Unity For Fedora (As in OpenSUSE or Arch)

[Florian Müllner]

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