Re: [Elementary-dev-community] (the indicators situation) XFCE next release approaching, they hope to port to gtk3 afterwards
Hi Daniel: Ok, now I understand what you mean with that (I needed to do a full demo code to discover it :( ). El 09/08/14 a las #4, Daniel Foré escribió: The big problem is that GTK.Popover cannot be a top level window and granite popover is intended to be deprecated. Cheers, Daniel Foré elementaryos.org On Fri, Aug 8, 2014 at 10:53 AM, Sergio Costas rasters...@gmail.com mailto:rasters...@gmail.com wrote: Hi: I've been thinking about this, and want to propose an idea. But before writing code, I prefer to comment it first, just in case someone finds something that could prevent it from being useful. At first I considered the idea of using libpeas to add the indicators directly as part of the bar, but then I realized that it's not a good idea because a bug in any indicator (which are always pieces of software delivered by third parties and without the same quality control) would crash the entire bar, which is not desirable. The idea of exporting the indicator using DBus is good, but has the problem that it needs a lot of work in order to embed any widget and send them through the bus (like the famous libido). But then I realized that the only API needed over DBus is the one to put an icon in the bar, and also a DBus callback to inform the indicator that the user clicked on it. The popup itself can be painted directly by the indicator app, because it is a new window, and inside it can be painted any standard widget. This way, wingpanel (or whatever indicator bar used by the user) only needs to offer an API to add an icon inside, and a DBus signal to inform the indicator app that it must show/hide its popup (and also other to enable/disable an icon, and so on, but the API would be very small). The advantages are several: * Developing the library would be extremely easy, and also its maintenance, because it is extremely lightweight. * It won't use XEmbedd or other X-specific mechanisms, which means that it would be fully compatible with Wayland without changing a line. * By copying the client API from libappindicator, it is possible to have binary compatibility with libappindicator applications: the client code would send over DBus the petition to put the icon in the bar, and will wait for click events. When they arrive, it would create a popup with the menu created by the appindicator application. Critics? Change proponsals? Am I completely off-topic? El 28/07/14 a las #4, Sergey Shnatsel Davidoff escribió: Thanks for the info! I wonder if indicators themselves were ported to GTK3 though. Another suggestion I've heard recently is looking into MATE indicators. But this is all Freya+1 stuff so I'll investigate it only after Freya is released. If anyone's interested in the situation with indicators, I've detailed it here: https://bbs.archlinux.org/viewtopic.php?pid=1439765#p1439765 -- Sergey Shnatsel Davidoff -- Nos leemos RASTER(Linux user #228804) ras...@rastersoft.com http://www.rastersoft.com -- Nos leemos RASTER(Linux user #228804) ras...@rastersoft.com http://www.rastersoft.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] (the indicators situation) XFCE next release approaching, they hope to port to gtk3 afterwards
You are right. I presumed that Gtk.Popover had a similar API to the Gtk.Menu, but it is quite different. Anyway, I have another idea, and this time I have some demonstration code as a proof of concept. Basically, Gtk has everything needed to allow certain remote access to widgets in an easy way: you can read and write public properties using a string with the property name (and nearly all the useful data in a widget is stored in properties), you can create GUIs from textual representations using Gtk.Builder, you can get access to the widgets in those GUIs referring to them by its name contained in a string, and you can connect signals passing its name in a string. So the idea is to create a class that encapsulates a Gtk.Builder. This class is exported using DBus, and allows to load an UI from a file or from a textual representation sent with DBus. It also allows to read or write any public property in any of the widgets, referencing them by name thanks to Gtk.Builder. Finally, when a widget emits one of the specified signals, it would send a DBus signal indicating it. As I commented, I created a little proof of concept, and in fact it is so simple that I don't understand why this is not part of Gtk... You can find it at https://github.com/rastersoft/dbuilder There is a little README file with the instructions. So the idea would be to create a bar with one icon per indicator, and a popover for each one. And the content of each popover could be managed this way. More critics? More change proponsals? (BTW... I LOVE FREYA!) El 09/08/14 a las #4, Cameron Norman escribió: I also believe there would be a few issues with the placement of the pointer from the popover to the parent. I have know idea what to call it except a triangle haha. If it was its own window it would have no idea where to place that (or place itself for that matter). Have a great weekend, -- Cameron El vie, 8 de ago 2014 a las 9:33 , Daniel Foré dan...@elementaryos.org escribió: The big problem is that GTK.Popover cannot be a top level window and granite popover is intended to be deprecated. Cheers, Daniel Foré elementaryos.org On Fri, Aug 8, 2014 at 10:53 AM, Sergio Costas rasters...@gmail.com mailto:rasters...@gmail.com wrote: Hi: I've been thinking about this, and want to propose an idea. But before writing code, I prefer to comment it first, just in case someone finds something that could prevent it from being useful. At first I considered the idea of using libpeas to add the indicators directly as part of the bar, but then I realized that it's not a good idea because a bug in any indicator (which are always pieces of software delivered by third parties and without the same quality control) would crash the entire bar, which is not desirable. The idea of exporting the indicator using DBus is good, but has the problem that it needs a lot of work in order to embed any widget and send them through the bus (like the famous libido). But then I realized that the only API needed over DBus is the one to put an icon in the bar, and also a DBus callback to inform the indicator that the user clicked on it. The popup itself can be painted directly by the indicator app, because it is a new window, and inside it can be painted any standard widget. This way, wingpanel (or whatever indicator bar used by the user) only needs to offer an API to add an icon inside, and a DBus signal to inform the indicator app that it must show/hide its popup (and also other to enable/disable an icon, and so on, but the API would be very small). The advantages are several: * Developing the library would be extremely easy, and also its maintenance, because it is extremely lightweight. * It won't use XEmbedd or other X-specific mechanisms, which means that it would be fully compatible with Wayland without changing a line. * By copying the client API from libappindicator, it is possible to have binary compatibility with libappindicator applications: the client code would send over DBus the petition to put the icon in the bar, and will wait for click events. When they arrive, it would create a popup with the menu created by the appindicator application. Critics? Change proponsals? Am I completely off-topic? El 28/07/14 a las #4, Sergey Shnatsel Davidoff escribió: Thanks for the info! I wonder if indicators themselves were ported to GTK3 though. Another suggestion I've heard recently is looking into MATE indicators. But this is all Freya+1 stuff so I'll investigate it only after Freya is released. If anyone's interested in the situation with indicators, I've detailed it here: https://bbs.archlinux.org/viewtopic.php?pid=1439765#p1439765 -- Sergey Shnatsel Davidoff -- Nos leemos RASTER
Re: [Elementary-dev-community] (the indicators situation) XFCE next release approaching, they hope to port to gtk3 afterwards
I also believe there would be a few issues with the placement of the pointer from the popover to the parent. I have know idea what to call it except a triangle haha. If it was its own window it would have no idea where to place that (or place itself for that matter). Have a great weekend, -- Cameron El vie, 8 de ago 2014 a las 9:33 , Daniel Foré dan...@elementaryos.org escribió: The big problem is that GTK.Popover cannot be a top level window and granite popover is intended to be deprecated. Cheers, Daniel Foré elementaryos.org On Fri, Aug 8, 2014 at 10:53 AM, Sergio Costas rasters...@gmail.com wrote: Hi: I've been thinking about this, and want to propose an idea. But before writing code, I prefer to comment it first, just in case someone finds something that could prevent it from being useful. At first I considered the idea of using libpeas to add the indicators directly as part of the bar, but then I realized that it's not a good idea because a bug in any indicator (which are always pieces of software delivered by third parties and without the same quality control) would crash the entire bar, which is not desirable. The idea of exporting the indicator using DBus is good, but has the problem that it needs a lot of work in order to embed any widget and send them through the bus (like the famous libido). But then I realized that the only API needed over DBus is the one to put an icon in the bar, and also a DBus callback to inform the indicator that the user clicked on it. The popup itself can be painted directly by the indicator app, because it is a new window, and inside it can be painted any standard widget. This way, wingpanel (or whatever indicator bar used by the user) only needs to offer an API to add an icon inside, and a DBus signal to inform the indicator app that it must show/hide its popup (and also other to enable/disable an icon, and so on, but the API would be very small). The advantages are several: * Developing the library would be extremely easy, and also its maintenance, because it is extremely lightweight. * It won't use XEmbedd or other X-specific mechanisms, which means that it would be fully compatible with Wayland without changing a line. * By copying the client API from libappindicator, it is possible to have binary compatibility with libappindicator applications: the client code would send over DBus the petition to put the icon in the bar, and will wait for click events. When they arrive, it would create a popup with the menu created by the appindicator application. Critics? Change proponsals? Am I completely off-topic? El 28/07/14 a las #4, Sergey Shnatsel Davidoff escribió: Thanks for the info! I wonder if indicators themselves were ported to GTK3 though. Another suggestion I've heard recently is looking into MATE indicators. But this is all Freya+1 stuff so I'll investigate it only after Freya is released. If anyone's interested in the situation with indicators, I've detailed it here: https://bbs.archlinux.org/viewtopic.php?pid=1439765#p1439765 -- Sergey Shnatsel Davidoff -- Nos leemos RASTER(Linux user #228804) ras...@rastersoft.com http://www.rastersoft.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] (the indicators situation) XFCE next release approaching, they hope to port to gtk3 afterwards
The big problem is that GTK.Popover cannot be a top level window and granite popover is intended to be deprecated. Cheers, Daniel Foré elementaryos.org On Fri, Aug 8, 2014 at 10:53 AM, Sergio Costas rasters...@gmail.com wrote: Hi: I've been thinking about this, and want to propose an idea. But before writing code, I prefer to comment it first, just in case someone finds something that could prevent it from being useful. At first I considered the idea of using libpeas to add the indicators directly as part of the bar, but then I realized that it's not a good idea because a bug in any indicator (which are always pieces of software delivered by third parties and without the same quality control) would crash the entire bar, which is not desirable. The idea of exporting the indicator using DBus is good, but has the problem that it needs a lot of work in order to embed any widget and send them through the bus (like the famous libido). But then I realized that the only API needed over DBus is the one to put an icon in the bar, and also a DBus callback to inform the indicator that the user clicked on it. The popup itself can be painted directly by the indicator app, because it is a new window, and inside it can be painted any standard widget. This way, wingpanel (or whatever indicator bar used by the user) only needs to offer an API to add an icon inside, and a DBus signal to inform the indicator app that it must show/hide its popup (and also other to enable/disable an icon, and so on, but the API would be very small). The advantages are several: * Developing the library would be extremely easy, and also its maintenance, because it is extremely lightweight. * It won't use XEmbedd or other X-specific mechanisms, which means that it would be fully compatible with Wayland without changing a line. * By copying the client API from libappindicator, it is possible to have binary compatibility with libappindicator applications: the client code would send over DBus the petition to put the icon in the bar, and will wait for click events. When they arrive, it would create a popup with the menu created by the appindicator application. Critics? Change proponsals? Am I completely off-topic? El 28/07/14 a las #4, Sergey Shnatsel Davidoff escribió: Thanks for the info! I wonder if indicators themselves were ported to GTK3 though. Another suggestion I've heard recently is looking into MATE indicators. But this is all Freya+1 stuff so I'll investigate it only after Freya is released. If anyone's interested in the situation with indicators, I've detailed it here: https://bbs.archlinux.org/viewtopic.php?pid=1439765#p1439765 -- Sergey Shnatsel Davidoff -- Nos leemos RASTER(Linux user #228804) ras...@rastersoft.com http://www.rastersoft.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
[Elementary-dev-community] (the indicators situation) XFCE next release approaching, they hope to port to gtk3 afterwards
One interesting thing I read in this XFCE announcement [0] was that xfce's panel has added support for gtk3 plugins. Although I have not looked much into it, afaics the architecture of xfce's panel is similar to the indicators-as-libsoup-plugins idea that I heard floating around a few months ago on this ML. In any case, I thought it was worth bringing up, since maintaining indicators alone would not be a good idea, and the current indicators, from what I hear, are not sustainable. [0] http://blog.alteroot.org/articles/2014-07-26/news-from-xfce.html Good evening, -- Cameron Norman -- 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] (the indicators situation) XFCE next release approaching, they hope to port to gtk3 afterwards
Thanks for the info! I wonder if indicators themselves were ported to GTK3 though. Another suggestion I've heard recently is looking into MATE indicators. But this is all Freya+1 stuff so I'll investigate it only after Freya is released. If anyone's interested in the situation with indicators, I've detailed it here: https://bbs.archlinux.org/viewtopic.php?pid=1439765#p1439765 -- Sergey Shnatsel Davidoff -- 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
