Re: [Elementary-dev-community] (the indicators situation) XFCE next release approaching, they hope to port to gtk3 afterwards

2014-08-18 Thread Sergio Costas 

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 > 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

2014-08-11 Thread Sergio Costas 
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é 
 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 > 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.

Re: [Elementary-dev-community] (the indicators situation) XFCE next release approaching, they hope to port to gtk3 afterwards

2014-08-09 Thread Cameron Norman 
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é 
 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  
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

2014-08-08 Thread Daniel Foré 
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 
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

2014-08-08 Thread Sergio Costas 

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

2014-07-28 Thread Sergey "Shnatsel" Davidoff 
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