← Back to team overview

elementary-dev-community team mailing list archive

Re: (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 <rastersoft@xxxxxxxxx <mailto:rastersoft@xxxxxxxxx>> 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)
    raster@xxxxxxxxxxxxxx               http://www.rastersoft.com




--
Nos leemos
		         RASTER    (Linux user #228804)
raster@xxxxxxxxxxxxxx              http://www.rastersoft.com


References