← Back to team overview

unity-design team mailing list archive

Re: Design discussion proposals for Christmas

 

> > 1 - Application indicators optional by design.
> > 
> > (...)
> 
> I'd support this as a design goal, but I don't think that it's something
> we could enforce on the library side of things.  The only thing I think
> we could do is allow users to block particular applications like Win7
> does.  But, personally, I think that's a hack that's caused by closed
> source software -- MS can't fix things, and so they have to block it at
> the tray level.  We can fix it, and I think we should :)

But *can* the current specification fix this for closed-source apps like
Skype? The reason I ask (and forgive me if I'm wrong) is that
Application Indicators seem to solve the problem of notification area
consistency but not the problem of notification area abuse. Even if
Skype were to follow the libappindicator API to the letter, it could
still *force* an indicator icon to appear, and this is something that
displeases a lot of users.

> > 2 - Evolution and Ayatana
> > 
> > (...)
> 
> Yes, I'd say that the Evolution API is limiting some things.  I'm not a
> Thunderbird fan, but I'd be more than happy to help anyone wanting to
> try and write a libindicate extension for it.

There's been some progress in https://launchpad.net/libnotify-mozilla.
Indicators are being the focus of current trunk development.

Another alternative is investing heavily in integrating webmail with
the applet.

> > 3 - Raising awareness
> > 
> > (...)
> 
> Yeah, we've been thinking about this a lot.  One of the things that the
> Canonical Design team is talking about is a shared blog.  I like that,
> but I have a hard enough time writing on my own blog :(  I'm not sure if
> there's some way that this could be a way to work in a collaborative
> way?  Perhaps "official" wiki entries that start out and are discussed
> on this list?  I think that someone reading this probably has a good
> idea, please reply :)

I'd like to also mention the need of easily reachable and constantly
updated (perhaps automatically generated) API documentation, to avoid
making good-intentioned developers hit on a brick wall, as seen here:

http://bleedingpaper.com/2009/10/23/call-for-help-getting-gm-notify-ready-for-karmic/




Follow ups

References