elementary-dev-community team mailing list archive

["Sergey \"Shnatsel\" Davidoff" <sergey@xxxxxxxxxxxxxxxx>]

2013/8/26 Chris Timberlake <game64@xxxxxxxxx>

> *First, some indicators (e.g. keyboard and network) are really complex,
> and it took even Canonical over a year to port them to Ayatana API and get
> them more or less right. Moreover, user switching and power indicators deal
> with security, and I'm not sure we have any PolicyKit gurus to audit that.
>
> *
> *Second, we'd be making up *yet another* applet API. Come on! Isn't there
> enough of that out there already? Can we just reuse some API like XFCE
> panel applets or something? Do we really have to reimplement all those
> things yet again?*
>
> I think one of the major issues we encounter is that current AppIndicators
> don't support full widgets. In the case of Ayatana, it only supports
> Gtk.Menu. This means that very advanced and cool indicators would not be
> possible. Take for example GrowlVoice for OSX. http://www.growlvoice.com/ This
> is not something that would be possible in the current Ayatana way of doing
> things. Reinventing the wheel isn't a huge issue if you're improving the
> wheel greatly, imo.
>
> As for Ayatana, I don't see why we don't just make an indicator system,
> then make an indicator that houses Ayatana for backwards compatibility.
> Then we don't have to redo anything. We just have to put the current
> Ayatana system into a new Indicator Plug, and bam.
>

FYI, AppIndicators were introduced exactly for this purpose - make
implementing the deeply misguided design like that GrowlVoice indicator
impractical or impossible, and bring consistency to the indicators. And I'm
all for it, if it kills off junk like that.

GrowlVoice should display its messaging history in a window and the window
should pop up in the dock, with the badge displaying the number of new
messages (or threads, whatever it uses). It doesn't need an indicator *at
all*. Neither do most other apps. So Ayatana limitations are not a bug,
they're a feature, and we might choose to tighten them even more or
eradicate app indicators altogether. The question is not about app
indicators, it's about system indicators.

Voldyman showed off a cool proof of concept for libpeas-based plugs
yesterday, but it's not necessarily the best architecture if we choose to
embed indicators into apps (e.g. sound indicator in Audience). I'd like to
talk to designers first and see what are the use cases for this feature,
and if there's a sufficient number of indicators that should be embedded.
Otherwise we could use the libpeas-based architecture and simply provide
minimal D-bus interfaces to indicators like Sound.

-- 
Sergey "Shnatsel" Davidoff
OS architect @ elementary