<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="12" style="border: 1px #c9c399 solid; border-radius: 6px; -moz-border-radius: 6px; -webkit-border-radius: 6px;">
<tr>
<td>
This is an automatically generated e-mail. To reply, visit:
<a href="https://git.reviewboard.kde.org/r/129730/">https://git.reviewboard.kde.org/r/129730/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<p style="margin-top: 0;">On January 8th, 2017, 9:04 p.m. CET, <b>David Faure</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Where do KDE apps on Mac get installed to?</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">The reasoning "QStringList::removeAll() should remove only entries matching /Applications exactly", while true, <em style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: normal;">does</em> 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.</p></pre>
</blockquote>
<p>On January 8th, 2017, 9:24 p.m. CET, <b>René J.V. Bertin</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">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.</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">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.</p></pre>
</blockquote>
<p>On January 8th, 2017, 9:54 p.m. CET, <b>David Faure</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">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.</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">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.</p></pre>
</blockquote>
<p>On January 8th, 2017, 10:32 p.m. CET, <b>René J.V. Bertin</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">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?</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">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 .</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">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?</p></pre>
</blockquote>
<p>On January 8th, 2017, 10:51 p.m. CET, <b>David Faure</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Yes, ksycoca is used for parts and plugins, but NOT when looking under Applications.</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Application desktop files are not the same as service desktop files (plugins). (And even that is mostly moving to json in plugins instead).</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">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.</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">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 ;)</p></pre>
</blockquote>
</blockquote>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">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.</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">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.</p></pre>
<br />
<p>- René J.V.</p>
<br />
<p>On December 30th, 2016, 9:10 p.m. CET, René J.V. Bertin wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="12" style="border: 1px #888a85 solid; border-radius: 6px; -moz-border-radius: 6px; -webkit-border-radius: 6px;">
<tr>
<td>
<div>Review request for KDE Software on Mac OS X and KDE Frameworks.</div>
<div>By René J.V. Bertin.</div>
<p style="color: grey;"><i>Updated Dec. 30, 2016, 9:10 p.m.</i></p>
<div style="margin-top: 1.5em;">
<b style="color: #575012; font-size: 10pt;">Repository: </b>
kservice
</div>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">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: <code style="text-rendering: inherit;color: #4444cc;padding: 0;white-space: normal;margin: 0;line-height: inherit;">/Applications</code>.</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">This patch avoids that by removing all occurrences of /Applications from the result of <code style="text-rendering: inherit;color: #4444cc;padding: 0;white-space: normal;margin: 0;line-height: inherit;">QStandardPaths::standardLocations(QStandardPaths::ApplicationsLocation)</code> (and also removes any duplicates, which seems like a good idea just in case).</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">I've marked this "WIP" because I'm not sure how this implementation would work out for standalone app bundle builds. I <em style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: normal;">think</em> they should be fine even if installed somewhere under /Applications because <code style="text-rendering: inherit;color: #4444cc;padding: 0;white-space: normal;margin: 0;line-height: inherit;">QStringList::removeAll()</code> 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, <code style="text-rendering: inherit;color: #4444cc;padding: 0;white-space: normal;margin: 0;line-height: inherit;">$HOME/Applications/Kate.app</code>.</p></pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Testing </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">On OS X 10.9.5 and and Linux with Qt 5.7.1 and KF5 5.29.0 installed in /opt/local</p></pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>src/sycoca/kmimeassociations.cpp <span style="color: grey">(25ce3fe)</span></li>
<li>src/sycoca/vfolder_menu.cpp <span style="color: grey">(5acbf8a)</span></li>
</ul>
<p><a href="https://git.reviewboard.kde.org/r/129730/diff/" style="margin-left: 3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>