QtCurve update with support for Qt5

[RJVB (René Bertin)]

This is a proposed update for the QtCurve port.

It introduces support for Qt5 (and is "somewhat prepared" for a future appearance of KF5 in MacPorts) through a subport. Support for GTk2 is moved to a subport too, to avoid a combinatorial explosion of variants.

Thus:

• QtCurve still provides KDE4 and/or Qt4 support
• qt5-QtCurve provides Qt5 and in the future also KF5 support
• QtCurve-gtk2 provides GTk2/X11 support

I named the subports in line with what seems to be usual, i.e. a prefix for Qt5 and a suffix for GTk2.

qt5-QtCurve was tested with my own "concurrent" Qt5 install but ought to work just as well with the exclusive qt5-mac version currently in MacPorts. Ditto for QtCurve, btw.

[RJVB (René Bertin)]

this allows co-installation of GTk2, Qt4 and Qt5 specific qtcurve-utils libraries

[ryandesign (Ryan Carsten Schmidt)]

You should not set the revision field to a large number like 20150110. The revision field is meant to be a small integer, increased whenever a change is made to the port that does not involve a change to the upstream code. Since your patch does involve a change to the upstream code, the version field should be changed instead and the revision left at its default value of 0.

In the post-destroot, you have an empty block after an if statement:

            if {${subport} eq "qt5-${name}"} { 
            } else { 

This can be simplified to:

            if {${subport} ne "qt5-${name}"} { 

You're using system procedure to run the ln executable to create a symlink:

                    system "ln -s ${prefix}/lib/kde4/plugins/styles ${destroot}${qt_plugins_dir}/" 

Instead, please use the MacPorts ln procedure:

                    ln -s ${prefix}/lib/kde4/plugins/styles ${destroot}${qt_plugins_dir}/

[RJVB (René Bertin)]

Replying to ryandesign@…:

You should not set the revision field to a large number like 20150110. The revision field is meant to be a small integer, increased whenever a change is made to the port that does not involve a change to the upstream code. Since your patch does involve a change to the upstream code, the version field should be changed instead and the revision left at its default value of 0.

I know the dogma, but in this case it's impossible to change the version because the upstream version has not changed. I'd use the git commit number as a 4th version component, but those are random numbers, not monotonically increasing.

[larryv (Lawrence Velázquez)]

Replying to rjvbertin@…:

I know the dogma, but in this case it's impossible to change the version because the upstream version has not changed. I'd use the git commit number as a 4th version component, but those are random numbers, not monotonically increasing.

So add a date component to version or something. Don’t hijack revision to indicate what’s actually a new version.

[mkae (Marko Käning)]

Cc Me!

[mkae (Marko Käning)]

This relies on committing PortGroup qt5, right?!

[RJVB (René Bertin)]

That PortGroup already exists. I haven't tried, but a priori the Portfile as committed should function also with port:qt5-mac in its current, exclusive form.

[RJVB (René Bertin)]

the qt5-QtCurve subport was replaced with QtCurve-qt5

[RJVB (René Bertin)]

syncs to the latest version but depends on the patches at

[RJVB (René Bertin)]

depends on the patches at ​https://git.reviewboard.kde.org/r/122279/

[RJVB (René Bertin)]

Disregard version 20150122, this version should build as is.

[mkae (Marko Käning)]

@RJVB, your current QtCurve port has a symbolic link to Portfile-1.8.18 and tons of patches in files, but uses only 2 of those after all.

As the port also contains references to kf5 I guess we better wait until KF5 is part of MacPorts...

[RJVB (René Bertin)]

Yeah, I know I should clean out the patches, that there's no reason to keep old ones in a SVC system etcetc.

[mkae (Marko Käning)]

I'd like to commit this port as a test for the new cmake 1.1 portgroup.

Shall I simply go for the latest version present in your macstrop repo?

[RJVB (René Bertin)]

Yes. I've started cleaning up the patchfiles; you can skip the old directory and even the alt directory (contains some alternative settings that interested people might want to play with).

(I just tested QtCurve-qt5 builds fine +qtonly).

[mkae (Marko Käning)]

I guess this should not be committed as is:

if {[file exists ${filespath}/QtCurve-git/.git]} {
    git.url         ${filespath}//QtCurve-git
} else {
    git.url         git://anongit.kde.org/qtcurve.git
}

Have never seen that in an official port...

[larryv (Lawrence Velázquez)]

Do not commit development detritus to the ports repository.

[mkae (Marko Käning)]

Replying to larryv:

Do not commit development detritus to the ports repository.

That's exactly why I was asking the contributor. ;)

[mkae (Marko Käning)]

What's the secret behind the version numbering scheme here:

if {${subport} ne "${name}-gtk2"} {
    git.branch      ae2aa694d36630d0d4948a2088256dc06c4134e9
    version         ${qtc_version}.262
    epoch           2
} else {
    # newer GTk2 engine versions have issues with respecting the selected font and "icons in buttons" setting
    git.branch      e3e2325e
    version         ${qtc_version}.20150127
}

Why seems one to be some index and the other a date?

[mkae (Marko Käning)]

We'd be referencing the not (yet) existing portgroup kf5 and their ports in here:

if {(${subport} ne "${name}-gtk2") && (${subport} ne "${name}-extra")} {
    patchfiles-append       patch-qtc-no-qtc-activewin-events.diff \
                            patch-qt5-dbus-fixes-by-debian.diff
    if {${subport} eq "${name}-qt5"} {

        categories              kde kf5 qt5

        if {![variant_isset qtonly]} {
            PortGroup               kf5 1.1
            long_description        A highly configurable widget style for Qt5/KF5
            depends_build-append    port:gettext \
                                    ${kf5::pythondep}
            kf5.depends_frameworks  karchive kconfig kconfigwidgets \
                                    ki18n kdelibs4support kguiaddons kio \
                                    kiconthemes kwidgetsaddons kxmlgui

That needs mending unless we decide to commit this port only after qt5-kde(-devel) are out...

[RJVB (René Bertin)]

You already decided you wanted to wait until the KF5 frameworks were in. The least invasive way to add a protection against installing -qtonly to my version in MacStrop is to add a small block somewhere high up enough (under the test.run yes line):

if {${subport} eq "${name}-qt5"} {
    if {![variant_isset qtonly]} {
        default_variants +qtonly
    }   
}   

As to the GTk2 version version: yes, it's got a date in it. Purely historical; the GTk2 hasn't been upgraded since I changed the versioning scheme. It will move to that same scheme if I ever get around to it and figure out how to fix the regression(s) that were introduced after that Jan. 27th 2015 version. I've been meaning to do that

[mkae (Marko Käning)]

Replying to RJVB:

You already decided you wanted to wait until the KF5 frameworks were in.

You are right, but... :)

The least invasive way to add a protection against installing -qtonly to my version in MacStrop is to add a small block somewhere high up enough (under the test.run yes line):

Sounds like a good plan.

[RJVB (René Bertin)]

Yeah, there are quite a few improvements I made to QtCurve since this port was last updated, even if you build it without the KDE parts. IIRC you don't lose anything in the style itself with +qtonly, but you do lose the possibility to configure the style.

Maybe I should look into making my own stylesheet the default setting on Mac, when QtCurve is built without KDE support, what do you think?

[mkae (Marko Käning)]

Replying to RJVB:

Maybe I should look into making my own stylesheet the default setting on Mac, when QtCurve is built without KDE support, what do you think?

Why would you do that? What's the difference to the default?

[mkae (Marko Käning)]

Actually I'd be for leaving the default setting in place, so that users have the original Qt'ish look and feel. If they don't like they can use another style or complain at Qt's issue tracker about what should be improved. If we replace it here with your tweaked one we'd inhibit this (potentially useful and important) information flow.

[RJVB (René Bertin)]

I have made a QtCurve theme that matches the native Mac look as closely as possible.

We've been coining QtCurve as a Qt style that isn't subject to layout glitches (in KDE) like the native Mac style is, and it's also a style that can make cross-platform Qt applications not specifically tuned for rendering on Mac look a bit less as if they are intended for visually impaired users. (Less blown-up.)

But if you prefer QtCurve's default looks that's fine with me too, I'm not looking for extra work on this.

Edit: QtCurve's default is not a "Qt'ish look and feel". It's QtCurve. Complaints about how this looks on Qt's bug tracker will only be met with a reaction like "just don't use a custom style".

You have my KF5 ports installed, I presume including kf5-osx-integration-devel. This gives you access to my theme via the configure button in the dialog obtained with kcmshell5 style; pick the MacOSX-Graphite preset. For the complete package, pick the Mac OS X Graphite colour palette in kcmshell colors.

[mkae (Marko Käning)]

Ah yes, you are right. With Qt's original style Qt can't be run smoothly on OSX unfortunately. This might even drive users away right from the start. So, under those circumstances I believe it's better to preset your optimized style right from the start and keep an info in the port's description or its notes.

[RJVB (René Bertin)]

With Qt's original style Qt can't be run smoothly on OSX unfortunately.

That isn't really true either. The layout issues we know happened only with KDE, and have been addressed in KF5. The only issue with standard (cross-platform) Qt applications is that they tend to use the same big font (Lucida Sans 13) everywhere and use very generous widget spacing. That's what I meant with "as if designed for the visually impaired". The benefits of QtCurve +qtonly will not be as complete because the style cannot change the font used, but it should be a start.

I'll look into changing the default then. I've never touched this part of the code, so I don't know how much work it'll be.

Alternatively we could just ship a stylerc and instruct users where to install that file if they want to use it.

[mkae (Marko Käning)]

Replying to RJVB:

That isn't really true either. The layout issues we know happened only with KDE, and have been addressed in KF5.

They have been adressed, fully?

The only issue with standard (cross-platform) Qt applications is that they tend to use the same big font (Lucida Sans 13) everywhere and use very generous widget spacing. That's what I meant with "as if designed for the visually impaired".

Ah, ok.

The benefits of QtCurve +qtonly will not be as complete because the style cannot change the font used, but it should be a start.

Too bad that the font can't be selected by the theme...

I'll look into changing the default then. I've never touched this part of the code, so I don't know how much work it'll be.

OK.

Alternatively we could just ship a stylerc and instruct users where to install that file if they want to use it.

Yeah, that's what I meant above. You could place it somewhere easily accessible and teach the user.

Or, is it possible to perhaps have a variant for that purpose? (Is possibly overkill?!)

[RJVB (René Bertin)]

That isn't really true either. The layout issues we know happened only with KDE, and have been addressed in KF5.

They have been addressed, fully?

AFAIK, yes.

Looking at the code I think I'll add support for a system-wide config directory. That's going to be the easiest solution. If that leads to angry feedback we'll provide the stylerc as a template, but let's wait and see.

[RJVB (René Bertin)]

In fact, there was already a provision for reading a system-wide config file which I've resurrected and adapted. port:QtCurve-extra now installs a stylerc file there which overrides the hardwired defaults.

I'll attach 2 screenshots showing the difference.

[RJVB (René Bertin)]

QtCurve default style configuration

[RJVB (René Bertin)]

QtCurve "MacOS-Graphite" style configuration

[mkae (Marko Käning)]

In case of the metallic style it's hard to see the icons for the minimize, maximize and close buttons at the top right if the window frame but.

Otherwise it looks more Aoole'ish. :-)

[RJVB (René Bertin)]

If you're talking about the blue window title bar/frame, that's completely moot. That's part of QtCurve's window style, which is used only on X11 with the KWin window manager (and currently works only with Qt4/KDE4).

EDIT: I'm homing in on the issue that causes the current version of the GTk2 theme to misbehave. So hang on for a bit longer ;)

[RJVB (René Bertin)]

Done! As promised the subports now all use the same versioning.

Please use the occasion to push the ciment-icons port too!

[mkae (Marko Käning)]

Using your latest status from macstrop, i.e.

$ port installed QtCurve-qt5
The following ports are currently installed:
  QtCurve-qt5 @1.8.18.263_0+qt5kde (active)

For style set to "QtCurve" I just saw this strange error or warning when clicking the "Apply" button for the colors:

$ kcmshell5 colors
QFile::copy: Empty or null file name

As a result the chosen color settings were neither fully kept when clicking "Apply" nor after restarting the kcmshell, meaning its dialog window had different colors after click and after restarting the application than before clicking. This is reproducible - for the various styles the behavior is different. So, that's not really consistent yet.

Seeing errors also for the style when clicking "Apply":

$ kcmshell5 style
QFile::copy: Empty or null file name
QObject::killTimer(): Error: timer id 7 is not valid for object 0x7fd0f4008c00 (QtCurve::Style, qtcurve), timer has not been killed

[RJVB (René Bertin)]

Replying to mkae:

This is all a bit beyond the scope of this ticket (kcmshell5 is a KF5 port)!

For style set to "QtCurve" I just saw this strange error or warning when clicking the "Apply" button for the colors:

$ kcmshell5 colors
QFile::copy: Empty or null file name

I only see this when I activate the "Mac OS X Graphite" colour scheme, not with any of the others. I'll need to investigate where the warning comes from, but it appears not to have any adverse effect.

As a result the chosen color settings were neither fully kept when clicking "Apply" nor after restarting the kcmshell, meaning its dialog window had different colors after click and after restarting the application than before clicking. This is reproducible - for the various styles the behavior is different. So, that's not really consistent yet.

Do you have the osx-integration port installed? I suppose you have because otherwise changing styles in the style dialog shouldn't have any effect at all. Either way, colour schemes do not work 100% reliably, as you can see with the Wonton Soup scheme. It's less obvious when you install the scheme and then restart an application like kate5. The side-bar toolview will probably maintain a white background, but for me the rest of the application takes the Wonton colours. That could well be something hard-coded in Qt.

Qt/Mac simply seems not to like it too much when colour palettes are changed at runtime, via an external utility like kcmshell5 . Nothing that a restart can't cure, and fortunately this is not something one does very frequently. (Apps where this is more frequent usually have a menu with a list of the installed colour palettes to chose from, e.g. digiKam).

Seeing errors also for the style when clicking "Apply":

$ kcmshell5 style
QFile::copy: Empty or null file name
QObject::killTimer(): Error: timer id 7 is not valid for object 0x7fd0f4008c00 (QtCurve::Style, qtcurve), timer has not been killed

The timer message is annoying but of little consequence. The QFile message comes from the colour scheme; it disappears when I have another scheme configured when I change styles.

[RJVB (René Bertin)]

I fixed the QFile::copy() warning. Turns out colour palettes should not have a dash in their name...

[RJVB (René Bertin)]

I think I've also fixed the killTimer warning, can you test please?

[mkae (Marko Käning)]

Will, do, but ran into a major rev-upgrade:

-->  Found 52 broken file(s), matching files to ports   
--->  Found 16 broken port(s), determining rebuild order
--->  Rebuilding in order
     libVLC @2.2.4 +qtkit+quartz-x11
     qt5-kde-devel @5.6.1 +harfbuzz+mariadb55+qt5kde
     kf5-gwenview @16.08.2 +qt5kde
     qt5-kde-qtwebkit @5.6.1 +qt5kde
     gd2 @2.2.3 -x11
     poppler @0.47.0 
     gdk-pixbuf2 @2.36.0 -x11
     OpenSceneGraph @3.4.0 +qt5
     kf5-khtml @5.27.0 +qt5kde-qspXDG
     kf5-kio-extras @16.08.2 +qt5kde
     ghostscript @9.19 -x11
     ImageMagick @6.9.6-2 -x11
     opencv @3.1.0 +contrib+qt5
     poppler-qt5 @0.47.0 +qt5kde
     kf5-digikam-devel @5.1.0.133 +qt5kde
     kf5-okular-devel @15.12.1.455 +qt5kde

being a side-effect of disabling your macstrop version of port:jpeg...

[RJVB (René Bertin)]

Will, do, but ran into a major rev-upgrade:

-->  Found 52 broken file(s), matching files to ports
--->  Found 16 broken port(s), determining rebuild order
--->  Rebuilding in order

...

}}} being a side-effect of disabling your macstrop version of port:jpeg...

Did you have the default version of that port installed? In that case it should have been possible to install the official port and be done with it. I didn't have to rebuild anything else when I updated my own port:jpeg!

[mkae (Marko Käning)]

Trac's up and down for me all the time which is why I am sending feedback only now.

I tested the current status.

No warnings anymore.

Works better now. Keeps more settings set. :)

Will proceed with committing.

[RJVB (René Bertin)]

Hah, you could have waited until I commit that timer patch upstream ;) (doing so now)

[mkae (Marko Käning)]

Go ahead, I am still fiddling with it. I'll let it alone then for now and wait for your push into macstrop.

[RJVB (René Bertin)]

Done. I've also cleaned up the code a bit more.

[mkae (Marko Käning)]

Great!

BTW, I would like to avoid the epoch 2 if that's not too much of a hassle for you.

Also I'll convert the port name to lower case, in order to satisfy port lint --nitpick.

[RJVB (René Bertin)]

Removing the epoch is apparently possible because I have no more of the old versions with a date in the version installed.

I also detected a error that slipped by: the gtk2 subport's post-destroot should install into the destroot, not ${worksrcpath} ...

        xinstall -m 644 ${filespath}/kdeglobals ${destroot}${prefix}/share/themes/QtCurve/gtk-2.0/kdeglobals

[mkae (Marko Käning)]

Just for the record: this update of qtcurve is currently being reviewed on GitHub as ​'macports/macports-ports' pull request #7

[mkae (Marko Käning)]

In fcb15080/macports-ports:

qtcurve: New subport qtcurve-extra + patch for KCM

Upstreamed patch to prevent the killTimer warning when changing styles via
the styles KCM.

Fixed the GTk2 theme upstream. Ship Mac-appropriate kdeglobals file for
this theme.

Code cleanup & introduction of a libcxx variant for 10.6 (and earlier).

qtcurve{,-qt5,-gtk2}: revive function that scans for system-wide config
file.

qtcurve-extra: install a system-wide config file (stylerc) that provides
a Mac-like look.

Deactivate config pages that don't make sense on OS X and/or don't work
properly anywhere.

qtcurve-qt5: Adapt to the new cmake.install_rpath syntax.

qtcurve : Add a setting to use a non-native ("in-window") menubar with
select applications; incorporated upstream.

qtcurve(-qt5): Implements qt4 & qt5 UIs and previews for the
onlyTicksInMenu feature which was incorporated upstream. Another upstreamed
fix that prevents the well-known menu-rendering glitch under Qt4
(happened also with qtcurve when popup menus were rounded). D-Bus
patching.

The Qt5 subport is "KF5-ready" but will install as +qtonly by default until
the required KF5 dependencies are available in MacPorts.

Closes: #46507
Closes: ​https://github.com/macports/macports-ports/pull/7

[mkae (Marko Käning)]

In eb318efa/macports-ports:

qtcurve: New subport qtcurve-extra + patch for KCM

Upstreamed patch to prevent the killTimer warning when changing styles via
the styles KCM.

Fixed the GTk2 theme upstream. Ship Mac-appropriate kdeglobals file for
this theme.

Code cleanup & introduction of a libcxx variant for 10.6 (and earlier).

qtcurve{,-qt5,-gtk2}: revive function that scans for system-wide config
file.

qtcurve-extra: install a system-wide config file (stylerc) that provides
a Mac-like look.

Deactivate config pages that don't make sense on OS X and/or don't work
properly anywhere.

qtcurve-qt5: Adapt to the new cmake.install_rpath syntax.

qtcurve : Add a setting to use a non-native ("in-window") menubar with
select applications; incorporated upstream.

qtcurve(-qt5): Implements qt4 & qt5 UIs and previews for the
onlyTicksInMenu feature which was incorporated upstream. Another upstreamed
fix that prevents the well-known menu-rendering glitch under Qt4
(happened also with qtcurve when popup menus were rounded). D-Bus
patching.

The Qt5 subport is "KF5-ready" but will install as +qtonly by default until
the required KF5 dependencies are available in MacPorts.

Closes: #46507
Closes: ​https://github.com/macports/macports-ports/pull/7