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