On Monday 23 November 2015 13:29:23 René J.V. Bertin wrote:
> Hi,
> 
> Preparing a MacPorts port for kf5-kinit, I see the following in kdeinit's 
> CMake file:
> 
> add_executable(kdeinit5 ${kdeinit_SRCS})
> if (APPLE)                       
>   # this has to be GUI on OSX because it launches GUI apps and need a quartz 
> context
>   set_target_properties(kdeinit5 PROPERTIES MACOSX_BUNDLE_INFO_PLIST 
> ${CMAKE_CURRENT_SOURCE_DIR}/Info.plist.template)
>   set_target_properties(kdeinit5 PROPERTIES MACOSX_BUNDLE_GUI_IDENTIFIER 
> "org.kde.kdeinit5")
>   set_target_properties(kdeinit5 PROPERTIES MACOSX_BUNDLE_BUNDLE_NAME "KDE 
> Init")
> else ()           
>   ecm_mark_nongui_executable(kdeinit5)
> endif ()          
> 
> 
> Has that been verified? AFAIK, the only thing mark_nongui_exec does on OS X 
> is to build the application as a regular executable, instead of as an app 
> bundle. And also AFAIK, this makes no difference on what the resulting 
> application can do.

I thought app bundles led to more GUI initializations than non-app bundles, and 
clearly the person
writing the above (Benjamin Reed, CC'ed) found that to be true as well, at 
least back then.

But maybe things changed since then. I don't know what quartz is. How does that 
relate to Carbon and Cocoa ?

> Hence my question: has anyone verified whether the app bundle nature is 
> required?

Not since 2008 (commit 820088d335070c1c03521c0aedf811553dcbefc5 in kdelibs).

> Kdeinit4 was built like that, and as a result wasn't found by the library 
> function (KToolInvocation::startKdeinit()) that is supposed to start things 
> like klauncher through kdeinit4. I see the KF5 version uses 
> QSP::findExecutable(), and its documentation is mute about whether that 
> function is able to find a BundleExec on OS X.

Who needs documentation when you have code? ;)

From qstandardpaths.cpp:
static QString checkExecutable(const QString &path)
{
    const QFileInfo info(path);
    if (info.isBundle())
        return info.bundleName();

^ it's supposed to find app bundles. If it doesn't, feel free to debug 
qstandardpaths.cpp and submit a patch, I'll review it.
 
> If not: what possibilities do I have to verify this myself

You would need to start an executable via kdeinit, e.g. using  `kwrapper5 
kwrite`.
Don't just check that kwrite starts up, check the debug output or the process 
list to make sure it was started by kdeinit forking.
If kdeinit5 isn't found, there's fallback for starting the app directly.

> when I am only just at the point where I could build and install kf5-kinit 
> itself? (I see a lot of leftover Q_OS_MAC tokens, suggesting the code hasn't 
> been verified beyond whether it builds.)

Sounds right.

-- 
David Faure, [email protected], http://www.davidfaure.fr
Working on KDE Frameworks 5

_______________________________________________
Kde-frameworks-devel mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Reply via email to