[KDE/Mac] Review Request 120437: [OS X] patchset to make QtCurve 1.8.18+ build and work

Tue Sep 30 18:39:53 UTC 2014

> On Sept. 30, 2014, 7:28 p.m., Yichao Yu wrote:
> > CMakeLists.txt, line 27
> > <https://git.reviewboard.kde.org/r/120437/diff/2/?file=315817#file315817line27>
> >
> >     I see your point. It's fine on Qt4, where you know what the backend is at compile time. However, it is probably not possible on Qt5, and this behavior is introduced precisely to take that into account (all the `qtcX11*` calls are no-op unless it is enabled at compile time and is initialized at runtime).
> >     
> >     Also these are not really Qt/X11 code.
> >     They are not Qt since they are provided by `libqtcurve-utils` which doesn't link to Qt.
> >     They are not X11 on OSX since `libqtcurve-utils` is not linked to X11 on OSX either...
> >     
> >     The Qt/X11 calls are indeed filtered out. The Qt::X11 part is filtered out at initialization time (see `qt4/style/qtcurve_plugin.cpp`) and the X11(xcb) part is filtered out in `libqtcurve-utils` (see `lib/utils/x11utils.c`) which makes all x11 calls no-op when xcb is not found or disabled.
> 
> René J.V. Bertin wrote:
>     Heh, whatever backend Qt5 uses on OS X (raster or OpenGL), it is certainly not X11, on that platform we can be quite sure about that!
>     
>     > They are not X11 on OSX since libqtcurve-utils is not linked to X11 on OSX either...
>     
>     You think so? ;)
>     
>     ``` bash
>     > otool -L /opt/local/lib/libqtcurve-utils.dylib
>     /opt/local/lib/libqtcurve-utils.1.0.dylib:
>             /opt/local/lib/libqtcurve-utils.1.dylib (compatibility version 1.0.0, current version 1.0.0)
>             /opt/local/MacPorts/lib/libX11-xcb.1.dylib (compatibility version 2.0.0, current version 2.0.0)
>             /opt/local/MacPorts/lib/libX11.6.dylib (compatibility version 10.0.0, current version 10.0.0)
>             /opt/local/lib/libxcb.1.dylib (compatibility version 3.0.0, current version 3.0.0)
>             /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)
>             /opt/local/lib/libgcc/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
>     > otool -L /opt/local/lib/libxcb.1.dylib
>     /opt/local/lib/libxcb.1.dylib:
>             /opt/local/lib/libxcb.1.dylib (compatibility version 3.0.0, current version 3.0.0)
>             /opt/local/lib/libXau.6.dylib (compatibility version 7.0.0, current version 7.0.0)
>             /opt/local/lib/libXdmcp.6.dylib (compatibility version 7.0.0, current version 7.0.0)
>             /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)
>     ```
> 
> Yichao Yu wrote:
>     Actually by backend I mean the window system qpa plugin, which is probably quartz on OSX?
>     
>     = = .... I didn't know that libxcb is actually presented on OSX.... anyway ... it doesn't hurt to do this on Qt4....
>     
>     For Qt5, the issue is that there isn't a way at all to figure out at compile time whether it will run on X11 (even on Linux). But unless someone failed to compile qtcurve-qt5 on OSX, I won't worry about it ......
> 
> René J.V. Bertin wrote:
>     Ah, in my own testing I set `ENABLE_X11=OFF` when building for Qt5. For now it's not possible to build for both Qt4 and Qt5 at the same time, at least not using MacPorts. I noticed it is on Linux; I presume the build system relies on qtchooser to get version-specific behaviour out of the same qmake programme?
> 
> Yichao Yu wrote:
>     I honestly has no idea about how it find the right version. The only thing I do in QtCurve is to use `find_package(Qt{4,5}*)` in the sub directories.
>     
>     On Linux, they don't interact with each other if I do it this way. I won't be really surprise if they do interact on other systems.
>     
>     I want to compile both (actually three including the gtk2 version) at the same time because I don't want to compile with three different settings to see if I've broken sth. It shouldn't be a big deal otherwise.

I'll see if I can find an answer in the build log on my linux box, but I presume it works like I said. qtchooser is basically a wrapper that you can give the name of a Qt application, and will then launch the true binary in `.../qt4` or `.../qt5` as a function of the argument you run it with. So yes, it supposes you have Qt4 and Qt5 installed in parallel and with a bit of 'glue' allowing cmake and other build systems to chose the version on the fly.
Someday we'll have something similar in MacPorts on OS X.

- René J.V.

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/120437/#review67692
-----------------------------------------------------------

On Sept. 30, 2014, 7:07 p.m., René J.V. Bertin wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120437/
> -----------------------------------------------------------
> 
> (Updated Sept. 30, 2014, 7:07 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X, André Marcelo Alvarenga, Yuri Chornoivan, and Yichao Yu.
> 
> 
> Repository: qtcurve
> 
> 
> Description
> -------
> 
> KDE is built on a cross-platform framework, and as such most applications (not directly linked to the Plasma desktop or X11) function or can be made to function fine.
> Qt will use a native style by default, but supports the same style plugins as it does on other platforms, which bring the advantage of better (more precise) and more compact layout, without by definition reducing integration with the OS X desktop.
> 
> As such, QtCurve 1.8.14 worked "out of the box" (http://kde-look.org/content/show.php?content=40492, source from http://craigd.wikispaces.com/file/view) and I created a MacPorts port for it (https://trac.macports.org/ticket/44527). With the `kde4-workspace` port installed, one has almost the full customisation experience, minus everything window-manager related of course, nor full control of window backgrounds (not allowed by Qt and/or OS X).
> 
> The current version, which has seen many changes that require X11, was less straightforward to get to work, requiring a considerable collection of small changes.
> 
> The brunt of the present patchset consists of making the code in question conditional on the presence of `Q_WS_X11`, `Q_OS_MAC`, `__MACH__` or `__APPLE__` in non Qt code and `APPLE` in the cmake files. A few patches introduce functions not available on OS X (getline) or replace them with OS X specifics (`clock_gettime` -> `mach_absolute_timer`, nicely initialised with a dylib constructor function :) ) while others simply ensure that header files are found (or inexistent ones ignored).
> The only functional guess/change I made is in `setOpacityProp()`, where I added a `w->setWindowOpacity( 0.01 * opacity )` for non Q_WS_X11 code, presuming that `prop` is simply on the 0-100 percentage as exposed in the preferences dialog.
> 
> 
> Diffs
> -----
> 
>   CMakeLists.txt f76fd1b 
>   gtk2/common/config_file.c d732ca9 
>   gtk2/style/CMakeLists.txt 01e8891 
>   gtk2/style/qt_settings.c f5a5c98 
>   lib/cairo/CMakeLists.txt c66c63c 
>   lib/utils/CMakeLists.txt 15757ed 
>   lib/utils/color.h 2c7081f 
>   lib/utils/map.c a829e9e 
>   lib/utils/process.c f2490ef 
>   lib/utils/timer.c 879451e 
>   qt4/config/CMakeLists.txt 15454e6 
>   qt4/config/exportthemedialog.h 42590ec 
>   qt4/config/exportthemedialog.cpp f39b86d 
>   qt4/kwin/CMakeLists.txt 654604b 
>   qt4/kwinconfig/CMakeLists.txt cbd8b62 
>   qt4/style/CMakeLists.txt f38d029 
>   qt4/style/qtcurve.cpp 7346c2f 
>   qt4/style/qtcurve_plugin.cpp f390da4 
>   qt5/CMakeLists.txt 1d0359e 
>   qt5/style/CMakeLists.txt b6cb222 
> 
> Diff: https://git.reviewboard.kde.org/r/120437/diff/
> 
> 
> Testing
> -------
> 
> On OS X 10.6.8 against kdelibs 4.14.1 and Qt 4.8.6 . This OS requires to build v1.8.18 with a gcc version from MacPorts in order to get the necessary C++11 support; newer OS versions will use a recent clang version (system compiler).
> 
> - Qt4/KDE4 support: OK (see screenshot)
> - GTk2 support: OK
> - X11 support: builds but I have no idea what it's supposed to do
> - Qt5 support: OK (against Qt 5.3.1 obtained with Digia's installer)
> 
> I tested building on Linux (Kubuntu 14.04, KDE SC 4.13.3, using clang 3.4) after the 2nd update to the patchset and that worked fine.
> One issue that could use attention is the Qt5 detection: Qt5.3 is apparently required and `ENABLE_QT5` is not unset when an earlier Qt5 version is found instead.
> 
> 
> File Attachments
> ----------------
> 
> sample showing a native file dialog for comparison
>   https://git.reviewboard.kde.org/media/uploaded/files/2014/09/30/02545bef-04d2-4a45-8955-e13bf7d063a0__Screen_shot_2014-09-30_at_14.05.54.png
> KDE4 systemsettings and the QtCurve configuration dialog
>   https://git.reviewboard.kde.org/media/uploaded/files/2014/09/30/fe5564f2-5e4e-485a-96d7-d192ff104261__QtCurve-1818.png
> KDE4 systemsettings and QtCurve config dialog with QtCuve 1.8.14, for comparison
>   https://git.reviewboard.kde.org/media/uploaded/files/2014/09/30/6bd8dd5a-9b94-43c3-88d9-c9be32a56b72__QtCurve-1814.png
> a little convenience file for uploading to RB from KDevelop
>   https://git.reviewboard.kde.org/media/uploaded/files/2014/09/30/39207a85-4092-4ea1-a181-051d0db5bb96__.reviewboardrc
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-mac/attachments/20140930/c22bb2d7/attachment-0001.html>