On Nov 6, 2012, at 8:01 AM, Kristian Rietveld <k...@loopnest.org> wrote:
>
> On Nov 6, 2012, at 4:23 PM, Matthias Clasen wrote:
>> Problems with GtkStatusIcon
>>
>> - It is really centered around the idea that apps just export a small
>> bit of their UI into the 'panel'
>>
>> - It assumes that all desktops want to offer a permanent place
>> ("system tray") for applications to present a clickable icon with a
>> context menu
>>
>> - It requires the application to be running as long as its icon is
>> present, essentially forcing a daemon mode onto applications (eg
>> evolution-alarm-notify)
>>
>> - The X implementation uses XEmbed and can't really be made to work
>> nicely in a composited environment
>>
>> - The win32 implementation is also problematic
>
> I would argue the OS X implementation is also problematic. Showing the icon
> in the OS X menu bar is quite easy, however, in response we currently
> typically pop up a GtkMenu. This gives interesting problems with grabs/event
> handling. Also, it looks quite out of place because native applications show
> a native menu. The current GtkStatusIcon makes it close to impossible to
> automatically convert a GtkMenu into a native menu (e.g. custom menu items)
> and there's also the case where the status icon pops up something that's not
> a menu.
All very true. This *helps* Matthias's case to get rid of GtkStatusIcon.
Another point in favor of Matthias's proposal is dbus-independence. Dbus is
great on Linux, but is a poor fit for OSX, and Win32. Dunno about Android, but
iOS is decidedly daemon-hostile, so dbus isn't likely to happen there.
As an aside, has anyone ever gotten a Gtk-based program into the iTunes Store
-- or the App Store, for that matter?
Anyway, all-in-all this looks very good to me.
Regards,
John Ralls
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
