Review Request 119451: some machinery for look and feel package

[Marco Martin]

> 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.
> 
> Marco Martin wrote:
>     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
> 
> David Edmundson wrote:
>     It probably should be themeable. My concern was changing files for an application whilst it's running.
>     
>     But after I think about it more, that would happen anyway.
>     All it would take is to have a Loader in a release that opens a file that gets renamed/deleted in an upgraded version and you'll have the same problems. It probably is best to notify and update the package so the app at least has a chance to handle it.
>     
>     I withdraw my comment.

anyways, the class is just sending a signal, if the application has particular problems in reloading at runtime, it would just ignore the signal.
btw at the moment it's signaling when the theme gets changed, but not when the files of the package gets upgraded (that looks like a separate can of worms...)


- 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/5e75b725/attachment.html>