> 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 > >
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
