2013/8/14 Akshay Shekher <voldyman...@gmail.com> > 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
-- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp