On Thursday, February 3, 2011, Ted Gould wrote: > The use case was
use cases! excellent ... :) > people wanting different menus on the panel vs. on the launcher. crazy idea: different menus from the same SNI for different (well-defined in the spec) contexts? if the SNI only provides a "generic" menu, use that everywhere. if they provide a "launcher" menu, use that for launchers? we'd need a set of menu contexts (generic or primary controller, launcher, ..?) > Or not appearing on the panel at all even if there wasn't a > launcher available. could be a piece of metadata in the SNI itself to dictate this. (and then it would work with any launcher.) > So the specific case was with Tomboy where in the > menu on the panel they wanted to have a "Quit" button but the launcher > menu automatically has a close (through the WM) and they didn't want > both. sounds like we need/want action-level metadata. > Also, in our specific case there are more restrictions on the > menus in the launcher (no submenus) so if an app wanted to use those > they wouldn't want it to appear in the launcher. this can be determined with a heuristic? > I would imagine that for most applications if they were going to use > this feature they would be building more than one Item. They'd build > one for a very specific visual target and then another that is a generic > item for all other visualizations. assuming they know of the available visualizations (and their design guidelines), also create a generic one and then actually get the visualization-specific ones right (esp over time -> what happens when the visualization changes design in some way?). it's a lot of overhead for the developer and very prone to breakage over time. any time we've put visualization control in app developer hands things get messy very quickly over the years due to these issues :( for Canonical, you have Unity today but in 5 years what will you have? maye something different. it's probably better not to get a whole bunch of app code specific to today's Unity design that in N years you're going to have to either provide legacy support for (probably with hacks) or which will result in having to re-work all those apps .. again. for KDE, it's even trickier: we don't have just one to-market product to support. different vendors ship Plasma in different forms and configurations, so we have to deal with "instant legacy" whenever these kinds of features are introduced. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
