On Fri, Jan 23, 2015 at 9:59 PM, Alexis Lopez Zubieta
wrote:
> Hello friends:
> I would like to discuss with you the future of the lxqt-panel systemTray.
> As you must know the traditional implementation is made using xembed this
> is no longer supported in Wayland or Mir. Now the KDE (1) and Ubu
Alexis, see discussion here: https://github.com/lxde/lxqt/issues/359
Paulo Lieuthier
On 01/23/2015 10:59 AM, Alexis Lopez Zubieta wrote:
> Hello friends:
> I would like to discuss with you the future of the lxqt-panel systemTray. As
> you must know the traditional implementation is made using xe
Hi John:
The "loadable module architecture" approach works but there are not fully
functional plug-ins yet due that I'm alone in this task. And PCmanFM is a tough
guy. I may need some help from the different module developers in order to get
all the pieces together. It may also require a bit of
Sorry for my last (weird) mail.
I don't understand what actually happen to this "$#!%". Here's what i meant:
"Hi,
Now that everybody is talking about the next 0.9 release, i'm curios to know
what's the state of the loadable module architecture approach.
Is there anything done for 0.9 or is it
Hello friends:
I would like to discuss with you the future of the lxqt-panel systemTray. As
you must know the traditional implementation is made using xembed this is no
longer supported in Wayland or Mir. Now the KDE (1) and Ubuntu (2) guys have an
alternative for this "Status Notifier" and "App
Hi,
Now that everybody is talking about the next 0.9 release, i'm curios to know what's the state of the loadable module architecture approach.
Is there anything done for 0.9 or is it still in the experiment's room?
--
Hi.
As of now lxde-applications.menu comprises lines
Graphics
Utility
due to which e. g. desktop entry files stating both Graphics and Utility
in "Categories" are shown as "Accessories" only in LXQt, not in "Graphics".
That "Not" line was committed by PCManFM some years ago.
It af
