Unity For Fedora (As in OpenSUSE or Arch)

[Kevin Kofler]

Florian Müllner wrote:
> 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,

Thus the shell should do that. How hard can it be?

> but there are no guarantees or ways to query the shell's capabilities.

Because the application should not have to worry about it.

> 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"

Implementing the spec is needed for your application to work properly on 
everyone else's desktops, and everyone else's applications to work properly 
on your desktop.

> - after all, "enforcing" adoption of technology is not what
> freedesktop.org is supposed to be about[0] ;-)
>
> [0] http://aseigo.blogspot.com/2005/04/stupidity-of-dconf.html

Bad example. Configuration file storage is not a communication protocol. The 
status notifier protocol is a protocol for communication between the 
applications and the workspace, and thus a communication protocol to the 
same extent as HTTP, FTP, SMB etc.

> 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.

Newsflash: KDE *also* deprecated the use of the system tray by random 
applications by default! However:

* Some users WANT to have the OPTION of having an icon for a specific 
application there. I know GNOME hates options, but not everyone agrees with 
that. So several applications do have a preference to show a system tray 
icon even if it is disabled by default, and change requests such as 
https://bugzilla.redhat.com/show_bug.cgi?id=761640 are just rude. (And yes, 
I know XChat is still using the crappy legacy XEmbed protocol. And by the 
way, I no longer comaintain or use XChat, so for all I personally care you 
can cripple it all you want, but that doesn't make it any less stupid to do 
so.)

* Not any cross-desktop program is a regular application. There can also be 
cross-desktop system utilities. Think, e.g., of hardware enablement: gnome-
shell currently has a hardcoded Bluetooth icon (and in fact requires an 
extension to get rid of it), what if there's a completely new hardware 
technology coming up which warrants an icon just as much? Why does 
everything have to be rewritten and hardcoded into gnome-shell (as was done 
for network management, bluetooth etc.)? Another example is imsettings, 
which not only had to be rewritten as a gnome-shell extension, but was not 
even allowed onto the default Fedora desktop (the misnamed GNOME "Desktop" 
live image) because the extension was not yet merged into upstream gnome-
shell!

So the argument that you're refusing to implement a cross-desktop protocol 
in order to ban random applications from adding themselves to the panel is 
bogus.

> Because the "integrated experience" means that there is a fixed set of
> system items with a defined order.

Including a bluetooth icon on a machine which does not even have bluetooth 
hardware? This is just beyond silly!

I'm really fed up of GNOME's "one size fits it all" mentality.

> 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! ;-)

Notification messages and status notifier icons are totally independent 
concepts with totally different use cases and totally different practical 
uses. They are separate protocols for a reason.

Notifications (also called "passive popups") are for one-off messages you 
want to show to the user to inform them of something transient. Status 
notifiers are for status icons the user wants to permanently keep an eye on, 
such as network connectivity (which in fact you do realize needs a status 
icon, or you wouldn't have hardcoded it in your shell).

But the idea that every user will always need the exact same hardcoded set 
of status icons in the panel is extremely simplistic and flawed, or we 
wouldn't have the bazillion gnome-shell extensions adding or removing those 
icons.


I'm totally fed up of how GNOME is trying to dictate to all applications how 
they can or should behave and refusing to interoperate with any 
specification which doesn't follow their restrictive "design". GNOME is not 
a universe of its own, there will always be non-GNOME applications running 
under GNOME, and GNOME applications running under other environments.

        Kevin Kofler