[KDE/Mac] Request to modify kdelibs4 dependency on shared-mime-info

[Marko Käning]

Hi Ian,

On 20 Jul 2014, at 04:26 , Ian Wadham <iandw.au at gmail.com> wrote:
> The rock on which KDE 1 thru 4 apps have depended (unless they were very
> simple apps with no non-executable files) has been the KStandardDirs library
> class.

ok.


> On MacPorts, those KDE 4 standard directories get spread around:
> some to /Applications, some to /opt/local/share/... and some to ~/Library/Preferences.

Yes, the usual reconfiguration done in the port files.


> But now see the following KDE community pages:
> https://community.kde.org/Frameworks/Porting_Notes
> https://community.kde.org/Frameworks/Porting_Notes#KDECore_Changes
> https://community.kde.org/Frameworks/Porting_Notes/KStandardDirs

The latter is an interesting page!


> http://qt-project.org/doc/qt-5/qstandardpaths.html#StandardLocation-enum
> 
> It all looks good to me, except that I think MacPorts will have to insert extra
> layer(s), as it does now, to avoid Apple apps, KDE apps and other MacPorts
> apps getting all mixed together.

Yes, that’s what would have to be done, of course.


> For example, the directory that will be called QStandardPaths::DataLocation
> (read-only version), is currently /opt/local/share/apps/<appname> for KDE 4
> apps on MacPorts and there is a mass of other stuff in /opt/local/share.  Qt 5
> says QStandardPaths::DataLocation (read-only version) will be
> "/Library/Application Support/<APPNAME>". "<APPDIR>/../Resources", but
> there are several Apple apps with data files in "/Library/Application Support”.

That was also the topic in my discussion thread with David. I think it’s not so
easy to decide how to reliably get all the reconfiguration done. The post [1]
discusses the naming of generic data location of a framework/application w.r.t.
the vendor/application naming scheme. In [2] David describes details about how
KXMLGUI_INSTALL_DIR is implemented. This got actually committed in [3] and some
application make already use of this. David’s comment

<cite>
This keeps DATADIR slightly cleaner, getting rid of many application subdirs 
that would just contain a rc file. Some people seem to care about the cleanliness 
of their DATADIR :-) 
</cite>

shows that he has taking my questions into consideration and tries his best to
reduce the "scattered-ness of application data”.


> Food for thought, preferably forethought … :-)

Yep, that’s why I triggered this whole discussion on K-F-D.

But it is - at least for me - a complicated topic, as there are so many
different files (read-only, writable, system- and user-specific stuff, etc.)
that I got quite confused in the course of discussion. As I am not a KDE
developer I do not have enough knowledge to ask the right questions, I am
afraid.


>> the KMyMoney-KF5 port also for Linux to KDE’s Jenkins [6] and we have a
>> first successful build since yesterday! Hurray!!! :-D
> 
> Wow!  Amazing!
> 
> But I'd recommend a simpler KDE app, maybe from KDE Edu, for nutting
> out the details of where the various behind-the-scenes directories go.

Yes, you are right. We need to find a small app, which preferably makes use
of all thinkable data and config locations, in order to have an easier test
case. That could help us later thinking about how a MacPorts port file would
have to do all the reconfigurations.

   Perhaps an even better approach would be to write a small Qt5 application
   which tests all that without even the necessity to have KF5 installed at
   all?! As KF5 doesn’t add a lot of complexity to this, I believe a lot
   could be achieved already with such a little Qt5 test tool!


> Never let it be said … :-)

I didn’t say anything. ;-)


Greets,
Marko


[1] http://mail.kde.org/pipermail/kde-frameworks-devel/2014-July/017308.html
[2] http://mail.kde.org/pipermail/kde-frameworks-devel/2014-July/017317.html
[3] http://quickgit.kde.org/?p=kxmlgui.git&a=commit&h=3756e4401f677eec3bacfb2b8fc7ac5b32eb5c1a