Unity For Fedora (As in OpenSUSE or Arch)

[Kevin Kofler]

drago01 wrote:

> On Wed, Feb 1, 2012 at 10:18 PM, Kevin Kofler <kevin.kofler at chello.at>
> wrote:
>> 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?
> 
> If that is the intend of the spec then why not explicitly state it in
> there? Instead of having some "unwritten rules" that app authors depend
> on. To reuse your words "how hard can that be?"

What is the point of specifying that "the shell [shall] use enough of the 
data [the application] provides to convey the information as intended"? It's 
obvious! (And it's all that CAN be specified, since the goal of the spec is 
explicitly NOT to specify HOW that data shall be displayed.)

> Well because the app provides an interface to the user and it has to
> somehow be able to know what the user actually sees.

Why does the app need to worry whether the user will see an icon with the 
"locked" overlay located in the bottom-right corner, in the top-left corner, 
monochromatic and translucent over the entire icon, located next to the icon 
in a vertical list, or even something completely different from an overlay 
icon but still conveying the concept of being locked? It's the workspace 
shell's business, not the app's business.

> Lets say your app opens a dialog and the window manager is free to
> just not display it. Does that make any sense?

Yet that's exactly what happens if you use the notification (message) spec 
GNOME wants apps to use instead of the status notifier spec. Your 
notification might get completely silenced. And FWIW, sometimes that's 
actually what the user WANTS. Plasma also allows the user to forcefully hide 
status notifier icons (they will show up in a popup you can open through an 
arrow next to the system tray instead of the system tray itself) even when 
the icon actually wants to be shown. (There are 3 options: automatic, i.e. 
do what the app wants, obviously the default; always shown; always hidden.) 
It's part of empowering the user (a concept GNOME is missing completely, 
sadly).

>> 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.
> 
> Nobody said that.

Florian Müllner did:
| 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.

        Kevin Kofler