Re: application indicators
- From: Bastien Nocera <hadess hadess net>
- To: Ted Gould <ted gould cx>
- Cc: GNOME, List <desktop-devel-list gnome org>, Colin Walters <walters verbum org>
- Subject: Re: application indicators
- Date: Thu, 18 Feb 2010 18:54:40 +0000
On Thu, 2010-02-18 at 12:46 -0600, Ted Gould wrote:
> On Thu, 2010-02-18 at 13:32 -0500, Colin Walters wrote:
> > But, do we agree that it makes sense for this to be in GTK+ (at least
> > under #ifdef X11)? Ted seemed to say "maybe". If we agree roughly
> > on that, then do we want a cycle where we port a bunch of apps and
> > components to use libappindicator, only to change it again when it
> > moves in GTK+?
> Yes, I think GTK/glib is a good place. One of the big blockers is the
> requirement for DBus, which is going into those guys, but I'm not sure
> of the schedule for when that'll happen. I may be totally wrong here,
> but I'm just not sure how the schedules align.
> I think that, as long as the APIs are really similar, porting from
> libappindicator to the GAppIndicator (or whatever) shouldn't be too
> difficult. That being said, how can we make sure the APIs are really
The problem isn't porting apps, it's supporting 2
similar-but-not-quite-the-same APIs. People that made the jump will feel
aggrieved if they need to port their apps again.
Have you done any research on what Windows or MacOS X provide in that
area, for applications to use? How do the APIs differ?
Whether dbus is available or not right now in the GTK+ (or GLib) stack
is an implementation detail.
] [Thread Prev