Review Request 129730: [WIP] : kbuildsyscoca should skip /Applications on Mac

Sun Jan 8 22:23:26 UTC 2017

> On Jan. 8, 2017, 9:04 p.m., David Faure wrote:
> > Where do KDE apps on Mac get installed to?
> > 
> > The reasoning "QStringList::removeAll() should remove only entries matching /Applications exactly", while true, *does* exclude /Applications from the recursive search for .desktop files. So if KDE Mac applications (including their .desktop file) do get installed into /Applications, and if we need their .desktop file located by ksycoca (e.g. to associate them with mimetypes), then we can't exclude /Applications.
> 
> René J.V. Bertin wrote:
>     In my approach, only the applications themselves are installed somewhere under /Applications, provided they're built as app bundles. Everything else goes under a traditional POSIX-style prefix like /opt/local, including non-app-bundle executables.
>     
>     Others who have more experience building standalone app bundle versions which could go under /Applications should be able to say more, but I would expect that those are in fact individual builds that are configured to consider the app bundle as their root and to be self-centred w.r.t. sycoca5. IOW, I would expect that their search for .desktop entries is limited to the app bundle contents, and starts at the app bundle, so at least 1 level under /Applications or wherever the bundle has been saved.
>     I'm not sure if they could do anything else: app bundles that include Qt and all required frameworks aren't guaranteed to have the same versions, which could lead to all kinds of unexpected behaviour.
>     That's why I think that excluding /Applications shouldn't have any impact on such builds.
> 
> David Faure wrote:
>     Same version of Qt/frameworks is completely irrelevant here.
>     Application .desktop files are about starting applications. They could be using GTK or whatever, they can still be launched by a Qt app.
>     
>     The question is, do we want an app installed as a bundle, to be possibly associated to mime types so that clicking on a file in e.g. Dolphin starts the application. And if we do, should the .desktop file be picked up from the bundle or from another location. That's for you Mac guys to discuss and decide.
> 
> René J.V. Bertin wrote:
>     Isn't the sycoca5 data also used to determine what KParts and other kinds of plugins are available, based on .desktop files or whatever they've been replaced with?
>     
>     I think the point you raise about their use to find applications should probably be limited to use from within Qt5/KF5 based applications. I don't have any brilliant ideas here, but ideally applications like Dolphin would use native mechanisms (possibly in addition to supporting .desktop files in standard locations). Remember the exchange we had about GUI style launching (using LaunchServices on Mac)? This would fit in. I'm not very optimistic though that some form of automatic conversion will be feasible of .desktop files to the necessary entries in the application Info.plist .
>     
>     I'll drop the patch and keep it as a MacPorts patch where it does make (more) sense. Do you want to close this RR or leave it open for a while to see if it attracts some discussion on this subject?
> 
> David Faure wrote:
>     Yes, ksycoca is used for parts and plugins, but NOT when looking under Applications.
>     
>     Application desktop files are not the same as service desktop files (plugins). (And even that is mostly moving to json in plugins instead).
>     
>     LaunchServices is once you know what to launch, AFAIK. This is about one step before that, finding which app to launch based on file type. No idea how that works on Mac, but for sure the native way isn't implemented right now.
>     
>     I am not objecting to this patch going in, as long as there is an agreement among kde-mac people that we don't need to find .desktop files in /Applications. I suppose the "starting other KDE apps by mimetype like in KDE" issue is largely unsolved (for the case of app bundles) and basically not supposed to be working (unlike the /opt/share installation case), so presumably this doesn't break anything. I'd just like confirmation from other KDE mac people to be sure ;)

LaunchServices also contains the information of which application(s) can open what document (types). Nowadays that's mostly determined by mimetype URIs and (gasp) file extensions where in former days there were document and creator FourCharCodes but the essence is still the same. It's the application that tells the system what kind of documents it can edit (and thus create) and which it can read, and that info is stored in a central database.
If you have Kate's source at hand you'll find kate/data/MacOSXBundleInfo.plist.in, a template Info.plist that at its end shows how an application can instruct LaunchServices that it can edit any kind of document.

There isn't much activity on kde-mac ATM, and this will also need to be seen by people who may be doing more Mac-targeted KDE development than they actually use the software there. They should have seen it via frameworks-devel though.

- René J.V.

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129730/#review101896
-----------------------------------------------------------

On Dec. 30, 2016, 9:10 p.m., René J.V. Bertin wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129730/
> -----------------------------------------------------------
> 
> (Updated Dec. 30, 2016, 9:10 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X and KDE Frameworks.
> 
> 
> Repository: kservice
> 
> 
> Description
> -------
> 
> After upgrading to Qt 5.7.1 I noticed that kbuildsycoca5 (and the "inline" version used by many applications) took long minutes to trawl a location where it's unlikely to find anything of interest among the probably huge number of files present: `/Applications`.
> 
> This patch avoids that by removing all occurrences of /Applications from the result of `QStandardPaths::standardLocations(QStandardPaths::ApplicationsLocation)` (and also removes any duplicates, which seems like a good idea just in case).
> 
> I've marked this "WIP" because I'm not sure how this implementation would work out for standalone app bundle builds. I *think* they should be fine even if installed somewhere under /Applications because `QStringList::removeAll()` should remove only entries matching "/Applications" exactly. Possibly the filter could be widened to catch all "*/Applications", meaning also $HOME/Applications. That should still leave, say, `$HOME/Applications/Kate.app`.
> 
> 
> Diffs
> -----
> 
>   src/sycoca/kmimeassociations.cpp 25ce3fe 
>   src/sycoca/vfolder_menu.cpp 5acbf8a 
> 
> Diff: https://git.reviewboard.kde.org/r/129730/diff/
> 
> 
> Testing
> -------
> 
> On OS X 10.9.5 and and Linux with Qt 5.7.1 and KF5 5.29.0 installed in /opt/local
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-mac/attachments/20170108/0e52f145/attachment-0001.html>