Re: [E-devel] RFC - Dropping Xembed support from E20
Hello.
On 03/11/14 17:10, Tom Hacohen wrote:
Adding e-users to CC.
On 03/11/14 15:58, Tom Hacohen wrote:
Appindicator: dis is a specification that start by the KDE devs a while
back, and was adopted by unity/ubuntu. It's essentially a dbus api,
which means the shell (enlightenment) has more control regarding look,
feel and behaviour, and makes the shelf more consistent among apps.
We have code for that in the E systray module. Anyone tested if that
really works?
I haveinstalled libappindicator and libappindicator-{gtk3,sharp}
I have not been able to let anything show up there. A good tip for an
application that uses it and will show up there?
Maybe I'm just using the wrong ones. Tested with Xchat, Tomboy
evolution, Thunderbird and Fifrefox. Maybe I miss the fancy stuff.
regards
Stefan Schmidt
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC - Dropping Xembed support from E20
2014-11-05 10:27 GMT-03:00 Stefan Schmidt ste...@datenfreihafen.org: Xchat Xchat is broken[1]. Try Hexchat. [1] http://sourceforge.net/p/xchat/bugs/1416/ -- Vinícius dos Santos Oliveira https://about.me/vinipsmaker -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC - Dropping Xembed support from E20
Hello. On 05/11/14 14:38, Vinícius dos Santos Oliveira wrote: 2014-11-05 10:27 GMT-03:00 Stefan Schmidt ste...@datenfreihafen.org: Xchat Xchat is broken[1]. Try Hexchat. [1] http://sourceforge.net/p/xchat/bugs/1416/ This bugs refers to the xembed systray stuff not the appindicator I was writing about. I have xembed disabled so it would never show up for me. regards Stefan Schmidt -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC - Dropping Xembed support from E20
I no longer use systray in any form or function but i do remember that all elm apps function correctly with the new api as does the Steam client. -- Regards, Alex-P. Natsios (a.k.a Drakevr) -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC - Dropping Xembed support from E20
Tested with Xchat, Tomboy evolution, Thunderbird and Fifrefox Actually, I can't find anything which works without Xembed, even with the libraries installed. I thought that the Network Manager Applet did but I was mistaken. I still had Xembed enabled although I thought I had disabled it. KeePassX, YUM-Extender and Network Manager all use the systray with Xembed enabled but not without it. I do not see any way to get Thunderbird or Firefox to use the systray. It would be a useful feature for Thunderbird, to indicate that you have new mail, but I don't see any point for Firefox. YUM-Extender does not use it in a useful way. Opening KeePassX from the systray icon avoids having to re-enter the master password. Network Manager is the only one that uses the systray in a really useful way, if you are doing WiFi. Mike -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC - Dropping Xembed support from E20
In Fedora, installing libappindicator and libappindicator-gtk3 makes the Network Manager Applet work without Xembed but the systray is all messed up. The first app loaded works properly but when you load additional apps, you get distorted and overlapping icons which do not go away entirely when the app is closed. Restarting E fixes the current problems but everything goes South again the next time you make any change to the systray. At any rate, it works a lot better with Xembed. AppIndicator probably needs more work before Xembed is eliminated. Mike -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC - Dropping Xembed support from E20
On 04/11/14 11:00, Michael Hughes wrote: In Fedora, installing libappindicator and libappindicator-gtk3 makes the Network Manager Applet work without Xembed but the systray is all messed up. The first app loaded works properly but when you load additional apps, you get distorted and overlapping icons which do not go away entirely when the app is closed. Restarting E fixes the current problems but everything goes South again the next time you make any change to the systray. At any rate, it works a lot better with Xembed. AppIndicator probably needs more work before Xembed is eliminated. Please report bugs. The thing about appindicator is that it's very easy to debug and solve (compared to xembed). -- Tom. -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC - Dropping Xembed support from E20
what about having an option like?: --enable-xembed (makes traditional systray to work in a ugly way) and so having it disabled by default, but optional for who needs it i personally think that if we restrict some usabilities, ppl will move to, let's say kde or gnome just because it makes its needs working 2014-11-04 12:52 GMT+01:00 Tom Hacohen tom.haco...@samsung.com: On 04/11/14 11:00, Michael Hughes wrote: In Fedora, installing libappindicator and libappindicator-gtk3 makes the Network Manager Applet work without Xembed but the systray is all messed up. The first app loaded works properly but when you load additional apps, you get distorted and overlapping icons which do not go away entirely when the app is closed. Restarting E fixes the current problems but everything goes South again the next time you make any change to the systray. At any rate, it works a lot better with Xembed. AppIndicator probably needs more work before Xembed is eliminated. Please report bugs. The thing about appindicator is that it's very easy to debug and solve (compared to xembed). -- Tom. -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC - Dropping Xembed support from E20
Date: Tue, 4 Nov 2014 20:18:48 +0100 From: thanatermesis.e...@gmail.com To: enlightenment-devel@lists.sourceforge.net Subject: Re: [E-devel] RFC - Dropping Xembed support from E20 what about having an option like?: --enable-xembed (makes traditional systray to work in a ugly way) and so having it disabled by default, but optional for who needs it i personally think that if we restrict some usabilities, ppl will move to, let's say kde or gnome just because it makes its needs working I think you missed the part about KDE dropping this completely as well. -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC - Dropping Xembed support from E20
Hello, On Tue, Nov 4, 2014 at 8:18 PM, Thanatermesis thanatermesis.e...@gmail.com wrote: what about having an option like?: --enable-xembed (makes traditional systray to work in a ugly way) and so having it disabled by default, but optional for who needs it i personally think that if we restrict some usabilities, ppl will move to, let's say kde or gnome just because it makes its needs working They wont go to KDE for that purpose : https://plus.google.com/+MartinGr%C3%A4%C3%9Flin/posts/7YpzTNC3WF6 I think it is a very good opportunity for all desktop environment to phase it out. Everyone agree everywhere that it is broken. Only a few application resist doing the change. The more environment there is that doesn't work for them the more they will be forced into fixing their application. So I am also all for permanently phasing it out, no matter the cost ! If you have application requiring xembed, open a bug on the application side to move away from it. That's the best course of action. You have time until the release of E20... 2014-11-04 12:52 GMT+01:00 Tom Hacohen tom.haco...@samsung.com: On 04/11/14 11:00, Michael Hughes wrote: In Fedora, installing libappindicator and libappindicator-gtk3 makes the Network Manager Applet work without Xembed but the systray is all messed up. The first app loaded works properly but when you load additional apps, you get distorted and overlapping icons which do not go away entirely when the app is closed. Restarting E fixes the current problems but everything goes South again the next time you make any change to the systray. At any rate, it works a lot better with Xembed. AppIndicator probably needs more work before Xembed is eliminated. Please report bugs. The thing about appindicator is that it's very easy to debug and solve (compared to xembed). -- Tom. -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Cedric BAIL -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] RFC - Dropping Xembed support from E20
Hey everyone, After fairly long chats with Carsten and Mike during LinuxCon and over IRC, trying to fix systray on my own, and better understanding the systray landscape, I've also switched to the drop-xembed camp. Introduction: For those of you who don't know, there are currently two main ways for implementing systray in Linux, Xembed (legacy) and appindicator (fairly new). Xembed: this is the legacy way of doing it. An application which wants to have a systray icon creates a small (22x22 px) window which gets embedded into the systray gadget. This is a window like any other, so for better or worse, everything is user controlled, including ugly inconsistent behaviour. To make things even worse, those windows usually don't have a transparent background, but instead use hacks to determine what solid colour background they should use, making themability, something we care about a lot in E, suck. Appindicator: dis is a specification that start by the KDE devs a while back, and was adopted by unity/ubuntu. It's essentially a dbus api, which means the shell (enlightenment) has more control regarding look, feel and behaviour, and makes the shelf more consistent among apps. Major issues with Xembed: Apart from the issues mentioned above, xembed is also broken because it (obviously) doesn't work under wayland, it doesn't work with higher dpi screens (remember the 22x22 restriction?), clients implement it in a hacky way, and that means servers have to adapt, making it very painful to support, and last, but not least, it's considered obsolete by many people in the Linux world, namely us. Rest of the ecosystem: From what I understand, KDE5 will have no xembed support, Unity already doesn't support it, and I hope we and many others will follow. I don't remember the exact list, but from the kde blog (see link below) and off the top of my head, in elm we only support appindicator for systray, most Qt and GTK+ apps support it, dropbox and steam also use it, so it's really just skype that's broken, I'd complain to support and get it working. If you encounter anything else that doesn't, just open a ticket at the respective project. But why not just fix the systray module? It's a lot of work and it's just not worth it since there is a better and widely used alternative out there. I also tried writing a module to embed a standalone systray into our shelves only to find out that all the standalone systrays suck. :) I wanted to port the e17 systray module to e20, but according to Mike, that won't work, as there are many issues with the compositor interactions. Essentially, unless we come across a reasonable reason why Xembed support shouldn't be dropped, I suggest we go on and get rid of it in the next week or two. References: http://blog.martin-graesslin.com/blog/2014/03/system-tray-in-plasma-next/ Thanks. -- Tom. -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC - Dropping Xembed support from E20
+1 I hope it dies a quick but very Painful death !! dh On 11/03/2014 10:58 AM, Tom Hacohen wrote: Hey everyone, After fairly long chats with Carsten and Mike during LinuxCon and over IRC, trying to fix systray on my own, and better understanding the systray landscape, I've also switched to the drop-xembed camp. Introduction: For those of you who don't know, there are currently two main ways for implementing systray in Linux, Xembed (legacy) and appindicator (fairly new). Xembed: this is the legacy way of doing it. An application which wants to have a systray icon creates a small (22x22 px) window which gets embedded into the systray gadget. This is a window like any other, so for better or worse, everything is user controlled, including ugly inconsistent behaviour. To make things even worse, those windows usually don't have a transparent background, but instead use hacks to determine what solid colour background they should use, making themability, something we care about a lot in E, suck. Appindicator: dis is a specification that start by the KDE devs a while back, and was adopted by unity/ubuntu. It's essentially a dbus api, which means the shell (enlightenment) has more control regarding look, feel and behaviour, and makes the shelf more consistent among apps. Major issues with Xembed: Apart from the issues mentioned above, xembed is also broken because it (obviously) doesn't work under wayland, it doesn't work with higher dpi screens (remember the 22x22 restriction?), clients implement it in a hacky way, and that means servers have to adapt, making it very painful to support, and last, but not least, it's considered obsolete by many people in the Linux world, namely us. Rest of the ecosystem: From what I understand, KDE5 will have no xembed support, Unity already doesn't support it, and I hope we and many others will follow. I don't remember the exact list, but from the kde blog (see link below) and off the top of my head, in elm we only support appindicator for systray, most Qt and GTK+ apps support it, dropbox and steam also use it, so it's really just skype that's broken, I'd complain to support and get it working. If you encounter anything else that doesn't, just open a ticket at the respective project. But why not just fix the systray module? It's a lot of work and it's just not worth it since there is a better and widely used alternative out there. I also tried writing a module to embed a standalone systray into our shelves only to find out that all the standalone systrays suck. :) I wanted to port the e17 systray module to e20, but according to Mike, that won't work, as there are many issues with the compositor interactions. Essentially, unless we come across a reasonable reason why Xembed support shouldn't be dropped, I suggest we go on and get rid of it in the next week or two. References: http://blog.martin-graesslin.com/blog/2014/03/system-tray-in-plasma-next/ Thanks. -- Tom. -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC - Dropping Xembed support from E20
Adding e-users to CC. On 03/11/14 15:58, Tom Hacohen wrote: Hey everyone, After fairly long chats with Carsten and Mike during LinuxCon and over IRC, trying to fix systray on my own, and better understanding the systray landscape, I've also switched to the drop-xembed camp. Introduction: For those of you who don't know, there are currently two main ways for implementing systray in Linux, Xembed (legacy) and appindicator (fairly new). Xembed: this is the legacy way of doing it. An application which wants to have a systray icon creates a small (22x22 px) window which gets embedded into the systray gadget. This is a window like any other, so for better or worse, everything is user controlled, including ugly inconsistent behaviour. To make things even worse, those windows usually don't have a transparent background, but instead use hacks to determine what solid colour background they should use, making themability, something we care about a lot in E, suck. Appindicator: dis is a specification that start by the KDE devs a while back, and was adopted by unity/ubuntu. It's essentially a dbus api, which means the shell (enlightenment) has more control regarding look, feel and behaviour, and makes the shelf more consistent among apps. Major issues with Xembed: Apart from the issues mentioned above, xembed is also broken because it (obviously) doesn't work under wayland, it doesn't work with higher dpi screens (remember the 22x22 restriction?), clients implement it in a hacky way, and that means servers have to adapt, making it very painful to support, and last, but not least, it's considered obsolete by many people in the Linux world, namely us. Rest of the ecosystem: From what I understand, KDE5 will have no xembed support, Unity already doesn't support it, and I hope we and many others will follow. I don't remember the exact list, but from the kde blog (see link below) and off the top of my head, in elm we only support appindicator for systray, most Qt and GTK+ apps support it, dropbox and steam also use it, so it's really just skype that's broken, I'd complain to support and get it working. If you encounter anything else that doesn't, just open a ticket at the respective project. But why not just fix the systray module? It's a lot of work and it's just not worth it since there is a better and widely used alternative out there. I also tried writing a module to embed a standalone systray into our shelves only to find out that all the standalone systrays suck. :) I wanted to port the e17 systray module to e20, but according to Mike, that won't work, as there are many issues with the compositor interactions. Essentially, unless we come across a reasonable reason why Xembed support shouldn't be dropped, I suggest we go on and get rid of it in the next week or two. References: http://blog.martin-graesslin.com/blog/2014/03/system-tray-in-plasma-next/ Thanks. -- Tom. -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC - Dropping Xembed support from E20
2014-11-03 15:58 GMT+00:00 Tom Hacohen tom.haco...@samsung.com: Hey everyone, After fairly long chats with Carsten and Mike during LinuxCon and over IRC, trying to fix systray on my own, and better understanding the systray landscape, I've also switched to the drop-xembed camp. Introduction: For those of you who don't know, there are currently two main ways for implementing systray in Linux, Xembed (legacy) and appindicator (fairly new). Xembed: this is the legacy way of doing it. An application which wants to have a systray icon creates a small (22x22 px) window which gets embedded into the systray gadget. This is a window like any other, so for better or worse, everything is user controlled, including ugly inconsistent behaviour. To make things even worse, those windows usually don't have a transparent background, but instead use hacks to determine what solid colour background they should use, making themability, something we care about a lot in E, suck. Appindicator: dis is a specification that start by the KDE devs a while back, and was adopted by unity/ubuntu. It's essentially a dbus api, which means the shell (enlightenment) has more control regarding look, feel and behaviour, and makes the shelf more consistent among apps. Major issues with Xembed: Apart from the issues mentioned above, xembed is also broken because it (obviously) doesn't work under wayland, it doesn't work with higher dpi screens (remember the 22x22 restriction?), clients implement it in a hacky way, and that means servers have to adapt, making it very painful to support, and last, but not least, it's considered obsolete by many people in the Linux world, namely us. Rest of the ecosystem: From what I understand, KDE5 will have no xembed support, Unity already doesn't support it, and I hope we and many others will follow. I don't remember the exact list, but from the kde blog (see link below) and off the top of my head, in elm we only support appindicator for systray, most Qt and GTK+ apps support it, dropbox and steam also use it, so it's really just skype that's broken, I'd complain to support and get it working. If you encounter anything else that doesn't, just open a ticket at the respective project. But why not just fix the systray module? It's a lot of work and it's just not worth it since there is a better and widely used alternative out there. I also tried writing a module to embed a standalone systray into our shelves only to find out that all the standalone systrays suck. :) I wanted to port the e17 systray module to e20, but according to Mike, that won't work, as there are many issues with the compositor interactions. Essentially, unless we come across a reasonable reason why Xembed support shouldn't be dropped, I suggest we go on and get rid of it in the next week or two. I say, kill it with fire :) References: http://blog.martin-graesslin.com/blog/2014/03/system-tray-in-plasma-next/ Thanks. -- Tom. -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel D5 -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC - Dropping Xembed support from E20
2014-11-03 16:58 GMT+01:00 Tom Hacohen tom.haco...@samsung.com: Hey everyone, After fairly long chats with Carsten and Mike during LinuxCon and over IRC, trying to fix systray on my own, and better understanding the systray landscape, I've also switched to the drop-xembed camp. Introduction: For those of you who don't know, there are currently two main ways for implementing systray in Linux, Xembed (legacy) and appindicator (fairly new). Xembed: this is the legacy way of doing it. An application which wants to have a systray icon creates a small (22x22 px) window which gets embedded into the systray gadget. This is a window like any other, so for better or worse, everything is user controlled, including ugly inconsistent behaviour. To make things even worse, those windows usually don't have a transparent background, but instead use hacks to determine what solid colour background they should use, making themability, something we care about a lot in E, suck. Appindicator: dis is a specification that start by the KDE devs a while back, and was adopted by unity/ubuntu. It's essentially a dbus api, which means the shell (enlightenment) has more control regarding look, feel and behaviour, and makes the shelf more consistent among apps. Major issues with Xembed: Apart from the issues mentioned above, xembed is also broken because it (obviously) doesn't work under wayland, it doesn't work with higher dpi screens (remember the 22x22 restriction?), clients implement it in a hacky way, and that means servers have to adapt, making it very painful to support, and last, but not least, it's considered obsolete by many people in the Linux world, namely us. Rest of the ecosystem: From what I understand, KDE5 will have no xembed support, Unity already doesn't support it, and I hope we and many others will follow. I don't remember the exact list, but from the kde blog (see link below) and off the top of my head, in elm we only support appindicator for systray, most Qt and GTK+ apps support it, dropbox and steam also use it, so it's really just skype that's broken, I'd complain to support and get it working. If you encounter anything else that doesn't, just open a ticket at the respective project. But why not just fix the systray module? It's a lot of work and it's just not worth it since there is a better and widely used alternative out there. I also tried writing a module to embed a standalone systray into our shelves only to find out that all the standalone systrays suck. :) I wanted to port the e17 systray module to e20, but according to Mike, that won't work, as there are many issues with the compositor interactions. Essentially, unless we come across a reasonable reason why Xembed support shouldn't be dropped, I suggest we go on and get rid of it in the next week or two. Personally I rely on XEmbed for Dropbox and NetworkManager, googling a bit it seems they should both works using appindicator, but I have nothing in my tray if I disable the xembed option... I do not see anything without xembed...is my appindicator tray support broken, what is needed to make the systray module appindicator-able? does it need the libappindicator package? how can I test appindicator? Any suggestion are welcome References: http://blog.martin-graesslin.com/blog/2014/03/system-tray-in-plasma-next/ Thanks. -- Tom. -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC - Dropping Xembed support from E20
Den Nov 3, 2014 kl. 19:59 skrev Davide Andreoli d...@gurumeditation.it: 2014-11-03 16:58 GMT+01:00 Tom Hacohen tom.haco...@samsung.com: Hey everyone, After fairly long chats with Carsten and Mike during LinuxCon and over IRC, trying to fix systray on my own, and better understanding the systray landscape, I've also switched to the drop-xembed camp. Introduction: For those of you who don't know, there are currently two main ways for implementing systray in Linux, Xembed (legacy) and appindicator (fairly new). Xembed: this is the legacy way of doing it. An application which wants to have a systray icon creates a small (22x22 px) window which gets embedded into the systray gadget. This is a window like any other, so for better or worse, everything is user controlled, including ugly inconsistent behaviour. To make things even worse, those windows usually don't have a transparent background, but instead use hacks to determine what solid colour background they should use, making themability, something we care about a lot in E, suck. Appindicator: dis is a specification that start by the KDE devs a while back, and was adopted by unity/ubuntu. It's essentially a dbus api, which means the shell (enlightenment) has more control regarding look, feel and behaviour, and makes the shelf more consistent among apps. Major issues with Xembed: Apart from the issues mentioned above, xembed is also broken because it (obviously) doesn't work under wayland, it doesn't work with higher dpi screens (remember the 22x22 restriction?), clients implement it in a hacky way, and that means servers have to adapt, making it very painful to support, and last, but not least, it's considered obsolete by many people in the Linux world, namely us. Rest of the ecosystem: From what I understand, KDE5 will have no xembed support, Unity already doesn't support it, and I hope we and many others will follow. I don't remember the exact list, but from the kde blog (see link below) and off the top of my head, in elm we only support appindicator for systray, most Qt and GTK+ apps support it, dropbox and steam also use it, so it's really just skype that's broken, I'd complain to support and get it working. If you encounter anything else that doesn't, just open a ticket at the respective project. But why not just fix the systray module? It's a lot of work and it's just not worth it since there is a better and widely used alternative out there. I also tried writing a module to embed a standalone systray into our shelves only to find out that all the standalone systrays suck. :) I wanted to port the e17 systray module to e20, but according to Mike, that won't work, as there are many issues with the compositor interactions. Essentially, unless we come across a reasonable reason why Xembed support shouldn't be dropped, I suggest we go on and get rid of it in the next week or two. Personally I rely on XEmbed for Dropbox and NetworkManager, googling a bit it seems they should both works using appindicator, but I have nothing in my tray if I disable the xembed option... I do not see anything without xembed...is my appindicator tray support broken, what is needed to make the systray module appindicator-able? does it need the libappindicator package? how can I test appindicator? Any suggestion are welcome I've tested network manager with app indicator. There is a library which reads a gtk menu from network manager and provides it over dbus. It works, but has some quirks. Doesn't seem to update correctly all the time, but maybe a newer version is fine. Using Ubuntu. Sebastian -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
