[KDE/Mac] Upgrade to 4.13.3 in Macports

[Nicolas Pavillon]

Hello René, 

>> - Addition of ports baloo (baloo and baloo-widgets). There are not used automatically for now, but a variant is added to nepomuk-core and kde4-baseapps to include the dependency. Kdepim4 also requires baloo, as it can’t compile without it, but it would not be activated. As it would not be readily used for now, the nepomuk dependency would be kept. There are also probably some services to take care of before baloo could really be used. 
> 
> That's a pity (understandable as it is). Nepomuk/Virtuoso is too much of a hog to run in addition to Spotlight, I was really hoping Baloo would provide a means to search in emails when using mail.
Well, the ports will be there, and I made a tentative launchd script, so things should be around for testing. I suspect it won’t work out of box (it did not when I rapidly tried to test it), but we can improve from there. Considering that probably most users would still rely on Spotlight, it is likely that baloo will not be enabled by default on Mac OS X, even though having a working possibility could be nice.

> 
>> There are then some patches that I would consider rather safe to include:
>> - Use of OSX keychain (https://git.reviewboard.kde.org/r/119838/) This seems like a nice feature, with its use based on a variant, which would thus be mainly “on demand”. 
> 
> I'm still working on extending that one, but that won't change anything that's already been accepted.
In the case you are still working on it, I would tend to then hold before including it to the port. I would prefer not make incremental upgrades of the patch later. This  would also go well with my wish of trying to first test essentially the upgrade itself, and then include patches for improvement. 

> 
>> - Native file dialogs (https://reviewboard.kde.org/r/119243/). This seems to be deeper changes, that I would tend to leave out for now in order to see how 4.13 is going first.
> 
> You could leave those as a variant. I've been running this since I created the patch, and other than the fact that you get a mix of native and KDE dialogs there doesn't seem to be any problem with it.
I would avoid to do that. While it makes sense to me to make a variant when it implies a user’s choice (such as wanting to use OS X keychain instead of kwallet), they are not meant to store temporary features that will ultimately be included in the main code. Considering the life cycle of a variant (we can’t just delete them right away to avoid breaking users ports), that would make portfiles a mess.

> 
>> - System trays menus (​https://reviewboard.kde.org/r/120149/). Again, these would be changes I would leave out for now to test 4.13 first.
> 
> Heh, have you seen the code? It's a minimal change, and doesn't do any hacking, in fact it replaces a call that does complex formatting with a series of simpler calls. Again, I'm still working on menu related stuff, trying to find a solution to the fact that the wrong menu item gets stuck under the Application menu's Preferences item. It seems that this is the first item an application creates that has the word Configure in it ... I found how to patch user code to do this, I'll now be looking at possibilities to incorporate the logic in kdeui.
If you are working on it, I would also tend to wait for a final version, then. But the fact that I want to separate upgrade and new features through patches is not really about the code involved, but about the unexpected bad surprises we had in several occasions when upgrading from previous versions. I want to decouple these to make the transition smoother. 

> 
>> Any input welcome on this, would it be about the patches above, or something else I may have missed. 
> 
> Yes. You may have missed my remark, but it turns out to be perfectly possible to run kdelibs4 4.14.0 (basically, git/master) while all the rest is still at 4.12.5 . The differences with 4.13.3 are going to be even smaller.
> That makes it much more easy to decide which of the MacPorts patches are going to have to be kept during and after the transition to KF5, and to put them on review board. So I'd really suggest to look into upgrading to KDE SC 4.13.3 but kdelibs 4.14 . (IIRC all the existing MacPorts patches applied cleanly apart possibly from those that have become irrelevant.)
I saw it, and while I fully see the potential interest for developing, I would strongly disagree about forcing all users to run libraries from different versions, even more if it implies using an unreleased version of the code.  This makes complete sense to me for a local portfile to ease development, though.

Cheers, 

Nicolas