On Tuesday 08 April 2014 20:17:43 PCMan wrote: > 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.
right, I agree with that. Important is to get out the assumption that X11 is the only possible window system. This can be rather painful... > > > 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. Have a look at KF5: KWindowSystem became a tier1 framework depending only on Qt (Widgets and X11Extras or WinExtras). I would be very happy if you can make use of it and if you need anything or have suggestions to improve the API, please tell me (I'm the official maintainer of that framework). The NETWM classes are indeed rather low level and are not intended to be used by applications. KWindowSystem and KWindowInfo should wrap most useful stuff. Cheers Martin
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ 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
