elementary-dev-community team mailing list archive

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

2013/8/14 Akshay Shekher <voldyman666@xxxxxxxxx>

> I wanted to talk about the features to be added in wingpanel for L+1.
> the blueprints that i have in mind are.
> 1. Hide on Maximize<https://blueprints.launchpad.net/wingpanel/+spec/hide-on-maximize>
> 2. Branch Ayatana<https://blueprints.launchpad.net/wingpanel/+spec/branch-ayatana>
>
>
> *Hide on maximize* is easy. we just have to add a d-bus signal to gala
> which will be triggered when a window is maximized, wingpanel will connect
> to this signal when launched and whenever  an event is triggered wingpanel
> will hide.
> for hiding i was thinking of using clutter animations or something similar.
>

This is easy to code but hard to design. I'm not sure it's a good idea
because it could block the close/unmaximize buttons.

There also was talk of including some of the indicators into the titlebar
(e.g. sound volume for Audience, network and sound volume for Midori, etc),
but the doom of the titlebar is uncertain.


> *Branch Ayatana*: this was discussed earlier but no decision was made, we
> could use libpeas to make indicators as plugins. This is easy and good
> reliable indicator/plugins can be made but this creates problems for
> applications that want to show indicators, as for wingpanel to show an
> indicator a plug would have to be made and it would need to enabled from
> dconf.
>
> There are many ways to solve this problem.
> 1. use two libraries. one for system indicators and one for app indicators
> 2. use something similar to switchboard's plugins system.
> 3. don't allow application indicators. (which i think gnome follows)
>

As far as application indicators go, I like the "plug to support
AppIndicators" approach. Such things are already done for GNOME2, XFCE and
maybe LXDE panels. I'm inclined to think that we don't need application
indicators at all, because the dock already gives us everything an
indicator would. We just have to be able to keep the app icon in the dock
and we're good. My design for such things was implemented in Noise and
Birdie, although Noise used minimizing to keep itself in dock which was
ultimately reverted.

If I'm right on this one, we can just keep support for application
indicators in a system indicator (plug) or behind conditional compilation,
for compatibility with e.g. Dropbox on Ubuntu but avoiding a hard
dependency on Ayatana libraries at the same time.

If I'm wrong, i.e. it make sense to adopt application indicators in our
design, then we can just make another system indicator to house
GtkStatusIcon indicators and call the problem solved - we'd support both
existing indicator APIs in that case.

It's not that simple with system indicators though. Last time I checked the
problem with using Ayatana for *system* indicators was that it's a complex
and poorly documented process, to the point when Canonical themselves use
app indicator API for system indicators just to keep it simpler, and this
messes things up. Patching Ubuntu system indicators to look okay is also a
PITA because it's a moving target and the indicators are written in C which
is a bit too low-level for such things.

So we could probably go all "screw this, we're making our own system
indicator framework" and just go for completely custom system indicators
not dependent on the mess Ubuntu got in there. But there are several
problems with this.

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?

-- 
Sergey "Shnatsel" Davidoff
OS architect @ elementary