Re: [Elementary-dev-community] Future of Wingpanel
Sergey, What do you mean by 'embedding indictors into apps'? Does it mean one installs for example Noise and the soundindicator is installed as well but not as a separate package? If that's the case, what if a user wants to install another music player which makes use of the sound indicator? Additionally, how difficult will it be/ what effort will it take to backport upstream changes made to for example the sound indicator to the particular apps? Regards Kurt On 26-08-13 11:04, Sergey Shnatsel Davidoff wrote: [...] 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 -- 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
Re: [Elementary-dev-community] Future of Wingpanel
Kurt, What Sergey means is having apps, like Audience (and I think Pantheon-Greeter as well), which have a fullscreen mode (which hides wingpanel), which can still display indicators that are essential to them. So for the video-player Audience it is handy to still provide access to the sound indicator such that it can be used for adjusting the volume. Kind regards, Pim Vullers On 08/26/2013 01:22 PM, Kurt Smolderen wrote: Sergey, What do you mean by 'embedding indictors into apps'? Does it mean one installs for example Noise and the soundindicator is installed as well but not as a separate package? If that's the case, what if a user wants to install another music player which makes use of the sound indicator? Additionally, how difficult will it be/ what effort will it take to backport upstream changes made to for example the sound indicator to the particular apps? Regards Kurt On 26-08-13 11:04, Sergey Shnatsel Davidoff wrote: [...] 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 -- 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
Re: [Elementary-dev-community] Future of Wingpanel
Thanks for the clarification! On 26-08-13 13:33, Pim Vullers wrote: Kurt, What Sergey means is having apps, like Audience (and I think Pantheon-Greeter as well), which have a fullscreen mode (which hides wingpanel), which can still display indicators that are essential to them. So for the video-player Audience it is handy to still provide access to the sound indicator such that it can be used for adjusting the volume. Kind regards, Pim Vullers On 08/26/2013 01:22 PM, Kurt Smolderen wrote: Sergey, What do you mean by 'embedding indictors into apps'? Does it mean one installs for example Noise and the soundindicator is installed as well but not as a separate package? If that's the case, what if a user wants to install another music player which makes use of the sound indicator? Additionally, how difficult will it be/ what effort will it take to backport upstream changes made to for example the sound indicator to the particular apps? Regards Kurt On 26-08-13 11:04, Sergey Shnatsel Davidoff wrote: [...] 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 -- 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
Re: [Elementary-dev-community] Future of Wingpanel
Personally, I think there's no need to be complicated with the Audience stuff. When Audience is fullscreen wingpanel will just fade out, and when the user moves their mouse near wingpanel it fades back in. On Aug 26, 2013 11:33 AM, Pim Vullers p...@vullersmail.nl wrote: Kurt, What Sergey means is having apps, like Audience (and I think Pantheon-Greeter as well), which have a fullscreen mode (which hides wingpanel), which can still display indicators that are essential to them. So for the video-player Audience it is handy to still provide access to the sound indicator such that it can be used for adjusting the volume. Kind regards, Pim Vullers On 08/26/2013 01:22 PM, Kurt Smolderen wrote: Sergey, What do you mean by 'embedding indictors into apps'? Does it mean one installs for example Noise and the soundindicator is installed as well but not as a separate package? If that's the case, what if a user wants to install another music player which makes use of the sound indicator? Additionally, how difficult will it be/ what effort will it take to backport upstream changes made to for example the sound indicator to the particular apps? Regards Kurt On 26-08-13 11:04, Sergey Shnatsel Davidoff wrote: [...] 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 -- 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 -- 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
Re: [Elementary-dev-community] Future of Wingpanel
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 Maximizehttps://blueprints.launchpad.net/wingpanel/+spec/hide-on-maximize 2. Branch Ayatanahttps://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
[Elementary-dev-community] Future of Wingpanel
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 Maximizehttps://blueprints.launchpad.net/wingpanel/+spec/hide-on-maximize 2. Branch Ayatanahttps://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. *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) please tell me your opinion and suggestions guys. voldyman -- 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
Re: [Elementary-dev-community] Future of Wingpanel
I think one of the ways we can support legacy Ayatana indicators is by making a plug for it. So we'd setup wingpanel to support plug files through LibPeas. Then we would create a plug file that is used to display all Ayatana indicators from applications and the like. Native eOS Applications could utilize the new format with their own plug while still allowing graceful fallback support. Just my 2 cents. On Wed, Aug 14, 2013 at 1:29 AM, Akshay Shekher voldyman...@gmail.comwrote: 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 Maximizehttps://blueprints.launchpad.net/wingpanel/+spec/hide-on-maximize 2. Branch Ayatanahttps://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. *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) please tell me your opinion and suggestions guys. voldyman -- 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 -- *--**--** Chris Timberlake* Technical Architect Phone: 515-707-5109 gam...@gmail.com -- 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
Re: [Elementary-dev-community] Future of Wingpanel
We were just talking about this exactly with voldyman. +1 from me on this. On Wed, Aug 14, 2013 at 3:33 PM, Chris Timberlake gam...@gmail.com wrote: I think one of the ways we can support legacy Ayatana indicators is by making a plug for it. So we'd setup wingpanel to support plug files through LibPeas. Then we would create a plug file that is used to display all Ayatana indicators from applications and the like. Native eOS Applications could utilize the new format with their own plug while still allowing graceful fallback support. Just my 2 cents. On Wed, Aug 14, 2013 at 1:29 AM, Akshay Shekher voldyman...@gmail.comwrote: 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 Maximizehttps://blueprints.launchpad.net/wingpanel/+spec/hide-on-maximize 2. Branch Ayatanahttps://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. *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) please tell me your opinion and suggestions guys. voldyman -- 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 -- *--**--** Chris Timberlake* Technical Architect Phone: 515-707-5109 gam...@gmail.com -- 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 -- Alex Lourie -- 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
