On Tue, Apr 8, 2014 at 1:48 AM, Martin Gräßlin <mgraess...@kde.org> wrote: > On Monday 07 April 2014 17:55:39 Jerome Leclanche wrote: >> On Mon, Apr 7, 2014 at 5:44 PM, PCMan <pcman...@gmail.com> wrote: >> > Hello, >> > For smoother migration toward Qt5 and Wayland, I'd like to propose >> > splitting Xfitman from liblxqt. >> > >> > The rationale. >> > 1. Due to Xfitman, liblxqt depends on Xlib now. All programs using >> > liblxqt got the indirect dependency on Xlib, too. Actually, many of >> > them only requires LxQt::Settings. >> > >> > 2. Actually, every Qt programs are using liblxqt implicitly since our >> > Qt platform plugin reads LxQt settings using liblxqt and apply the >> > settings to other Qt programs. >> > >> > 3. The only components that use Xfitman are: lxqt-panel (very heavy >> > use), app switcher (used 4 methods), notification daemon (used 2-3 >> > methods), and runner (used 2 methods only). Other components depending >> > on liblxqt does not require X11 at all. >> > >> > 4. Xfitman will stop working in Qt5 and Wayland. Qt5 uses xcb, and X11 >> > event filters work differently, giving us xcb event structures, not >> > XEvent. In the Wayland/weston world, xdg_shell will be used to replace >> > some of the functionality of NETWM. EWMH will stop working. The >> > desktop panel may need to be a compositor plugin in wayland, too. So >> > this part is hard to port to wayland. It might be needed to add a >> > layer of abstraction around Xfitman and avoid touching X11 directly to >> > ease the porting. >> > >> > Any comments? >> > As the developer of Xfitman, Alexander Sokoloff, do you have any >> > suggestions? >> > >> > Thank you all! >> >> (Point of note: Let's stop including the razor-qt ML for anything that >> doesn't really concern both projects if possible) >> >> I think getting rid of xfitman is the only way forward. >> We talked about having a full-blown QPA plugin for this sort of thing. >> I don't know how KDE does it - Martin Graesslin probably knows; CC'd, >> any comments on this?
I'd say it's not so urgent to get rid of Xfitman. It's clear that X11 will stay for a while. Some very important applications, such as LibreOffice and GIMP do not support wayland at all. LibreOffice uses its own GUI toolkit based on X11 so upgrading to gtk+ 3 or qt 5 won't help. There are still many frequently used programs using gtk+ 2 and Qt 4. For example, Google chrome, and the porting to gtk+ 3 progressed very slowly. It also uses its own paint engine. So, they'll need to support wayland, which is not a trivial tasks. To sum up, it's not possible to dump X11 in the near future. Of course there is xwayland, but this actually runs wayland + X server, which IMHO is not better than running X alone. While keeping wayland in mind, we need to make sure we have a release that works pretty well with X11 now. > As I don't know what xfitman is, I doubt I can give a proper answer. AFAIU the > question is how we handle the usage of X11 and Wayland at the same time? Our > libraries will get runtime selection where possible - an example can be seen > in kwindowsystem framework. Depending on the runtime platform we select a > different backend. Xfitman is the "kwindowsystem" of LxQt. It's a thin Qt wrapper around some EWMH/NETWM stuff. It provides less features than kwindowsystem does, but it's lighter. > For the communication desktop shell <-> kwin we haven't done anything yet as > KWin is not yet able to handle Wayland clients. The idea is to add very > specific interfaces which will only handle this communication. This will > probably be done in very local abstractions (e.g. just in libtaskmanager). I > don't think that real abstractions can be used as Wayland and X11 are too > different and would reduce the usage on the least common denominator. Which > means if one wants to use all the power of Wayland one has to try to get rid > of X11 as quickly as possible ;-) At least we need to getting rid of Xlib and stop assuming that we have X11 running. Qt 5 uses xcb and can switch between different backends. I only want to make less components depending on X. X should still be supported as long as it's being used widely. I just explained why X11 will not die. > I'm not sure what is meant with QPA plugin. It could be either the > implementation of the windowing system - that's something you clearly don't > want. I toy with the idea to do that for KWin, but am rather scared of it as > it's not BC and a lot of work. And there's the platform theme. That's > something we have in the frameworksintegration framework, but it's not > powerful enough to abstract away the differences between X11 and Wayland. Well, I only hope that kwindowsystem can become desktop agnostic and does not depend on kde libs. So we can reuse that nice module. Currently KWinInfo and KWindowSystem uses a lot of things from kde libs. The raw NETWM implementation is low level and hard to use. Using it defet the purpose of not touching X11 directly. Cheers! > Cheers > Martin > ------------------------------------------------------------------------------ > Put Bad Developers to Shame > Dominate Development with Jenkins Continuous Integration > Continuously Automate Build, Test & Deployment > Start a new project now. Try Jenkins in the cloud. > http://p.sf.net/sfu/13600_Cloudbees > _______________________________________________ > Lxde-list mailing list > Lxde-list@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/lxde-list > ------------------------------------------------------------------------------ Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees _______________________________________________ Lxde-list mailing list Lxde-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxde-list
