#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)
Change History (57)
Changed 10 years ago by RJVB (René Bertin)
Attachment: | add-utilslib-infix.patch added |
---|
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: | update → enhancement |
Version: | 2.3.3 |
comment:2 follow-up: 3 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 follow-up: 4 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 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: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)
depends on the patches at https://git.reviewboard.kde.org/r/122279/
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: | new → accepted |
---|
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: | accepted → assigned |
---|
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: | assigned → accepted |
---|
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 follow-up: 18 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 follow-up: 19 Changed 8 years ago by larryv (Lawrence Velázquez)
Do not commit development detritus to the ports repository.
comment:19 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?
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 follow-up: 23 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 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 thetest.run yes
line):
Sounds like a good plan.
comment:24 follow-up: 25 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 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 follow-up: 30 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 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?!)
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 ;)
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 follow-up: 37 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 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: | accepted → closed |
this allows co-installation of GTk2, Qt4 and Qt5 specific qtcurve-utils libraries