Shrinking to applet/notification area should have its own title bar button

Thank you for your bug. The standard way is to click on the notification area icon, not all the applications have this feature and that's not the job of the window manager to add an action for it

When you say "standard way", do you mean that this is specified in the GNOME HIG or something? So Gaim is wrong for minimizing when you press close?

The close button is meant to close the application, I'm not sure if the click on the notification area is documented by the HIG or not but it's the standard way in the GNOME desktop. gaim is not a GNOME application and the developper don't follow the HIG anyway so that's not an argument for upstream

"The close button is meant to close the application, I'm not sure if the click on the notification area is documented by the HIG or not but it's the standard way in the GNOME desktop."

I accepted this answer for a while, but the more I click on the notification area, the more I disagree. There should be a button on the title bar for this, as the standard method of moving to the notification area. Where do I petition for this? GNOME? Window manager?

HIG bugs go to http://bugzilla.gnome.org/enter_bug.cgi?product=HIG

Are you suggesting that *every* app should be minimisable to the notification area, or just the ones that already know how? How is this different from minimisation?

"Are you suggesting that *every* app should be minimisable to the notification area, or just the ones that already know how? How is this different from minimisation?"

Only the ones that have dedicated functionality for it. It looks like there are already programs for doing it for *all* programs.

http://ubuntuforums.org/showthread.php?t=267618

But that's not what I'm asking.

Rhythmbox, for instance, can operate as a standard window and be minimized like any other window. It can also be shrunk to the notification area, where it has dedicated right-click functionality for changing tracks, etc. The "Close" or "Minimize" buttons should not be overridden with this functionality, and depending on the user clicking in the notification area itself is strange for something that "minimizes" windows:

To maximize: Click Maximize button in title bar
To minimize to taskbar: Click Minimize button in title bar
To minimize to notification area: Click the notification area icon?

These are all similar functions. It makes sense to me that buttons for similar behavior should be in the same place, and behaviors that are common between apps should have standard unchanging interfaces. Clicking a fourth "Tray" button in the title bar is standard behavior in some Windows programs, and I think it makes more sense than clicking in the notification area.

http://ubuntuforums.org/showthread.php?t=576374

Example of four buttons in Windows from eMule website

Okay, before anything else, since you want this on some windows and not others, we would need a way of knowing which windows knew how to go to the notification area. This would be done with a new EWMH property on those windows. This would mean we had to update the EWMH, which can't be done without discussion on the wm-spec-list. So that should be your first port of call.

http://mail.gnome.org/mailman/listinfo/wm-spec-list

After that we'd need a way of telling a window to notificationify itself. Then we'd need to modify at least metacity and kwin and compiz to support the new functionality and the new theme formats which the extra button would require. Then we'd need to find some way of getting themes available that used the new button. But we can talk about all that on the list, so what you should do next is join that list and ask there, giving a reference to this bug report.

(Apart from all this, I still don't see how an action which means "hide the main window and put things in the notification area" is functionally different from the action which already exists which means "hide the main window and change the status in the task bar", or that you've explained this anywhere. But again, we can talk about this on the list.)

'is functionally different from the action which already exists which means "hide the main window and change the status in the task bar"'

This action already exists?

Um, yes, it's called "minimisation".

So you don't think Rhythmbox should minimize at all? It should just go to the notification area?

Well,

1) it's not really my call, I just hack the window manager; this is something the HIG people need to figure out. But
2) notificationisation and minimisation appear to me to be functionally very similar and I don't see why they should both be supported
3) if only one of them is supported it should presumably be the one we've been using for the last few decades rather than the new one
4) but it might be really useful if we allowed people to add options like "stop" and "rewind" and so on to the right-click menu on libwnck (the task bar) and the right-click metacity menu, via EWMH.

In any case, we still need to discuss this on wm-spec-list.

Why has this STILL not been included yet?
The discussion was about consistensy - the point is - ALL windows must behave consistently. Right now (today @ tuesday 8 april) when I open Amarok it goes into tray with a notification window that I need to tick when I press close (and again with notification asking me if I want to close when I press quit). Skype closes with close button. Deluge can ONLY be minimized to gnome bar , not system tray etc etc.
Do Ubuntu developers communicate with each other AT ALL?

Amarok is a KDE app, Skype is a third-party app. Ubuntu developers don't have that much control over this. They should officially say "we'd like this to be consistent for all apps", but then they have to pass it upstream to the people writing the various programs and desktops to get them to build it into the system. This won't happen overnight.

Maybe it would be good to make a list on the wiki of the various programs and conventions, to illustrate to everyone how confusing it is.

DeadZedz, Endolith: Did anyone raise a discussion on wm-spec-list? That really is the next step to getting this fixed.

I don't know anything about the wm-spec-list, EWMH properties, or the relationship of these things to Ubuntu. I don't think I'm the right person to bring it up.

I am aware of properties like gtk.gdk.WINDOW_TYPE_HINT_DIALOG that tell the window manager whether to provide one button or three:

http://www.pygtk.org/docs/pygtk/gdk-constants.html#gdk-window-type-hint-constants

So similar functionality already exists. I don't understand why people are so resistant to expanding it.

Visual mock-up here: http://ubuntuforums.org/attachment.php?attachmentid=77153&d=1215701439

Endolith:

1) I get a permissions error going to that page. Can you attach the mockup here?

2) Yes, exactly: gtk.gdk.WINDOW_TYPE_HINT_DIALOG ends up as an EWMH hint. If we were to do what you want here, we would need to add a new EWMH hint. wm-spec-list is the mailing list to propose new EWMH hints on.

3) My discomfort with this idea is nothing to do with the technical side of things. It's unrelated to the fact that a window can be a dialogue or an ordinary window. It's merely because I can't see how it differs, from the user's point of view, from minimisation, which has been in X for twenty-five years now.

(And my discomfort with the idea is fairly irrelevant. If the wm-spec-list agrees on this and updates the EWMH, I'll certainly add it. If the human interface folks say to add it, that'll be persuasive for the wm-spec-list folks. We could even strike out boldly and make up some hokey new Metacity-based hint that didn't work in any other window manager as proof of concept, but then the GTK+ folks probably wouldn't add it and if they didn't it would be unlikely that the app developers, Pidgin and Rhythmbox and so on, would want to play along.)

Oh, and another problem that hasn't been much discussed: adding a new button means updating every theme in existence.

I guess Ubuntu Forums only allows you to see attachments if you log in. Attached.

> My discomfort with this idea is nothing to do with the technical side of things. It's unrelated to the fact that a window can be a dialogue or an ordinary window. It's merely because I can't see how it differs, from the user's point of view, from minimisation, which has been in X for twenty-five years now.

Hmm... I don't get it. You can use the same word for both, but the function of "minimizing" to the taskbar and "minimizing" to an applet/notification area icon are very different.

Applications like Pidgin or Rhythmbox support all three "go away" actions (Minimize/Iconify/Close), yet there are only two buttons available for these actions to be bound to, so different apps use different conventions for mapping between actions and buttons, and everything is inconsistent.

(FWIW, the word "iconify" is going to cause problems very soon, since it's what the official X documentation calls what everyone these days calls "minimisation". The name wasn't as widely known in 1984. I don't have any better suggestions at present, though.)

I still don't see what the difference is, from the user's point of view. I agree that it is in fact true that Pidgin's buddy list, and Rhythmbox's main window, can both be minimised (while remaining on the notification area) and sent to the notification area (but not minimised). But statements about how apps currently behave miss the point. Rather, I don't see what, to the user, is the useful difference between an icon in the taskbar and an icon in the notification area, other than that you can at present have useful additional menu options on the context menu on the icon in the notification area (which could easily be added to the taskbar as well). Consider for a moment whether it would make any difference at all if every program could only vanish away to the notification area, and then if every program could only vanish away to the taskbar. I can't see you'd lose any significant functionality.

But as I said, my opinion on this carries no more weight than anyone else's; the HIG people are the people who can make the call.

It may shed a little light on the matter if I point out that this use of the notification area is not what it was designed for, and is a recent development: I think the idea spilled over from the system tray on MS Windows. The notification area in GNOME is there to provide notifications, such as the package manager telling you there are new updates you should look at, or the battery monitor telling you you've lost AC power, or the printer daemon telling you your job's printed. See:
http://developer.gnome.org/projects/gup/hig/2.0/desktop-notification-area.html
http://developer.gnome.org/projects/gup/hig/draft_hig_new/desktop-notification-area.html
for the details. Programs that *live* in the notification area are what used to be implemented as applets, and according to the official rules still should be.

That said, I'm not saying that changes to this idea are bad; systems of ideas grow and develop. They are, however, out of step with the HIG, and perhaps the HIG people need to be consulted and discuss the implications for themselves. As evolutionary developments, they have also, as I said earlier in this comment, not been thought through in as consistent fashion as the older, documented ideas, and they could do with some careful discussion.

> But statements about how apps currently behave miss the point.

Well, there's a problem with the way apps currently behave, regardless of the idealized way they should theoretically behave.

> Rather, I don't see what, to the user, is the useful difference between an icon in the taskbar and an icon in the notification area

So Rhythmbox and Pidgin should be applets that reside solely on the Panel?

> It may shed a little light on the matter if I point out that this use of the notification area is not what it was designed for, and is a recent development: I think the idea spilled over from the system tray on MS Windows.

Microsoft considers the term "system tray" incorrect:

http://blogs.msdn.com/oldnewthing/archive/2003/09/10/54831.aspx

The system tray is, however, defined for KDE and the freedesktop spec:

http://developer.kde.org/documentation/library/kdeqt/kde3arch/protocols-docking.html
http://standards.freedesktop.org/systemtray-spec/systemtray-spec-latest.html

As far as I'm concerned, the "iconify" button applies to either notification area icons or applet icons.

> Well, there's a problem with the way apps currently behave, regardless of the idealized way they should theoretically behave.

This is true. I brought this up on IRC just now, and people came up with a large set of applications which broke the rules given in the HIG. Either the HIG is wrong or the applications are. We need to sort this out.

> So Rhythmbox and Pidgin should be applets that reside solely on the Panel?

Perhaps; I haven't said exactly that. Perhaps they should both live on the notification area and so should everything else. Perhaps we should come up with a third way.

Thanks for digging up those links. I note that the freedesktop specification explicitly says that only transient icons belong in the tray, so Rhythmbox and friends are still in violation of it.

> As far as I'm concerned, the "iconify" button applies to either notification area icons or applet icons.

I think this is a good idea. One point which someone brought up on IRC is that there is currently no spec-valid way to handle persistent background applications. The spec, as you noted, brushes aside the problem by saying, "Oh, those are just applets". But the trouble with doing them as applets, as such, is that:

1) applets (as currently implemented with the panel) need to be explicitly placed on the panel, whereas notification area icons just appear in any old order in a pleasantly helpful sort of way

2) it is very tied in to the use of gnome-panel; if a program wanted to work just as well with KDE, or even with GNOME for someone who ran AWN instead of gnome-panel, they would have to reimplement the applet part all over again each time. Notification area applets work everywhere.

I think I shall send a bunch of people from Planet GNOME over here to give their twopennyworth; any objections?

> 1) applets (as currently implemented with the panel) need to be explicitly placed on the panel, whereas notification area icons just appear in any old order in a pleasantly helpful sort of way

There's probably a better way to do all of this, but it would require much more fundamental overhauls, like getting rid of the taskbar and notification area altogether and using some of the features of AWN or an OS X dock (but they have little icons at the top-right of the screen next to the clock, too, don't they?)

And if we stop trying to fix current problems because of the possibility of those fixes being irrelevant in a very distant, very different future, stuff will stay broken for a long time.

> 2) it is very tied in to the use of gnome-panel; if a program wanted to work just as well with KDE, or even with GNOME for someone who ran AWN instead of gnome-panel, they would have to reimplement the applet part all over again each time. Notification area applets work everywhere.

Right.

If Pidgin's persistent state is changed to be implemented as an applet, does it use the same applet icon to notify you of new messages, or does it pop up a second icon in the notification area?

"and people came up with a large set of applications which broke the rules given in the HIG. Either the HIG is wrong or the applications are. We need to sort this out.
...
One point which someone brought up on IRC is that there is currently no spec-valid way to handle persistent background applications."

Can we file a bug for the HIG conflict, and make this bug dependent on it?

"I think I shall send a bunch of people from Planet GNOME over here to give their twopennyworth; any objections?"

None here

Was there ever a discussion on the Gnome list about this?

The difference between panel applets and notification area icons is really irrelevant to this discussion.

The point is that apps have an "iconified" functionality that is fundamentally different from "closed" and "minimized" functionality, and that there is no standard way to get the app into this state from the window itself, resulting in abuse of the standard window management buttons.

Some discussion on the Metacity blog: http://blogs.gnome.org/metacity/2008/12/23/notifisation/

I would realy like to see that feature.

You misunderstand the notification bar, it is actually abused for minimizing of different kind, eg when you want to seperate a window from the taskbar.

What it really needed is second official taskbar, that contatins only icons, and put there all applications that user want to.

Notification bar should die as such, it should just turn in another taskbar for applications, and btw this is exactly mostly the case today, but it isn't standard.

Real notifications should be shows as just a popup window with no icon.

Controls like volume/brightness, app launchers are already seperate applets.

Let me tell again, exactly like you say here, there should be two taskbars,
one main one and a special icon only taskbar for important/background apps.

And there should be two buttons exactly like you say, minimize there and there.

This is the best feature I would like to have on linux

> What it really needed is second official taskbar, that contatins only icons, and put there all applications that user want to.

How is that different from applets? You can create a panel and put all your applets on it next to each other if you want.

> Let me tell again, exactly like you say here, there should be two taskbars,
one main one and a special icon only taskbar for important/background apps.

So the only difference between this and applets is that the applet icon would disappear while you have them open in "window" mode? I'm not sure there's any benefit to this.

Just encourage developers to create applets instead of notification area icons, and/or encourage the freedesktop spec to be revised so that it creates an applet in Gnome and notification area icons in KDE and Windows.

http://standards.freedesktop.org/systemtray-spec/systemtray-spec-latest.html

You still didn't understand me.
Applets are nice, but I want to be able to place any, I repeat any application like terminal, nautilus, evolution, to the second taskbar, thats all, just if I run someting importaint in terminal or that I for example started a gui app from terminal, and I don't want accidenty to close the terminal and have app killed, then I want to put that terminal to systray, or I might want to put specific pidging chat to systray, etc...

Alltray is the app that does that but does that in buggy way.
I want a standard support from WM and panel, and a button to place app to second taskbar would be nice

> I want to be able to place any, I repeat any application like terminal, nautilus, evolution, to the second taskbar, thats all,

So that's kind of like a different form of minimization, then? Not really the same as the applet/notification area icon functionality. I don't think that's related to this bug.

Yeah, but if such featute gets ever implemented, it would remove the need in 90% of application specific tray icons, and maybe even replace tray bar.

also having a button in each window will be nice

what is the treshold of some improvement request making it into consideration of linux desktop developers?
Everyone knows that linux OS's lack confomity and direction.

@DeadZedz: I am a developer. I have given it some consideration. Did you read the blog post I linked above? You should.

We are all thinking the same thing - I wrote something over at http://ubuntuforums.org/showthread.php?t=1022061 that is working towards a consistent 'minimize to tray' functionality. We can bypass the issue of adding a fourth button by using context menus instead. I think the best way to get started is to develop or rewrite AllTray, which always gets mentioned whenever people talk about this issue.

You know, I originally thought of this as a gnome-panel applet, but it might work better as a metacity feature, since I'm envisioning 'minimize to tray' as a title bar context item. My 'global defaults' (dock or not) could be hidden away in gconf instead of an applet context menu. Basically, just rewrite AllTray to be less buggy, integrate it into metacity, instant coolness.

I don't think "we are all thinking the same thing" at all. Some people here are talking about a different new fucntionality "minimize to icon", which is like standard minimization but in icon form, that would be possible for all apps, like the AllTray program. I really don't think this makes any sense for most apps. "Minimize to window list" is a fundamentally different function than "shrink to applet form".

The functionality that already exists (shrinking to either an applet or a notification area icon) only makes sense for some apps (the ones that have a persistent background functionality as well as an active foreground functionality).

> I really don't think this makes any sense for most apps.

I don't think 'Always on Top' makes sense for most apps, but I love the fact that when I need it, it's there. I don't see anything wrong with providing a new, unobtrusive feature for people to play with.

I guess we are thinking about different things, because I would like all windows to have 'minimize to tray' functionality, instead of simply providing more control over the windows/programs which already have this. I apologize for wasting your time, and will fill my own bug report.

Cheers.

@aeosynth I am thinking exactly the same thing, and tell me about your new bugreport, I''l monitor it

@Maxim: I filed them at https://bugs.launchpad.net/ubuntu/+source/alltray, and unsubscribed to this bug.