----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119451/#review63037 -----------------------------------------------------------
lookandfeelaccess/lookandfeelaccess.cpp <https://git.reviewboard.kde.org/r/119451/#comment43763> 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. lookandfeelaccess/shellpluginloader.h <https://git.reviewboard.kde.org/r/119451/#comment43764> not used? I'd quite like to have a chat about the goals of look and feel (next Monday meeting?). It was something where you guys clearly had a plan (or at least a name) before I got more heavily involved in Plasma, and I'm really not on the same page. - David Edmundson 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