On mié, 2012-02-01 at 18:25 +0100, Kevin Kofler wrote: > The objections weren't addressed because they objected to the very point of > the spec, making it impossible to address them without defeating the purpose > of the spec. > > One main design goal of the spec was that it should NOT be the app's job to > decide how exactly the icon will look, but the shell's. I don't think anyone made an argument for letting apps "decide how exactly the icon will look" (which is basically what XEmbed does, and everyone agrees that it's crap), but rather to avoid the other extreme of giving the shell complete power of what to display (and even whether to display anything at all). As is, applications can only hope that the shell will use enough of the data it provides to convey the information as intended, but there are no guarantees or ways to query the shell's capabilities. But I don't want to reopen that xdg discussion; I just wanted to clarify that GNOME did not ignore the spec, but refused to adopt it because it was deemed insufficient. We'll have to agree to disagree on whether the reasons brought forward justify the non-adoption. I have no problem with your opinion that the NotifierIcon spec is a good spec, but I do take issue on blaming GNOME for not adopting a spec we consider "bad" - after all, "enforcing" adoption of technology is not what freedesktop.org is supposed to be about[0] ;-) > And it makes sense: > Look at how gnome-shell deprecated the system tray entirely because it > looked totally out of place there, and is forcing everyone who wants an icon > in the panel to implement a GNOME-specific shell extension in JavaScript. You are right about requiring a Javascript extension to add items to the top panel, but you are wrong about the reasoning - it is not because the "system tray looked out of place" (which it does, but it is nevertheless still supported in the message tray), but rather because the top panel is considered "system space", which means that we do not *want* random applications to add anything to it. So even if we had adopted NotifierIcons for the top bar (which was considered), it would still have been reserved for a small set of processes (mostly gnome-settings-daemon). Given that design restriction, it becomes very much irrelevant whether the implementation uses cross-desktop technology or not. > Cross-desktop status notifiers and native Plasma widgets > (plasmoids) can sit right next to each other in the Plasma system tray and > look and feel the same, why can't gnome-shell offer the same integrated > experience rather than deprecating everything other than gnome-shell-only > extensions? Because the "integrated experience" means that there is a fixed set of system items with a defined order. Extensions can be used to "hack" the intended experience (which includes adding "non-official" icons in the top bar), but it's nothing we want normal applications to do. Applications are encouraged to interact with the message tray (== the autohiding bottom panel) via freedesktop notifications (yay, cross-desktop! ;-) Florian [0] http://aseigo.blogspot.com/2005/04/stupidity-of-dconf.html -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
