[KDE/Mac] kdeinit5 on OS X

[Ian Wadham]

Hi René,

On 24/11/2015, at 6:42 AM, René J. V. Bertin wrote:
> (Cross-posting from kde-frameworks-devel; should have done so straight away!)
> 
> 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.

Lasciate ogni speranza, voi ch'entrate.
	• Abandon all hope, you who enter here.

Whether kdeinit _needs_ to be a GUI app on Apple I do not know.  It is a very
old process, originally intended to minimise library loading, memory requirements
and KMainWindow execution overheads in "commonly used" KDE applications.
It allowed apps to add a procedure called kde_main(argc, argv) (or some such)
and then have themselves built in two ways --- as a conventional app, starting in
main (argc, argv), and as a _library_ with kde_main() as an entry point.  There
was then a special invocation to execute such an app as a library dynamically
loaded into kdeinit, which was said to gain the required efficiencies in PCs of
the early 2000s, with their smaller memories and lesser CPU power.  I think
Kate (in KDE 4) is one example of such an app.

That is about as far the documentation on kdeinit goes (see source code
kdelibs/kinit/README), but if kdeinit5 is still having to do that stuff in KF5
_and_ if OS X only lets things that have been launched as apps access
windows and GUI facilities, _then_ kdeinit5 must be built as an app bundle.

On a side note, I remember running an early KDE desktop and using "ps"
and finding that most of the processes I was running were called "kdeinit"… :-)
It was my first introduction to the weirdness of KDE.  Nowadays, I believe,
kdeinit has been fixed so as to show something more meaningful in "ps".

Which brings me to the next point.  Over the years, kdeinit has acquired some
companions, several additional functions (mostly undocumented) and several
ways of communicating with other processes (also mostly undocumented).
Kdeinit's companions are klauncher, kded and (indirectly) kio.  And these
companions have many ways to launch other processes and apps, to say
nothing of what apps themselves have in QProcess.

Internally the code of kdeinit and its companions is hard to read and follow
and almost devoid of comments.  IIUC, David Faure is the only person in the
present KDE Community who understands it very much at all.

So the problems with documentation, readability and comments, coupled with
the rather systemic role the code plays, are the reasons for my quoting from
Dante above.  No disrespect for David Faure intended… :-)

> 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.)

From my reading of the code of kdeinit4 and its companions, I am sure
that your suggestion is correct.

> 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

One advantage of kdeinit being an app is that you can include it in your
OS X "Users & Groups, Login items" settings, so that it is always running.

 I seem to remember, that a KDE 4 desktop has it in its startup script.

Having kdeinit always running is, however, not helpful when you wish to
build and run your own version… :-)

Cheers, Ian W.