Unity For Fedora (As in OpenSUSE or Arch)

[Kevin Kofler]

Florian Müllner wrote:

> No, the argument for refusing to implement the protocol is that the spec
> is bad. I was merely pointing out that *if* we used the protocol in the
> top bar, it would have been as an implementation detail with no benefit
> to applications (e.g. no way for applications to provide options to
> override that behavior as you imply)

Then your implementation in gnome-shell would just be half-assed and crappy, 
just like your implementation of the XEmbed-based spec is. Unlike the 
XEmbed-based spec, the status notifier spec actually allows apps to specify 
whether their icon is "active" or not, and a good implementation will show 
it in the panel if it is active and hide it behind a popup if it is not. 
(That's exactly what Plasma does.) You have both an area in the panel where 
the icon could be shown (themed to look the same as the icons which are 
already there, that's exactly why the spec allows the shell to theme the 
icons!) and a popup where it could be shelved in when inactive. Now the spec 
does allow you (by design) to decide you know better and always hide the 
icon behind the popup, it would just be lame, but apps would still be no 
worse off than now, where they automatically fall back to the old XEmbed-
based spec, to which you give the same treatment.

But in any case, that doesn't address the issue of GNOME application 
developers rejecting patches to support the spec in their applications, 
which was the issue that started this subthread. GNOME applications aren't 
only used on gnome-shell.

> On mié, 2012-02-01 at 22:18 +0100, Kevin Kofler wrote:
>> Including a bluetooth icon on a machine which does not even have
>> bluetooth hardware? This is just beyond silly!
> 
> *sigh*
> You are trolling.

How is that trolling? Some icons are just useless in some situations. (And 
even if you can autodetect whether a bluetooth controller is present, you 
still cannot know whether the user actually owns anything it can pair with, 
so that is not a solution either.) There's also the accessibility icon which 
will be totally useless for most users. Why does it take third-party 
extensions to get rid of those useless icons? It just doesn't make sense.

> Except that applications can set a 'resident' hint on notifications, in
> which case a representive icon is kept in the message tray, from which
> the notification can be recalled; together with the ability to provide
> actions on notifications, the experience is not different from status
> icons.

Except that this feature only works that way in GNOME and nowhere else. It 
also makes some strong assumptions on how the message tray looks, which is 
exactly what the status notifier spec tries hard to avoid. There is no place 
in the Plasma notifier where one would put an icon (in fact, the Plasma 
notifier IS an icon in the system tray, and the notifications pile up in the 
icon's popup). There is support for persistent notifications, but they are 
really persistent, i.e. they keep showing (as notifications) until you click 
them away. To my knowledge, no non-GNOME desktop implements the "resident" 
notifications you describe.

And it's still a different concept from the status notifier icons, even if 
it might be possible to abuse it to work approximately the same way. If it 
were the same concept, why implement a different incompatible spec rather 
than the one at least 2 other desktop environments implement?

        Kevin Kofler