elementary-dev-community team mailing list archive
Mailing list archive
Re: (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,
El vie, 8 de ago 2014 a las 9:33 , Daniel Foré
The big problem is that GTK.Popover cannot be a top level window and
granite popover is intended to be deprecated.
On Fri, Aug 8, 2014 at 10:53 AM, Sergio Costas <rastersoft@xxxxxxxxx>
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
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
* 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:
Sergey "Shnatsel" Davidoff
RASTER (Linux user #228804)