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?
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. 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 ;-) 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. 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
