> On Sept. 1, 2014, 4:53 p.m., David Edmundson wrote: > > I need some the concept explaining, why would a developer set a > > fallbackpackage? > > Is it not always org.kde.breeze.desktop? > > Marco Martin wrote: > It would usually be the packagestructure setting it, in initPackage(), so > setFallbackPackage follows the same pattern as addFileDefinition(), > setRequired() and the likes. > > so, for the packages of type Plasma/LookAndFeel it would be > org.kde.breeze.desktop > for packages of types Plasma/Shell, it would be org.kde.desktop > > even tough at some point it will probably have to be something more > complicated, like the default lookandfeel one depending from the current > shell, if ever needed, will be feasible. > > David Edmundson wrote: > Ah, makes sense. Thanks. > > Do you really expect a linked link big enough to cycle? I can't really > see it going 3 deep. The cycle check is call cool though :) > > Could you add a warning in setFallbackPackage() if it finds a cycle and > no-ops. Could be confusing to debug otherwise. > > Marco Martin wrote: > added warning.. > i see it very unlikely that it's going to go deep, but better safe than > sorry :p > > Aaron J. Seigo wrote: > "Is it not always org.kde.breeze.desktop?" > > No, because of third party developers. Not every project targets the > desktop. > > That said, this applies to any use of Plasma::Package, which is meant to > be a generic concept not something just for the limited set of package types > plasmashell uses. It is helpful to think of it as a concept on its own rather > than in the context of Plasma Desktop. Other Frameworks using applications > really ought to be able to use Plasma::Package for their "bundles of data" > needs. > > "It would usually be the packagestructure setting it, in initPackage()" > > In the case of Shell and Look & Feel packages I would caution against > doing this, as it biases them to Plasma Desktop. The tablet interface in > Plasma Active will need its own "root" L&F; falling back to components from > breeze.desktop will likely be both an oversight and create undesirable > results. It also would mean that every time someone touches a component in > breeze.desktop that is used by the tablet UX, they will be required to ensure > it remains appropriate on touch. For devices even further afield from desktop > than tablets this becomes even more of an issue, and those devices may not > want to ship breeze.desktop at all. Of course, there is the alternative which > is to just tell system integrators to call their root package > "org.kde.breeze.desktop" but I'm not sure that would be desirable. > > While setting this in initPackage is a reasonable stop-gap for now, this > really ought to be something that gets defined in e.g. the shell package and > set in plasmashell so that it can be tied to the shell. If no fallback is > defined in the shell package, fair enough -> no fallback :) > > Marco Martin wrote: > "While setting this in initPackage is a reasonable stop-gap for now" > for now it does that, I think it's fine for a first step to get rid of > lookandfeelaccess. I would advise to provide a full complete package anyways, > soat start wouldn't matter much. > > Then, after this, how to make it depend from the shell? it may depend on > the shell kded, but it would depend from quite a lot of boilerplate, also it > should stay possible to configure it, so in the config file it would end up > with pairs shell/l&f packages i guess. > > Or, to make it a bit more primitive, but still functional for the scope, > the fallback could be from a configuration file as well, so integrators could > just ship such fine. > For the shell package instead, the fallback *may* be defined in its > metadata desktop file? (not sure this could really work for the l&f one) > > Aaron J. Seigo wrote: > "how to make it depend from the shell?" > > Looking only at the question of default fallback (not user config) then > your suggestion should work: > > "the fallback may be defined in its metadata desktop file?" > > This would indeed allow L&F customizations to define the source theme as > its fallback. (We'll ignore dependency resolution..) The default fallback > could be defined in the shell package's metadata file (so org.kde.desktop > would set that to org.kde.breeze.desktop, e.g.) so L&F without a defined > fallback would get the default fallback. > > For shell packages, I would agree that having complete packages is > desirable and safest and there should perhaps be no default fallback for > them. All or nothing, or else an explicitly defined fallback in its metadata > (as with any other package supporting fallbacks) > > "it would depend from quite a lot of boilerplate" > > The default fallback should be determined in one central place > (plasmashell or an external daemon, exposing the setting as a DBus property > on a well-known DBus service?) which only leaves applying it appropriately > wherever these packages are used. That indeed means some boilerplate, but > *that* could go into the Plasma/LookAndFeel package structure. So it wouldn't > have a literal value, but the logic necessary to fetch what the current > fallback value is and apply it. > > Marco Martin wrote: > "That indeed means some boilerplate, but that could go into the > Plasma/LookAndFeel package structure" > hmm for that I can think it could make sense having the structure > changing the path of all its packages after a signal from given kded.. > but the structure bookeeping the packages kinda stinks..
If the L&F fallback changes, that implies the shell package has changed; perhaps it then makes more sense to just re-create the L&F package as well? Then there is no bookkeeping required in PackageStructure. The application would be responsible for refreshing its relevant packages, which is another kind of boilerplate though a simpler one and one that is likely to be application-specific? - Aaron J. ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120029/#review65648 ----------------------------------------------------------- On Sept. 1, 2014, 7:04 p.m., Marco Martin wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/120029/ > ----------------------------------------------------------- > > (Updated Sept. 1, 2014, 7:04 p.m.) > > > Review request for KDE Frameworks and Plasma. > > > Repository: plasma-framework > > > Description > ------- > > introduces the concept of fallback for packages. > this will replace the private statically linked class LookAndFeelAccess in > workspace and desktop, but be more generic so will be usable for things like > the shell package as well. > The feature has an autotest as well to check it's actually working and > doesn't break other stuff. > > the package structures that will use this, will just set a package in their > structure::initPackage() > tough for the user of Package in c++ is possible as well to set the fallback > package outside the structure if custm things are neede (it's guarded that > cycles don't occur in the fallback chain) > > > Diffs > ----- > > autotests/CMakeLists.txt 4e64f38 > autotests/data/testfallbackpackage/contents/ui/main.qml PRE-CREATION > autotests/data/testfallbackpackage/metadata.desktop PRE-CREATION > autotests/data/testpackage/contents/ui/otherfile.qml PRE-CREATION > autotests/fallbackpackagetest.h PRE-CREATION > autotests/fallbackpackagetest.cpp PRE-CREATION > src/plasma/data/servicetypes/plasma-shell.desktop e2c83ba > src/plasma/package.h 2c686d7 > src/plasma/package.cpp 6ad3321 > src/plasma/private/package_p.h d902eb1 > > Diff: https://git.reviewboard.kde.org/r/120029/diff/ > > > Testing > ------- > > > Thanks, > > Marco Martin > >
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
