Re: Gnome shell suggestions after a bit of usage

[Florian Max <florian muellner gmail com>]

2011/7/8 Aurélien Naldi <aurelien naldi gmail com>

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

Oops, sorry - I mixed up terminology when quoting from memory. The cited description of "persistent" is correct, and it is a server capability rather than a notification hint (e.g. similar to the previously mentioned action support - applications can query the capability and adjust behavior accordingly). Both gnome-shell and the notification-daemon used in fallback mode support persistence, Unity's notify-osd does not. So the hint I meant is called 'resident'[0] ...

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

All running applications "clutter" the dock. To be honest, I don't see this as problem - to the contrary, having two completely unrelated ways to get to a running application (icon in dock, status icon) is much more problematic in my opinion.
 

* it clutters the workspace view, and strongly abuses the concept of
workspace for me

I don't think it really "clutters" the workspace view, unless the window is on the active workspace - but in that case it's likely that you actually want to interact with it.

I don't agree that it is an abuse either, but that's likely because we have different concepts of workspaces - one concept uses workspaces as a mean of organization, e.g. each workspace only contains windows which are associated with a well defined "task"; another concept just sees workspaces as a mean to provide additional space, the set of windows on a given workspace is much more arbitrary there. I can certainly see the conflict in the former case - "listening to music" is not a task of its own, so giving it a dedicated workspaces can very well be seen as an abuse. It works quite well with the latter concept though (which is also favored by the dynamic workspace management of the shell by the way).

 

* it clutters the alt-tab switcher

See comment on "clutters dock"

 

* some applications (dropbox) don't have an explicit window at all

That is very problematic from a shell perspective. Our definition of an application is pretty much "has open windows" (for running applications) or "will open windows" (for launchers). Services on the other hand are rather limited in presenting UI - the only "officially sanctioned" way is by using notifications.

 

* it doesn't solve at all the "I want to view the status of this
application or give it some order" use case

"give it some order" should be covered by notification actions, you are right about the "I want to view the status" case not being covered.

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.

That is a bug[1].

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

Those points are best discussed on #gnome-design - note that involving the designers does not necessarily boil down to "solve stuff at shell level", but rather "solve stuff at GNOME level" (oh, and more than one of them has used dropbox, so ...).
 

But I really think that applications should be able to add a set of
actions that can be triggered quickly by the user.

Again, the "if" and "how" of that are design questions.

 

The reasons why I mentioned the protocol used by indicators are:
* it exists today and is used by others

The same can be said about Windows? (Yeah, that's a low one, sorry for going there ...)
More seriously, if you are interested in some of the objections from the GNOME side, this post[2] is a good starting point.

 

* 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 don't think the UI is the main problem, but rather if we should support "something" that's between an application and a service. But then I'm a developer and this is a design question ...

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)

Hey, there are designers from Europe as well, you know - being European is not an excuse :-)
(If you haven't been able to guess from the name, so am I).

Obviously no one can force you to use IRC, but it's unfortunate - that's basically where design is happening. You can assume that designers follow the list, but not to discuss design here.
 

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

I think we're doing fine for now :-)


Florian

[0] http://developer.gnome.org/notification-spec/#hints
[1] https://bugzilla.gnome.org/show_bug.cgi?id=652752
[2] http://lists.freedesktop.org/archives/xdg/2010-January/011228.html