Re: kguiaddons uses qpa headers?
On Sunday 23 February 2014 17:02:55 John Layt wrote: Hi, I'm building all of Frameworks from scratch for the first time, using the openSUSE packages for Qt 5.2, and qguiaddons fails with: [ 24%] Building CXX object src/CMakeFiles/KF5GuiAddons.dir/util/kmodifierkeyinfoprovider_x11.cpp.o /media/build/kdesrc- build/src/k5/frameworks/kguiaddons/src/util/kmodifierkeyinfoprovider_x11.cpp :26:42: fatal error: qpa/qplatformnativeinterface.h: No such file or directory This is because qpa headers are considered private and are packaged separately by openSUSE. I'm not sure depending on private/qpa headers is such a good thing? Or is there no other option here? For kguiaddons there's an alternative, linking to QX11Extras (breaking the rules about the dependencies for an addon). This is starting to make me wonder if we couldn't change Qt to set a property on qApp with the values of Display* and/or xcb connection. But personally I would just link to QX11Extras. *However* note that another framework, called frameworkintegration, *does* require the private qpa headers, since it provides a platform theme plugin. No way around that there. You need to install the package with the Qt private headers. -- 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: kguiaddons uses qpa headers?
On Sunday 23 February 2014 17:47:48 David Faure wrote: On Sunday 23 February 2014 17:02:55 John Layt wrote: Hi, I'm building all of Frameworks from scratch for the first time, using the openSUSE packages for Qt 5.2, and qguiaddons fails with: [ 24%] Building CXX object src/CMakeFiles/KF5GuiAddons.dir/util/kmodifierkeyinfoprovider_x11.cpp.o /media/build/kdesrc- build/src/k5/frameworks/kguiaddons/src/util/kmodifierkeyinfoprovider_x11.c pp :26:42: fatal error: qpa/qplatformnativeinterface.h: No such file or directory This is because qpa headers are considered private and are packaged separately by openSUSE. I'm not sure depending on private/qpa headers is such a good thing? Or is there no other option here? For kguiaddons there's an alternative, linking to QX11Extras (breaking the rules about the dependencies for an addon). Well I wanted to use QX11Extras but was told to not use it for that reason ;-) This is starting to make me wonder if we couldn't change Qt to set a property on qApp with the values of Display* and/or xcb connection. I doubt that's a real solution as there are more things available in the native interface which might really be needed if one uses low level X11 code. But of course there's QX11Extras for that. 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: kguiaddons uses qpa headers?
On Sunday, 2014-02-23, 17:02:55, John Layt wrote: Hi, I'm building all of Frameworks from scratch for the first time, using the openSUSE packages for Qt 5.2, and qguiaddons fails with: [ 24%] Building CXX object src/CMakeFiles/KF5GuiAddons.dir/util/kmodifierkeyinfoprovider_x11.cpp.o /media/build/kdesrc- build/src/k5/frameworks/kguiaddons/src/util/kmodifierkeyinfoprovider_x11.cpp :26:42: fatal error: qpa/qplatformnativeinterface.h: No such file or directory This is because qpa headers are considered private and are packaged separately by openSUSE. I'm not sure depending on private/qpa headers is such a good thing? Or is there no other option here? I am not sure it is wise to consider the QPA headers as private, most of them are not. QPlatformInterface, for example, is clearly an exposed type, there is an accessor in QGuiApplication that returns a pointer to it. Obviously the returned object and its functionality is platform specific, but afterall its very purpose is to enable platform integration that goes beyond the things that can be wrapped in an abstraction across multiple platforms. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring 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: kguiaddons uses qpa headers?
On Sunday 23 February 2014 17:47:48 David Faure wrote: On Sunday 23 February 2014 17:02:55 John Layt wrote: Hi, I'm building all of Frameworks from scratch for the first time, using the openSUSE packages for Qt 5.2, and qguiaddons fails with: [ 24%] Building CXX object src/CMakeFiles/KF5GuiAddons.dir/util/kmodifierkeyinfoprovider_x11.cpp.o /media/build/kdesrc- build/src/k5/frameworks/kguiaddons/src/util/kmodifierkeyinfoprovider_x11.c pp :26:42: fatal error: qpa/qplatformnativeinterface.h: No such file or directory This is because qpa headers are considered private and are packaged separately by openSUSE. I'm not sure depending on private/qpa headers is such a good thing? Or is there no other option here? For kguiaddons there's an alternative, linking to QX11Extras (breaking the rules about the dependencies for an addon). This is starting to make me wonder if we couldn't change Qt to set a property on qApp with the values of Display* and/or xcb connection. But personally I would just link to QX11Extras. Still you were the one with the very strict view on the *addons ones. :-) Let's go for QX11Extras, but it has to be an optional dependency. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com 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
