Created attachment 82856 [details] [review]
gtk_status_icon_get_widget.patch

Suggested implementation.

Ekiga also uses middle click to show the address book.

Changing summary; I've looked at the Windows API and it seems all of DnD[1], scroll events, middle-click, rich tooltips should be implementable, so there's no reason to use a non-portable solution.  It's a pity we can't use GtkWidget, but I guess notification area icons are a bit of a special case.

Suggestions:
* For DnD, create a GtkDraggable[2] interface implemented by GtkWidget and GtkStatusIcon; adapt gtkdnd.c to use the interface (API change will produce compiler warnings but no ABI break); in GtkStatusIcon, call or adapt _gtk_drag_{dest,source}_handle_event as appropriate.
* For scroll and middle-click, add "button-press-event" and "button-release-event" as with GtkWidget; emit "activate" or "popup-menu" if propagation not stopped.
* For rich tooltips, implement the new tooltips API: "has-tooltip" and "tooltip-markup" properties, along with "query-tooltip" signal.  If "has-tooltip" is set and the platform supports it, use mouse motion events to implement the new tooltips API; else use the tooltip set by gtk_status_icon_set_tooltip().

Comments?  Does this look feasible?  Is it the Right Way?

1. http://support.microsoft.com/kb/139408
2. interface GtkDraggable:
       prerequisite GObject
       method get_display(): GdkDisplay
       method get_screen(): GdkScreen
       method get_ipc_widget(): GtkWidget
       method register_dnd()
       method drag_highlight()
       method drag_unhighlight()
       method drag_pointer_grab(GdkCursor cursor, guint32 time)
       method drag_pointer_release(guint32 time)
       method monitor_drag_events(GCallback callback, gpointer data)
       method unmonitor_drag_events(GCallback callback, gpointer data)
       signal "drag-data-get"
       signal "drag-data-received"
       signal "drag-data-delete"
       signal "drag-leave"
       signal "drag-motion"
       signal "drag-drop"
       signal "drag-begin"
       signal "drag-end"

I am really not convinced that it is a good idea to enable all this on status icons. Sure, it may be possible to implement it on win32 too, but that should not be an argument to enable bad ui ideas.

Bad UI?  Specifically?  I'll admit that DnD is pretty much pure crack, but rich tooltips are essential for Rhythmbox, and the mouse-click stuff is pretty useful to add shortcut access to functionality available through the popup menu or main UI.

Rich tooltips would be useful, granted, but just don't think that allowing n different clicks on status icons is an improvement. Instead of moving statusicons  further and further away from their "status" function, I'd rather wait for the new panel applet api. 

What is so bad about dragging files to the status icon? I use this very often. The notification area (or the systray) isn't only used for status, most applications can be minimized in the tray. And there are applications how also support drag n drop, so why i do i have to maximize my application before dragging files to them? Imho it would be a very good feature to drag files just to the status icon.

Is someone working on a new applet api? theoretically not too hard with dbus and xembed as building blocks...

Well, this one is just barely starting to be used desktop-wide, so it would be great if applets API could just stop changing... Fixing this one is IMHO more urgent (even if features like drag and drop are willingly not implemented).

*** Bug 382018 has been marked as a duplicate of this bug. ***

(In reply to comment #8)
> Is someone working on a new applet api? theoretically not too hard with dbus
> and xembed as building blocks...
 
XEmbed doesn't sound like the new applet API would be cross-platform.  If said "applet API" isn't cross-platform (besides cross-desktop) then it should not be mentioned as alternative to GtkStatusIcon (specifically to prevent GtkStatusIcon from acquiring the missing functionality).

Changing the title, since there is no regression here; GtkStatusIcon never had the requested functionality.

Why not using this patch interim? Better then nothing, isn't it?

*** Bug 446592 has been marked as a duplicate of this bug. ***

Could someone make things move a bit ?

GtkStatusIcon NEEDS those functionalities. Don't tell me about "applet API", think about people not using gnome-panel.

(In reply to comment #15)
> Could someone make things move a bit ?

I doubt that anything will happen soon on this front. While I understand that for obvious reasons, introducing new APIs in a library like GTK+ requires some thinking and caution, I find that this process is often prolonged for an exaggeratedly long period of time.

For instance, EggTrayIcon has been available and widely used since 2002, but a similar (albeit more limited) GTK+ API (GtkStatusIcon) has only been introduced with GTK+ 2.10 (July 2006).

Another example: the so-called "rich" tooltips. Their usefulness has been blatant for a very long time (I've been myself carrying a modified version of GtkTooltips with one of my applications since 2004), but they have yet to be featured in a stable GTK+ release.

If this lag is a choice and not the consequence of lack of time, I then respectfully advise you to reconsider it.

Created attachment 96196 [details] [review]
statusicon-enhancements.patch

Here's a patch implementing most of the above:

* DnD - not covered, because it's a little cracky and would be a fair amount of work
* Scroll events - X11 only; rumour has it that scroll events are not passed to tray icons on Win32; I don't know NextSTEP well enough to implement this on Quartz, or even if it is possible
* Middle click - X11, Win32; not Quartz (again)
* Rich tooltips - X11 only.  Win32 and Quartz gracefully degrade by parsing the markup down to plain text.

Patch should apply cleanly to 2.12.0 tarball.

Can you merge the middle button support first?

My project(stardict) need this feature as people are reporting bug(trayicon is not transparent), while I don't want to remove the middle button feature.

Now I am still using eggtrayicon as I can add middle button signal to it. I add the image widget into egg_tray_icon just like the implement of gtk_tray_icon, but my image widget is not transparent, while gtk_tray_icon do. Can anyone tell me the essential lines of code in gtkstatusicon.c or gtktrayicon-x11.c which achieved this?

Thank you very much!

*** Bug 414903 has been marked as a duplicate of this bug. ***

Hmm.

I think I said in some other bug that I'd give up my opposition to statusicon additions that can be implemented cross-platform. This looks a bit uglier than I had hoped for in terms of platform-dependence. 

Can middle-click and rich tooltips be implemented at all on win32/quartz ? 

Created attachment 114491 [details] [review]
statusicon-enhancements.patch

Update for gtk+-2.13.3.

> +  SCROLL_EVENT_SIGNAL,

I *need* that for volume control, could anyone commit it for the next release
please?

Thanks.

I'd like to see this committed as two patches:

- new tooltip api
- scroll+button events

Please update the Since: tags to say 2.16, and please add new api to gtk/gtk.symbols and docs/reference/gtk/gtk-sections.txt

Scroll and button events done

* gtk/gtkstatusicon.[hc]: Add support for button press/release and
scroll events. Patch by Ed Catmur

tooltip api done, too.

Just to leave a note: I had to resort to EggTrayIcon to get DnD support. This allowed me write a plugin for the Exaile music player to be able to drop media files on the tray icon which in turn could then be directly played, appended to the playlist and more.

So while it might be difficult to implement on Windows, there are use cases for it.