<div dir="ltr"><div>I think this is getting a bit excessive. We don't need to enumerate every single place a desktop environment should put actions, we should simply specify that they should appear around the launcher in the specification. And if an action appears in both the messaging menu and the launcher menu, oh well? The user will cope, I think. </div></div><div class="gmail_extra"> <div class="gmail_quote">On Wed, Jul 3, 2013 at 11:43 AM, Aaron J. Seigo <<a href="mailto:aseigo@kde.org" target="_blank">aseigo@kde.org</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Wednesday, July 3, 2013 10:15:45 Lars Uebernickel wrote: > On 07/02/2013 06:09 PM, Ted Gould wrote: > > The use case was two fold. First there was concern that some desktops > > might not want to implement the actions or might implement them > > differently. It's also possible that desktops could put different sets > > of actions in different places. For instance, the Unity Launcher vs. > > the Messaging Menu. This way some items could be in one, the other, or > > both depending on how the values are set. > > I agree that it seems like it might be useful for applications to show > actions only in specific parts of the UI. However, I can't find an > application that does this right now for the messaging menu. > > Also, this goes against the spec, because "MessagingMenu" is not a > registered value. </div>honestly, this looks like something that should be in a different specification altogether. prior art in this direction: * the status notifiers / app indicators spec we solved this issue for categorizing entries for running applications. * mpris2 allowed the creation of things like the sound menu we see in various places these obviously have covered only running applications, but both work very very well given their focus (as opposed to re-use of a not-quite-appropriate area) and their clear separation of data and visualization. if we wish to see categorization of actions for applications that may not yet be running, a similar system that is focused on providing integration with, e.g. a presence or messasging menu, would make sense that is separate from the application .desktop structure. this would future proof those .desktop files from such features become passe and abandoned and would allow the creation of a system well designed for the use case of message population. an example of how this could matter: if every application implements a "Compose message" action on their own ... how does a shell present these in a consisten fashion? probably can't, since it is up to each application developer which means variance will occur. this is actually a good (bad? :) example of breaching the veil between application metadata and presentation in the target shell. instead, applications should be able to register themselves as "composers of messages of type [email|SMS|...]" and the shell should take care of presenting that to the user in a form factor and environment appropriate manner. therefore i don't think this kind of feature belongs in the application .desktop files at all. it leads to the kind of malformations we already see now as environments experiment with (currently) modern features such as a messaging menu and applications try to adapt while simultaneously making consistency next to impossible. <div class="im"> > > It seems to me like they are using the values correctly, but have been > > set more specific than you'd prefer. I'd imagine that most upstreams > > would be willing to accept patches to adjust the values if GNOME Shell > > is getting support for them. > > Definitely. I think we should just discourage their use in general, but </div>that hardly ever works ime. application developers take advantage of anything that made available, whether a central authority deems it kosher or not. <div class="im"> > keep them to enable some specific use-cases (for example "Open Window on > a New Workspace" wouldn't work on all desktops, and "Start Minimized" > makes no sense in GNOME shell). </div>should those be actions provided in an application's .desktop file though? seems like something that the shell should be inserting itself, not something down on an application-by-application basis. -- Aaron J. Seigo _______________________________________________ xdg mailing list <a href="mailto:xdg@lists.freedesktop.org">xdg@lists.freedesktop.org</a> <a href="http://lists.freedesktop.org/mailman/listinfo/xdg" target="_blank">http://lists.freedesktop.org/mailman/listinfo/xdg</a> </blockquote></div> -- Jasper </div>