After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 409435 - GtkStatusIcon enhancements: DnD, scroll events, middle click, rich tooltips
GtkStatusIcon enhancements: DnD, scroll events, middle click, rich tooltips
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: Other
2.10.x
Other Linux
: Normal enhancement
: ---
Assigned To: gtk-bugs
gtk-bugs
: 382018 414903 446592 (view as bug list)
Depends on:
Blocks: 349280 361139 434023
 
 
Reported: 2007-02-18 22:26 UTC by Ed Catmur
Modified: 2010-05-15 13:37 UTC
See Also:
GNOME target: ---
GNOME version: 2.17/2.18


Attachments
gtk_status_icon_get_widget.patch (2.31 KB, patch)
2007-02-18 23:18 UTC, Ed Catmur
none Details | Review
statusicon-enhancements.patch (27.58 KB, patch)
2007-09-25 21:21 UTC, Ed Catmur
reviewed Details | Review
statusicon-enhancements.patch (27.93 KB, patch)
2008-07-13 21:01 UTC, Ed Catmur
committed Details | Review

Description Ed Catmur 2007-02-18 22:26:31 UTC
Rhythmbox bug 349280 (replace EggTrayIcon with GtkStatusIcon) is blocked by the following regressions:

* GtkStatusIcon doesn't support dnd (but does anyone actually drop files onto
the icon?)
* GtkStatusIcon doesn't support scroll events, which we currently respond to by
changing the volume
* GtkStatusIcon doesn't support middle click (we respond to with play/pause)
* GtkStatusIcon doesn't support mouseover events (we use a SexyTooltip for displaying rich information)

ISTM the easiest way to fix this would be with a gtk_status_icon_get_widget() method, probably accessing a readonly "widget" property, which is NULL on non-fdo platforms (Win32).
Comment 1 Ed Catmur 2007-02-18 23:18:35 UTC
Created attachment 82856 [details] [review]
gtk_status_icon_get_widget.patch

Suggested implementation.
Comment 2 Luis Menina 2007-02-19 16:36:15 UTC
Ekiga also uses middle click to show the address book.
Comment 3 Ed Catmur 2007-02-22 19:46:33 UTC
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"
Comment 4 Matthias Clasen 2007-02-22 21:06:38 UTC
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.
Comment 5 Ed Catmur 2007-02-23 00:39:58 UTC
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.
Comment 6 Matthias Clasen 2007-02-23 00:57:20 UTC
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. 
Comment 7 Jan Niklas Hasse (Account disabled) 2007-03-06 20:23:11 UTC
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.
Comment 8 Havoc Pennington 2007-03-06 20:28:12 UTC
Is someone working on a new applet api? theoretically not too hard with dbus and xembed as building blocks...
Comment 9 Luis Menina 2007-03-07 00:13:16 UTC
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).
Comment 10 Murray Cumming 2007-05-04 19:58:29 UTC
*** Bug 382018 has been marked as a duplicate of this bug. ***
Comment 11 Gustavo Carneiro 2007-05-22 13:12:04 UTC
(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).
Comment 12 Matthias Clasen 2007-05-22 13:50:06 UTC
Changing the title, since there is no regression here; GtkStatusIcon never had the requested functionality.
Comment 13 Jan Niklas Hasse (Account disabled) 2007-05-26 13:11:29 UTC
Why not using this patch interim? Better then nothing, isn't it?
Comment 14 Christian Persch 2007-06-12 09:47:52 UTC
*** Bug 446592 has been marked as a duplicate of this bug. ***
Comment 15 Olivier Duclos 2007-07-21 22:45:01 UTC
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.
Comment 16 Jean-Yves Lefort 2007-09-08 18:14:14 UTC
(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.
Comment 17 Ed Catmur 2007-09-25 21:21:02 UTC
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.
Comment 18 huzheng 2008-02-18 08:55:27 UTC
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!
Comment 19 Björn Lindqvist 2008-04-27 00:30:00 UTC
*** Bug 414903 has been marked as a duplicate of this bug. ***
Comment 20 Matthias Clasen 2008-05-24 20:47:55 UTC
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 ? 
Comment 21 Ed Catmur 2008-07-13 21:01:34 UTC
Created attachment 114491 [details] [review]
statusicon-enhancements.patch

Update for gtk+-2.13.3.
Comment 22 Bob Mauchin 2008-10-03 00:13:56 UTC
> +  SCROLL_EVENT_SIGNAL,

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

Thanks.
Comment 23 Matthias Clasen 2008-10-31 05:52:42 UTC
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
Comment 24 Matthias Clasen 2008-11-01 05:33:59 UTC
Scroll and button events done

* gtk/gtkstatusicon.[hc]: Add support for button press/release and
scroll events. Patch by Ed Catmur
Comment 25 Matthias Clasen 2008-11-03 19:50:21 UTC
tooltip api done, too.
Comment 26 Mathias Brodala 2010-05-15 13:37:32 UTC
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.