Opened 10 years ago

Closed 8 years ago

Last modified 8 years ago

#46507 closed enhancement (fixed)

QtCurve update with support for Qt5

Reported by: RJVB (René Bertin) Owned by: mkae (Marko Käning)
Priority: Normal Milestone:
Component: ports Version:
Keywords: haspatch maintainer Cc:
Port: QtCurve

Description

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.

Attachments (7)

add-utilslib-infix.patch (10.4 KB) - added by RJVB (René Bertin) 10 years ago.
this allows co-installation of GTk2, Qt4 and Qt5 specific qtcurve-utils libraries
qtcurve-diff-20150109.diff (7.1 KB) - added by RJVB (René Bertin) 10 years ago.
qtcurve-diff-20150110.diff (7.0 KB) - added by RJVB (René Bertin) 10 years ago.
the qt5-QtCurve subport was replaced with QtCurve-qt5
qtcurve-diff-20150122.diff (7.1 KB) - added by RJVB (René Bertin) 10 years ago.
syncs to the latest version but depends on the patches at
qtcurve-diff-20150127.diff (7.1 KB) - added by RJVB (René Bertin) 10 years ago.
QtCurve-default.png (122.9 KB) - added by RJVB (René Bertin) 8 years ago.
QtCurve default style configuration
QtCurve-MacOSX-Graphite.png (123.1 KB) - added by RJVB (René Bertin) 8 years ago.
QtCurve "MacOS-Graphite" style configuration

Download all attachments as: .zip

Change History (57)

Changed 10 years ago by RJVB (René Bertin)

Attachment: add-utilslib-infix.patch added

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

Changed 10 years ago by RJVB (René Bertin)

Attachment: qtcurve-diff-20150109.diff added

comment:1 Changed 10 years ago by mf2k (Frank Schima)

Keywords: maintainer added
Type: updateenhancement
Version: 2.3.3

comment:2 Changed 10 years ago by 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}/

comment:3 in reply to:  2 ; Changed 10 years ago by 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.

comment:4 in reply to:  3 Changed 10 years ago by 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.

comment:5 Changed 10 years ago by mkae (Marko Käning)

Cc: mk@… added

Cc Me!

comment:6 Changed 10 years ago by mkae (Marko Käning)

This relies on committing PortGroup qt5, right?!

comment:7 Changed 10 years ago by 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.

Changed 10 years ago by RJVB (René Bertin)

Attachment: qtcurve-diff-20150110.diff added

the qt5-QtCurve subport was replaced with QtCurve-qt5

Changed 10 years ago by RJVB (René Bertin)

Attachment: qtcurve-diff-20150122.diff added

syncs to the latest version but depends on the patches at

comment:8 Changed 10 years ago by RJVB (René Bertin)

Changed 10 years ago by RJVB (René Bertin)

Attachment: qtcurve-diff-20150127.diff added

comment:9 Changed 10 years ago by RJVB (René Bertin)

Disregard version 20150122, this version should build as is.

comment:10 Changed 8 years ago by mkae (Marko Käning)

Cc: mk@… removed
Owner: changed from macports-tickets@… to mk@…

comment:11 Changed 8 years ago by mkae (Marko Käning)

Status: newaccepted

comment:12 Changed 8 years ago by 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...

comment:13 Changed 8 years ago by mkae (Marko Käning)

Status: acceptedassigned

comment:14 Changed 8 years ago by 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.

comment:15 Changed 8 years ago by mkae (Marko Käning)

Status: assignedaccepted

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?

comment:16 Changed 8 years ago by 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).

comment:17 Changed 8 years ago by 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...

comment:18 in reply to:  17 ; Changed 8 years ago by larryv (Lawrence Velázquez)

Do not commit development detritus to the ports repository.

comment:19 in reply to:  18 Changed 8 years ago by 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. ;)

comment:20 Changed 8 years ago by 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?

Last edited 8 years ago by mkae (Marko Käning) (previous) (diff)

comment:21 Changed 8 years ago by 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...

comment:22 Changed 8 years ago by 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

comment:23 in reply to:  22 Changed 8 years ago by 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.

comment:24 Changed 8 years ago by 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?

comment:25 in reply to:  24 Changed 8 years ago by 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?

comment:26 Changed 8 years ago by 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.

comment:27 Changed 8 years ago by 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.

comment:28 Changed 8 years ago by 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.

comment:29 Changed 8 years ago by 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.

comment:30 in reply to:  29 Changed 8 years ago by 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 addressed, 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?!)

Last edited 8 years ago by mkae (Marko Käning) (previous) (diff)

comment:31 Changed 8 years ago by 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.

comment:32 Changed 8 years ago by 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.

Changed 8 years ago by RJVB (René Bertin)

Attachment: QtCurve-default.png added

QtCurve default style configuration

Changed 8 years ago by RJVB (René Bertin)

Attachment: QtCurve-MacOSX-Graphite.png added

QtCurve "MacOS-Graphite" style configuration

comment:33 Changed 8 years ago by 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. :-)

comment:34 Changed 8 years ago by 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 ;)

Last edited 8 years ago by RJVB (René Bertin) (previous) (diff)

comment:35 Changed 8 years ago by 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!

comment:36 Changed 8 years ago by 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

comment:37 in reply to:  36 Changed 8 years ago by 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.

comment:38 Changed 8 years ago by RJVB (René Bertin)

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

comment:39 Changed 8 years ago by RJVB (René Bertin)

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

comment:40 Changed 8 years ago by 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...

comment:41 Changed 8 years ago by 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!

comment:42 Changed 8 years ago by 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.

comment:43 Changed 8 years ago by RJVB (René Bertin)

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

comment:44 Changed 8 years ago by 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.

comment:45 Changed 8 years ago by RJVB (René Bertin)

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

comment:46 Changed 8 years ago by 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.

comment:47 Changed 8 years ago by 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

comment:48 Changed 8 years ago by 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

comment:49 Changed 8 years ago by mkae (Marko Käning)

Resolution: fixed
Status: acceptedclosed

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

comment:50 Changed 8 years ago by 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

Note: See TracTickets for help on using tickets.