Re: X11 usage in kdeinit/kinit.cpp
On Monday 17 February 2014 16:36:45 Martin Gräßlin wrote: No that doesn't work as I expect that at least during the next decade we will have both WAYLAND_DISPLAY and DISPLAY being set (DISPLAY for legacy applications which won't have a Wayland port any time soon - e.g. Qt4). Then I don't see the problem with keeping the fact that the kdeinit socket contains $DISPLAY in its name (to avoid clashes between sessions). -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Re: X11 usage in kdeinit/kinit.cpp
On Saturday 15 February 2014 20:49:39 David Faure wrote: On Thursday 13 February 2014 09:29:40 Martin Gräßlin wrote: Hi, on my quest to ensure that we can run all applications with -platform wayland if compiled with X11 support I stumbled over kinit/kdeinit/kinit.cpp which gets compiled into the kdeinit5 binary. To quote the code: // Can't use QGuiApplication::platformName() here, there is no app instance And that's kind of a global problem in that file. So I don't see how we can make a version for wayland without compiling it twice. Will we still need kdeinit5 in the future or is that something which could be killed if we improve the startup process (thus ignore the problem)? Whether the speed improvement is still worth it for starting apps is still unknown, someone should profile it properly. However it's needed for sure for kioslaves, so that they can be started and passed between processes. A similar problem is present in wrapper.cpp which gets linked into the binaries: * kwrapper5 * kshell5 * kdeinit5_shutdown * kdeinit5_wrapper wrapper.cpp assumes there is a DISPLAY env variable and even if not it's set to :0. Can't we detect that we're not on X11 simply from the fact that DISPLAY is not set? No that doesn't work as I expect that at least during the next decade we will have both WAYLAND_DISPLAY and DISPLAY being set (DISPLAY for legacy applications which won't have a Wayland port any time soon - e.g. Qt4). The current code is wrong on mac and windows too (but without a workspace, the functionality of passing slaves between apps is less used so I guess they just skip using kdeinit right now). In kdeinit.cpp it seems it's mostly for startup notification (x11 only), and some old multihead display code that screams remove me. In the other files, it's about the name of the socket to talk to kdeinit. If e.g. wayland has no such thing as a display (i.e. the possibility to run multiple sessions on the same machine), then this can just be skipped. I run into one such socket thingy and adjusted it to work on Wayland, too. It's one of the many review requests I created last week. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: X11 usage in kdeinit/kinit.cpp
- Ursprüngliche Mail - wrapper.cpp assumes there is a DISPLAY env variable and even if not it's set to :0. Can't we detect that we're not on X11 simply from the fact that DISPLAY is not set? No that doesn't work as I expect that at least during the next decade we will have both WAYLAND_DISPLAY and DISPLAY being set (DISPLAY for legacy applications which won't have a Wayland port any time soon - e.g. Qt4). Hi, wouldn't be then the assumption: if WAYLAND_DISPLAY is defined, use wayland, else use X11 work? Or would it make any sense to have that defined (in a normal user desktop) but still use X11 as default? Greetings Christoph -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Re: X11 usage in kdeinit/kinit.cpp
On Monday 17 February 2014 23:30:07 Christoph Cullmann wrote: - Ursprüngliche Mail - wrapper.cpp assumes there is a DISPLAY env variable and even if not it's set to :0. Can't we detect that we're not on X11 simply from the fact that DISPLAY is not set? No that doesn't work as I expect that at least during the next decade we will have both WAYLAND_DISPLAY and DISPLAY being set (DISPLAY for legacy applications which won't have a Wayland port any time soon - e.g. Qt4). Hi, wouldn't be then the assumption: if WAYLAND_DISPLAY is defined, use wayland, else use X11 work? Sounds dangerous to me. Or would it make any sense to have that defined (in a normal user desktop) but still use X11 as default? Well I'm just running such a setup, but I'm not sure whether my dev setup counts as a valid setup ;-) I cannot say whether that will happen or not, but overall it sounds dangerous to me to infer functionality based on whether WAYLAND_DISPLAY is defined. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
X11 usage in kdeinit/kinit.cpp
Hi, on my quest to ensure that we can run all applications with -platform wayland if compiled with X11 support I stumbled over kinit/kdeinit/kinit.cpp which gets compiled into the kdeinit5 binary. To quote the code: // Can't use QGuiApplication::platformName() here, there is no app instance And that's kind of a global problem in that file. So I don't see how we can make a version for wayland without compiling it twice. Will we still need kdeinit5 in the future or is that something which could be killed if we improve the startup process (thus ignore the problem)? A similar problem is present in wrapper.cpp which gets linked into the binaries: * kwrapper5 * kshell5 * kdeinit5_shutdown * kdeinit5_wrapper wrapper.cpp assumes there is a DISPLAY env variable and even if not it's set to :0. Any recommendations? Cheers Martin signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
