Review Request 119451: some machinery for look and feel package

Marco Martin notmart at gmail.com
Thu Jul 24 10:41:36 UTC 2014



> On July 24, 2014, 10:34 a.m., David Edmundson wrote:
> > lookandfeelaccess/lookandfeelaccess.cpp, line 89
> > <https://git.reviewboard.kde.org/r/119451/diff/1/?file=292284#file292284line89>
> >
> >     My concern is this will create more problems than it's worth.
> >     
> >     Scenario:
> >      - I add a new feature in the lock screen in 5.1 with a new rootContext variable
> >      - I update the QML to use this new feature in 5.1
> >      - a user upgrades his system
> >      - We then reload the package (but not the binary) we get a QML error and the user can't log in again.

so do you think some more complicated things like the lockscreen souldn't be themeable? may make sense on a maintainance standpoint, but yeah, needs definition of what should be in there, what shouldn't


- Marco


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119451/#review63037
-----------------------------------------------------------


On July 24, 2014, 9:43 a.m., Marco Martin wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119451/
> -----------------------------------------------------------
> 
> (Updated July 24, 2014, 9:43 a.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> -------
> 
> This is still nowhere near final mergeability, but rather a request for comments for early stages ;)
> 
> So, what does an application that uses stuff from l&f needs?
> * open the proper l&f package, as configured
> * fetch files from it
> * use files of the default one if the provided one is incomplete
> * monitor for theme changes and if necessary reload the qml
> * some applications may even want to have an optional local config that overrides it, like the splash, but is out of scope of a central management
>  
> the branch uses a little class that does all of the above (minus the last point) and uses it for now in the splash screen
> For now it would just be statically linked into users, since they should be all in plasma-framework for now (of course not optimal)
> 
> *maybe* is stuff for libplasmaquick, but that library since locks a release of p-f with the same release of users of it, should probably me made public or else, so I'm a bit hesitant to add further stuff into it.
> 
> 
> Diffs
> -----
> 
>   ksplash/ksplashqml/CMakeLists.txt 16c58a0 
>   ksplash/ksplashqml/SplashWindow.cpp 23603f5 
>   ksplash/ksplashqml/shellpluginloader.h 9c0f624 
>   lookandfeelaccess/lookandfeelaccess.h PRE-CREATION 
>   lookandfeelaccess/lookandfeelaccess.cpp PRE-CREATION 
>   lookandfeelaccess/shellpluginloader.h PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/119451/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20140724/3338b6c4/attachment-0001.html>


More information about the Plasma-devel mailing list