Re: Gnome shell suggestions after a bit of usage

[Aurélien Naldi <aurelien naldi gmail com>]

On Fri, Jul 8, 2011 at 6:20 PM, Florian Müllner <fmuellner gnome org> wrote:
> That is no longer true. Usually notifications are shown for a short time at
> the bottom center of the screen and then move to the summary until
> acknowledged by the user.  Applications can specify a 'persistent' hint
> though, which means that a notifications remains in the summary even after
> having been acknowledged (e.g. rhythmbox uses the hint for its "currently
> playing" notifications), until the applications exits or explicitly removes
> the notification.

Good to know, I did see a "persistent" hint in the spec, but it was
described as "wait until the notification is acknowledged", not truly
persistent. If this is a new hint, I hope it will be added to the spec
as what I would like is a _consistent_ way to do it. If a hint has a
different meaning depending on the environment, it is no longer a
cross-desktop spec...

>> The notification area was used both for such notifications and to provide
>> a way to interact with
>> "background" applications.
>
> True, though the latter was always a HIG violation. As mentioned in my
> previous mail, I've suggested a way to "background" applications which
> doesn't abuse the message tray, but designers' reactions have been rather
> reserved. As I see it, the use of "notification" icons as a way for
> applications to run in the background has its origins on Windows - as there
> are no workspaces, every running application uses precious space in the task
> bar, so the "minimize-to-tray" behavior was created as a workaround. Given
> that GNOME3 does have workspaces to "move stuff out of sight" and no task
> bar which could get cluttered, the need for the "background" workaround
> pretty much disappears.

I agree that puttng "background" windows on a separate workspace
unclutters the overview, but it certainly isn't a perfect solution,
just a workaround:
* it still clutters the dock
* it clutters the workspace view, and strongly abuses the concept of
workspace for me
* it clutters the alt-tab switcher
* some applications (dropbox) don't have an explicit window at all
* it doesn't solve at all the "I want to view the status of this
application or give it some order" use case

> No, there is no API - the name "system area" should really say it all.

I fully agree with this, if applications can add icons, they should
not mix with the system ones.

> Applications can use status icons, although their use is discouraged, and
> there are patches for adding support for "app indicators" in the message
> tray as well - though while the latter would have a more integrated shell
> look, conceptually it's no less broken than status icons, so it's not clear
> that it will be merged. Personally I think the KDE spec is broken by design,
> as it defines "bits of information" and allows both applications and "hosts"
> (e.g. the entity which displays the indicator) to pick an arbitrary subset -
> this works fine as long as applications can assume a specific implementation
> (as the Canonical one), but would fail silently when an implementation
> happens to expect a completely different subset than the application.
> Ironically Canonical should be well aware of that possibility, as they
> implemented the notification spec without support for actions, which was
> optional in the spec but taken for granted by many applications.
> Fortunately, unlike the notifier spec, the notification spec provides a
> mechanism for testing the server's capabilities, so applications
> incompatible with Canonical's notify-osd could be patched ...

These are good points. I was also unhappy about the removal of action
support in ubuntu, but I agree with them that the bubble poping up
should be very unintrusive. Gnome-shell has a nice solution with the
notification tray but it does steal focus when the mouse is at the
bottom at the screen at the same time, which happens sometimes.


> In my opinion that is the wrong way looking at it. "How should XY be
> implemented" is not an interesting question, try to identify a problem in
> the current shell design, and designers will work on a solution.

I have to say that I would love to agree with this but I just can't.
Of course some of the things that have been done with the notification
area are workaround better solved at the shell level, and I am very
impressed y the design work done for gnome-shell, but as great as the
designers are, they can't solve everything. People will want tweaks
and as extension points already exist, they will be abused (unless the
user base is too small, or not tech-oriented enough).

Many problems can (and should) be solved at the shell level. For the
sake of it, I can write a bit more about the dropbox use case. For now
it works in the notification area thus it feels alien in the shell, it
would be so much better with a native GUI. Here is what I want to be
able to do:
I don't want to see a dropbox window, or dropbox showing up in the
overview, alt-tab or the dock
I want to view quickly the sync status of dropbox (but I certainly do
not want a notification whenever it changes). This seems to be solved
by the notification API. I want to always see it, not only when a sync
is going on (ubuntu one used to do that and I hate it, I had no easy
way to know wether it was hidden because all was fine or because it
crashed)
When a sync is ongoing, I want to see remaining time and similar information.
I also want to be able to pause and restart the service (can also be
done through a notification action).
I also want other actions: open the website, the settings... does the
notification API allow a group of actions or just one?
I want to be warned if I try to log out while a sync is in progress or
if dropbox is paused (this does not exist yet, but should be
technically possible)
I want this behaviour to be as similar as possible in fallback mode,
in KDE, XFCE, unity... and properly integrated in all of them
As a developer, I do not want to have specific code for every DE, I
just want to define notifications, actions and be called back when
they are triggered.

I do not care what the solution is, I don't care if it involves
something different from the usual "icon with a menu". It can be
jumplist in the dock, a tab in the overview a dashboard, a bottom-left
"action tray" to complement the "notification tray", an extension to
the system area, whatever...
But I really think that applications should be able to add a set of
actions that can be triggered quickly by the user. The reasons why I
mentioned the protocol used by indicators are:
* it exists today and is used by others
* it is just a definition of callbacks, the shell designers are free
to split them into separate places, make them look the way they want,
decide how the list appear... This liberty does not exist with the
notification area
* I happen to be using ubuntu most of the time and as a user I love
(most of) the work they did on the indicators. I love much less unity
and some other parts though.
* I happen to be using gnome-shell (I have been watching it from time
to time for at least two years). I do love (most of) what I see about
the current direction

PS: someone suggested going to IRC to discuss this, I'm sorry this is
just not an option for me (I am in europe, making it difficult and I
nearly don't use IRC)

PPS: I am really affraid this turns into flamewar, being constructive
on mailing list is not always easy. I try to be my best.


Best regards

-- 
Aurélien Naldi