Re: application indicators

2010-02-21 Thread Dylan McCall
> > If it hasn't been discussed, maybe worth some pondering, and if it has > > in recent history, I for one would love to know the verdict :) > > I don't think I've discussed it with regards to Application Indicators, > but the issue that I've always had

Re: application indicators

2010-02-19 Thread Nathaniel McCallum
On 02/19/2010 08:23 AM, Matthew Paul Thomas wrote: Nathaniel McCallum wrote on 19/02/10 07:39: ... I'd like to take the opportunity to talk about apps that may not fit the AppInd model. We have two basic goals here in replacing the notification area: 1. Make interaction with panel items more

Re: application indicators

2010-02-19 Thread Ted Gould
worth some pondering, and if it has > in recent history, I for one would love to know the verdict :) I don't think I've discussed it with regards to Application Indicators, but the issue that I've always had with emblems is that they look "bolted on." So overall, the desig

Re: application indicators

2010-02-19 Thread Dylan McCall
> Currently we generate a StatusIcon on the fly by rendering into a > pixbuf. This icon contains the color of the highest event severity > and the number of events of this severity. Using the AppInd model, we > would be required to generate roughly 5k icons just for this display > (5 status col

Re: application indicators

2010-02-19 Thread Matthew Paul Thomas
Nathaniel McCallum wrote on 19/02/10 07:39: >... > I'd like to take the opportunity to talk about apps that may not fit > the AppInd model. We have two basic goals here in replacing the notification area: 1. Make interaction with panel items more consistent. Clean up the swamp where some ite

Re: application indicators

2010-02-19 Thread Steve Frécinaux
On 02/18/2010 07:32 PM, 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 ch

Re: application indicators

2010-02-18 Thread Nathaniel McCallum
On Thu, Feb 18, 2010 at 12:25 PM, Colin Walters wrote: > On the subject of the Ubuntu application indicators work: > > https://wiki.ubuntu.com/DesktopExperienceTeam/ApplicationIndicators > > First, +5000 that this change is being driven by designers, and +1000 > that new us

Re: application indicators

2010-02-18 Thread Matthias Clasen
On Thu, Feb 18, 2010 at 6:12 PM, Ted Gould wrote: > > I think that the API is probably a little bit off topic for this list > though, so I'd invite everyone interested over the Ayatana list to hash > through it a little bit more. > >   http://launchpad.net/~ayatana > If you want something includ

Re: application indicators

2010-02-18 Thread Ted Gould
On Thu, 2010-02-18 at 18:54 +, Bastien Nocera wrote: > Have you done any research on what Windows or MacOS X provide in that > area, for applications to use? How do the APIs differ? We weren't trying to match an API or duplicate one from OSX or Windows. What we were targeting is having a unifi

Re: application indicators

2010-02-18 Thread Ted Gould
On Thu, 2010-02-18 at 13:57 -0500, Colin Walters wrote: > On Thu, Feb 18, 2010 at 1:46 PM, Ted Gould wrote: > > Yes, I think GTK/glib is a good place. One of the big blockers is the > > requirement for DBus, > > Yes, clearly having glib-dbus in the stack today would help a lot; > however gvfs al

Re: application indicators

2010-02-18 Thread Frederic Peters
Matthias Clasen wrote: > Whether the design needs change or not needs to be evaluated in the > context of gnome-shell, of course. This would be much easier if the > development for app-indicators hadn't happened behind closed doors. > > Just adding app-indicators as an external dep. now without w

Re: application indicators

2010-02-18 Thread Matthias Clasen
On Thu, Feb 18, 2010 at 1:57 PM, Colin Walters wrote: > On Thu, Feb 18, 2010 at 1:46 PM, Ted Gould wrote: >> 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 s

Re: application indicators

2010-02-18 Thread Colin Walters
On Thu, Feb 18, 2010 at 1:46 PM, Ted Gould wrote: > > I'll ping usability and see if we can get this on the agenda for the > usability hackfest next week. Awesome! > Yes, I think GTK/glib is a good place.  One of the big blockers is the > requirement for DBus, Yes, clearly having glib-dbus in t

Re: application indicators

2010-02-18 Thread Bastien Nocera
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 whe

Re: application indicators

2010-02-18 Thread Ted Gould
On Thu, 2010-02-18 at 13:32 -0500, Colin Walters wrote: > >> * It'd be really nice to get some discussion of how this fits in with > >> the design plans for GNOME Shell (note that in GNOME 2 if applications > >> use this, you have potentially *3* representations of an application > >> in the top pa

Re: application indicators

2010-02-18 Thread Colin Walters
On Thu, Feb 18, 2010 at 1:11 PM, Jorge O. Castro wrote: > > We have put together a design guide for application authors here: > https://wiki.ubuntu.com/CustomStatusMenuDesignGuidelines > Feedback on this would be appreciated. Thanks, yes this is useful. >> * It'd be really nice to get some discu

Re: application indicators

2010-02-18 Thread Jorge O. Castro
On Thu, Feb 18, 2010 at 12:25 PM, Colin Walters wrote: > Now, both of those said, I have two issues I'd like to bring up. Hi Colin, thanks for bringing this up. > * In the big picture, is this something we're recommending all > applications to use?  Some?  Only ones which send notifications? We

application indicators

2010-02-18 Thread Colin Walters
Hi, On the subject of the Ubuntu application indicators work: https://wiki.ubuntu.com/DesktopExperienceTeam/ApplicationIndicators First, +5000 that this change is being driven by designers, and +1000 that new useful code is being written. There are definite problems being solved here. Now