[KDE/Mac] breeze-settings5 problem (etc etc etc)

[René J.V. Bertin]

On Sunday January 31 2016 14:28:00 Marko Käning wrote:

>OK, I installed it and I don't see a difference in the dialogs rendering if I call it like this:
>
> $ /Applications/MacPorts/KF5/breeze-settings5.app/Contents/MacOS/breeze-settings5 -style breeze
> $ /Applications/MacPorts/KF5/breeze-settings5.app/Contents/MacOS/breeze-settings5 -style ciment
>
>Perhaps I am using a wrong style name here?

Ciment is an icon theme, not a style. The icon theme is selected in ~/.config/kdeglobals, and will be whatever you selected for KDE4 *before* that file was migrated for the 1st time. There isn't currently a way to edit this kind of setting via systemsettings5 because I haven't yet had the time or energy to patch the corresponding plasma package so that it builds on OS X.

> [Nicolas would] be verifying and testing that nothing is missed on the KDE4 side.
> But perhaps I am fearing something which wouldn't be a problem after all, as
> all changes are made in the qt4-mac and kde4 port groups only...

I didn't notice you had included him, but yeah, he *could* do that. IIRC he's aware of the changes I've proposed to the KDE4 PortGroup so I presume he'll jump in when and if he feels it's the right time to do that.

> This disguising ports as subports in Portfiles is sometimes quite
> irritating.

Having numerous little Portfiles for every tiny little port is just as annoying to me, maybe even for very similar reasons.
I'm holding off on this one because I'd like to know first if it gets framework status.

> Yeah, that's fine, but to keep "port lint --nitpick" happy one also needs to
> rename the port folders identical to the containing main ports.

I know, and that's exactly what I was referring to. I wouldn't publish my personal repository directly anyway.

> quite a few ports which have subports or variants which apply for both
> worlds

Oh? This is true for a number of Qt5 ports, but not KF5 AFAICS. There will be a growing number of KF5 ports that are successors to KDE4 ports, but I haven't created a single KF5 port that is actually a subport of a KDE4 port. I think :)
The KDE category folder is already large enough as it is. Finding one's way around it in a GUI tool can be cumbersome enough, cluttering it in addition with a potentially large number of entries starting all with kf5- will not make it easier to spot a specific port you're looking for.

I wouldn't be against an additional hierarchy, i.e. kde/4/<portdir> vs kde/5/<portdir> but I never tried if that's even possible (seems it isn't).

> Too bad that kf5-oxygen-icons conflicts with oxygen-icons and kde4-oxygen...

Actually, someone needs to inquire whether the oxygen and breeze icon themes are even potentially different between KDE4 and KF5. It seems the only difference for the oxygen theme is the download location ...

> Error: org.macports.destroot for port kf5-kate returned: error renaming
> "/opt/local/var/macports/build/_Users_marko_WC_MacPorts-test_dports_kf5_kat
> e5/kf5-kate/work/destroot/opt/local/share/man/man1/kate.1": no such file or
> directory

Hmmm, maybe that means that the manpage isn't created/installed when you don't use the +docs variant. Annoying. I pushed a fix (hopefully).

> If we commit the collection of KF5 ports to MacPorts we need - IMO - to make
> sure that we're not doing that, but instead base our changes onto real
> tarballs released by the respective projects.

I'm only pulling git repos for -devel ports or in rare occasions when I haven't found a release tarball.

> Meaning: Have you a script which generates the checksums of updated
> frameworks and updates the Portfile accordingly?

I started writing one at some point, but never completed it. I just use a for loop in my shell:

{{{
foreach J (kf5-foo kf5-bar kf5-etc)
port -v checksum $J |& tee -a checksums.log
end
}}}

I guess the next time I have to go through that circus (= 2 weeks ago or so...) I'll put that in a script. "base" is nice enough to show the expected checksums, and then I copy/paste the blocks in place. A lot of work because there are so many to treat, but that is exactly why I feel that putting all the checksums in a table is not a good idea either.

> What about figuring out individual updates of some frameworks. There might
> be framework versions x.y.z around for the current x.y.0 release which have
> z>0...

As far as I know that is not supposed to occur, but the KF5 PortGroup does have kf5.latest_{version,release,plasma} for that.

Cheers,
R.