> On July 24, 2014, 12:34 p.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. > > Marco Martin wrote: > 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...)
David, I think your fear is without need in this case as the greeter is not a long running process, but one that gets freshly started each time the screen gets locked. - Martin ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119451/#review63037 ----------------------------------------------------------- On July 24, 2014, 11: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, 11: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
