Re: kdeinit5 on OS X
David Faure wrote:
> 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.
Yeah, that used to be true, question is to what extent that is still the case.
Best way is to try and see:
https://git.reviewboard.kde.org/r/126161/
> But maybe things changed since then. I don't know what quartz is. How does
> that relate to Carbon and Cocoa ?
Good question, one I never really had the answer to. AFAIU Quartz is (or is
what
they called) the underlying software layer that handles the GUI, with which you
can interact either through Cocoa or the old Carbon (which itself started life
as a kind of porting layer designed to ease the transition from Mac OS to Mac
OS
X).
> 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.
That doesn't show where `path` comes from ... What I really meant with my
question is whether if finds the executable inside an app bundle that is itself
not in the PATH but that can be found via LaunchServices.
> 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.
Well, kwrapper5 kwrite doesn't start kwrite.app which lives inside
/Applications/MacPorts/KDE4 (so the BundleExec is
/Applications/MacPorts/KDE4/kwrite.app/Contents/MacOS/kwrite). Using the
complete path does start the application, but with an error that the kdeinit5
socket isn't found (internal confusion about its name, apparently). When I
check
ps, kwrite's parent is the shell I launched kwrapper5 from. Meaning kwrapper5
did a direct exec, apparently.
Again, see the RR. I have entitled it "housekeeping" because that's really what
it is :)
R.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kdeinit5 on OS X
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, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kdeinit5 on OS X
Aleix Pol wrote: > I also don't see why you'd want kdeinit in a bundle. But then I'm not There used to be a time when a connection to the windowserver indeed required (or was much easier to get, or worked better) if the application lived in an appbundle, and there *may* still be conditions under which that's preferable. A requirement to start an application through LaunchServices would be one, but I don't think that applies here > very knowledgeable about OS X. Maybe ask kde-...@kde.org? I'm rather certain that the people on kde-mac don't have a lot more experience with KF5 than I have, but you're right I should have cross-posted. R. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kdeinit5 on OS X
On Mon, Nov 23, 2015 at 1:29 PM, René J.V. 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.
>
> Hence my question: has anyone verified whether the app bundle nature is
> required? 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.
>
> If not: what possibilities do I have to verify this myself 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.)
>
> NB: if kdeinit5 indeed has to be built as an app bundle its executable isn't
> found because of that a wrapper script might be required, like the one I
> wrote for KDE4:
>
> #!/bin/sh
>
> if [ "${TERM}" != "" ] ;then
> # launched from a terminal session; do not use LaunchServices:
> exec @KDEAPPDIR@/kdeinit5.app/Contents/MacOS/kdeinit5 "$@"
> else
> exec open -W -a @KDEAPPDIR@/kdeinit5.app --args "$@"
> fi
I also don't see why you'd want kdeinit in a bundle. But then I'm not
very knowledgeable about OS X. Maybe ask kde-...@kde.org?
Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
kdeinit5 on OS X
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.
Hence my question: has anyone verified whether the app bundle nature is
required? 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.
If not: what possibilities do I have to verify this myself 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.)
NB: if kdeinit5 indeed has to be built as an app bundle its executable isn't
found because of that a wrapper script might be required, like the one I wrote
for KDE4:
#!/bin/sh
if [ "${TERM}" != "" ] ;then
# launched from a terminal session; do not use LaunchServices:
exec @KDEAPPDIR@/kdeinit5.app/Contents/MacOS/kdeinit5 "$@"
else
exec open -W -a @KDEAPPDIR@/kdeinit5.app --args "$@"
fi
R
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
