On 09/29/2011 02:43 PM, ext Girish Ramakrishnan wrote: > Hi, > > On Thu, Sep 29, 2011 at 5:25 PM, Paul Olav Tvete<[email protected]> wrote: >> On Thursday 29 September 2011 13:33:28 ext Thiago Macieira wrote: >>> A wayland server has nothing to do with the wayland plugin to lighthouse, >>> aside from the fact that they speak the same protocol and may be using the >>> same low-level library. >> >> The "low-level library" in question is Qt :p >> >> Samuel used this example to show that being able to use two different >> platform >> plugins on the same system, without having to have two separate >> installations of >> Qt, is not just a cool geeky feature: it's absolutely essential for the >> Wayland >> use case. >> >> Once you have chosen to use Qt on Wayland, the only sane choice is to use Qt >> to >> implement your compositor too. I mean, we use Qt because we don't actually >> enjoy >> low-level C programming. The Wayland compositor will then be run with a >> command >> line like >> >> qwindow-compositor -platform eglfs -plugin linuxinputmouse >> >> while the client will do something like >> >> hellowindow -platform wayland >> >> Exactly the same Qt libraries involved, but two different lighthouse >> back-ends. >> > > Yes, this is a very good reason to have platform plugins. > > As I explained a little more on irc, I wanted to see if we could build > the lighthouse code as (dynamic) plugins with just -nokia-developer > builds. For normal builds, it would compile them statically and an app > could figure which platform was in use using ifdefs. This way I could > do in the app code > #ifdef QPA_X11 > #include<Xlib.h> > #elif defined(QPA_XCB) > ... > #endif > With the current approach to platforms as plugins, the app has to load > symbols dynamically OR link to both Xlib+Xcb.
In this case you might be able to use the X display and Xlib whether the xcb or xlib plugin is being used, since xcb is also using Xlib internally for _some_ stuff that's not supported by pure xcb (like GLX). > Just to take my idea to conclusion before we kill it, can the wayland > and eglfs platforms be merged into one :) ? i.e we have a QPA_WAYLAND > and the platform plugin code itself determines what "mode" it is > (presumably by passing some command line option). In some ways this is > like the -qws option where the server and client reside in same > library. It's possible, but might lead to slightly messier plugin code and is less practical during development since it makes it harder to test the application against multiple backends (both wayland and using the same backend the compositor uses to run non-composited). We also test qt-compositor using at least xcb, xlib, kms, openwf backends, not just eglfs. And since you're in charge of configuring Qt in this case it's still up to you to "know" which platform plugin is being used. In the end, if you have the power to do a static build where the plugin is known at compile time, you probably also have the power to limit yourself to that plugin whether it's done statically or dynamically. -- Samuel _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
