Re: [Ayatana] Design discussion proposals for Christmas

[Mark Shuttleworth]

On 31/12/09 17:20, Conscious User wrote:
> 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.

In the case of Skype, there is now a library that we can use to
integrate it into the desktop more effectively.

Mark



signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Design discussion proposals for Christmas

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Conscious User wrote on 24/12/09 18:18:
>...
> 1 - Application indicators optional by design.
>...

 now
explicitly says "A custom status menu should be optional", and describes
what the configuration interface should look like.

- --
Matthew Paul Thomas
http://mpt.net.nz/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAktNofwACgkQ6PUxNfU6ecq1vwCfXk12ge7CMHZc14yDvhmhMxRQ
Wu0AoI/E/dZKN3RqBP/7oidobqRjj+ap
=2Pqh
-END PGP SIGNATURE-


___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Design discussion proposals for Christmas

[Conscious User]

> > 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/


___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Design discussion proposals for Christmas

[Ted Gould]

On Thu, 2009-12-24 at 16:18 -0200, Conscious User wrote:
> 1 - Application indicators optional by design.
> 
> The goals of application indicators are very ambitious, as
> they replace the systray as we know it today. With that in
> mind, I see them as a very good opportunity to solve a
> problem that has been plaguing the Desktop for years:
> applications shoving tray icons down our throats.
> 
> Unless the application resides *only* in the tray (e.g.
> nm-applet), I firmly believe a tray icon should be
> optional. If your application needs a tray icon to work
> properly, you are doing it wrong.
> 
> So I believe it would be very interesting if, by design,
> any application using libappindicator could be placed
> or removed from the tray according to the wishes of the
> user. I believe "not forcing" should be even a part of
> the spec.

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 :)

> 2 - Evolution and Ayatana
> 
> Seeing in the comments in
> https://bugs.launchpad.net/evolution-indicator/+bug/353007
> https://bugs.launchpad.net/evolution-indicator/+bug/460483
> I'm starting to wonder whether the goals of Ayatana are
> being limited by the Evolution plugin API. For example,
> it is difficult to pass message header information to
> notifications or implement close-to-tray functionality.
> 
> Being a faithful Evolution user, I never entered the
> "Thunderbird by default" bandwagon, but from an Ayatana
> perspective, Thunderbird's friendliness to extensions
> look very attractive. Of course, it creates a whole new
> set of problems such as integration with panel clock...

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.

> 3 - Raising awareness
> 
> Reading the Ubuntu forums, I noticed two interesting
> things. One: a lot of people have no idea of the rationale
> behind certain Ayatana decisions (e.g. the new bubble
> position in Karmic, how the indicator-applet works, etc.).
> Two: once explained, a lot of those people like the ideas.
> 
> I believe it is important to think about some kind of
> systematic and efficient way of make users aware of what
> has changed and is being experimented during the alphas.
> It would, at the very least, reduce the number of "the
> notification bubble seems lower than it should" bug reports.

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 :)

--Ted



signature.asc
Description: This is a digitally signed message part
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

[Ayatana] Design discussion proposals for Christmas

[Conscious User]

Hello all,

Under the light of the Christmas spirit, I'd like to kickoff
some discussions I was thinking about for a long time now.
Hopefully you'll pick up at least some of them. :)


1 - Application indicators optional by design.

The goals of application indicators are very ambitious, as
they replace the systray as we know it today. With that in
mind, I see them as a very good opportunity to solve a
problem that has been plaguing the Desktop for years:
applications shoving tray icons down our throats.

Unless the application resides *only* in the tray (e.g.
nm-applet), I firmly believe a tray icon should be
optional. If your application needs a tray icon to work
properly, you are doing it wrong.

So I believe it would be very interesting if, by design,
any application using libappindicator could be placed
or removed from the tray according to the wishes of the
user. I believe "not forcing" should be even a part of
the spec.


2 - Evolution and Ayatana

Seeing in the comments in
https://bugs.launchpad.net/evolution-indicator/+bug/353007
https://bugs.launchpad.net/evolution-indicator/+bug/460483
I'm starting to wonder whether the goals of Ayatana are
being limited by the Evolution plugin API. For example,
it is difficult to pass message header information to
notifications or implement close-to-tray functionality.

Being a faithful Evolution user, I never entered the
"Thunderbird by default" bandwagon, but from an Ayatana
perspective, Thunderbird's friendliness to extensions
look very attractive. Of course, it creates a whole new
set of problems such as integration with panel clock...


3 - Raising awareness

Reading the Ubuntu forums, I noticed two interesting
things. One: a lot of people have no idea of the rationale
behind certain Ayatana decisions (e.g. the new bubble
position in Karmic, how the indicator-applet works, etc.).
Two: once explained, a lot of those people like the ideas.

I believe it is important to think about some kind of
systematic and efficient way of make users aware of what
has changed and is being experimented during the alphas.
It would, at the very least, reduce the number of "the
notification bubble seems lower than it should" bug reports.



Merry Christmas to all!


___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp