[KDE/Mac] Cross-platform with kdeinit5, klauncher5, kded5 and friends

[Ian Wadham]

Hi guys, especially Jeremy and Marko,

This could become a long discussion, so I have started with a rather
generic title.  As we go along, we should identify specific issues, such
as the one Marko is battling with currently, and start new threads.

On the <kde-games-devel at kde.org>, "Freeze in 6 weeks" thread, we had:
On 30/01/2015, at 7:16 AM, Jeremy Whiting wrote:
> On Wed, Jan 28, 2015 at 8:23 PM, Ian Wadham <iandw.au at gmail.com> wrote:
> On 29/01/2015, at 1:25 PM, Jeremy Whiting wrote:
> > At any rate, how were klauncher and kded and such issues solved in kdelibs4 on osx? I can put some time into fixing the kf5 versions to do the same thing.
> 
> Ian wrote: We are getting WAY off topic here… :-)  But do you *know* something
> about kdeinit, klauncher, kded, kio and friends?  I have been looking for someone
> who does for 6 months or more.  I never did solve the issues, but I found quite
> a few and had some ideas how to solve them.  Then I could not find anyone to
> help confirm my findings… :-(  If we can work on this together, please start
> a topic on the KDE-Mac list and we can discuss what I found out before.
> 
> Yeah, that's way off for the games list indeed, my bad. As for if I *know* something about them, no I don't know much about them. I've delved into their code a bit when I was debugging why pdf files weren't opened with okular in the plasma 5.0 days. I feel confident that I can find my way around the sources as needed. I'm not sure exactly which jobs each of those do, I know what kbuildsycoca is for and does roughly, but couldn't say what the difference between kdeinit and klauncher is for example. I know dbus is the glue that keeps them communicating though. Is dbus a first class citizen on OS X now? I saw the messages when I installed the dbus port suggesting how to make it start automatically, though it doesn't seem like dbus-daemon is running here still.

Well, your knowledge is only slightly in advance of mine… :-)  But two heads
are better than one… :-)  And I do have quite a bit of (old) experience of real
time programming, even some in UNIX, circa 1998.

Re DBus, it is not the ONLY glue… and that is part of the problem, I would say.
Our friends use more than one way to communicate.

DBus runs OK on OS X and I never have any problems with it and I don't think
Marko or René do either.  However, AFAIK, only Qt and KDE apps use it and
it is not part of Apple's "standard kit".  Hence the notes MacPorts issues about
how to start DBus, whenever it installs a KDE app.

> Is there a list of known issues with these daemons/services on OS X?

Not yet, but I have a private list.  AFAIK, KDE users are mostly unaware of the
existence of our friends on Apple OS X.  And so they will never start them, unless
KDE apps or libraries start them automatically.  I used to have kdeinit4 in my Apple
OS X startup list[1], but it did not seem to make any difference, so I have taken it out.

We did become aware of the importance of kbuildsycoca4 a couple of years ago.
I asked on the kde-devel list what starts it and when, but nobody seemed to know
for sure…  Actually, it is one of kded's tasks to run kbuildsycoca regularly, but I think
it depends on detecting changes in KDE files…

Anyway, Nicolas Pavillon, our MacPorts' KDE port developer, installed a small
script that runs kbuildsycoca4 periodically, and since then we have been able to
run KDE apps that have plugins on Apple OS X… :-)

> I would expect it shouldn't take much to get them to work the same as they do on linux because of its unix underpinnings, but I could be wrong.

Procedurally speaking, the UNIX-like stuff is usually workable on Apple OS X.
However, the cases where our friends use Apple conditional code have been
written but either never tested or not tested for years.  So some things have
been written wrong or have become wrong.

When I say "usually workable", that means barring any Apple OS X constraints
re security or O/S style and architecture.  For example, if Dr Konqi is run by
kdeinit (as it should be, ideally), Apple OS X terminates Dr K for a security
violation.  I have not yet found out why… :-)

Also, our friends are dealing with different subject information and data in Linux
and OS X, so they may not work as well in OS X or some of their functions may
be redundant and a waste of time (grins at Marko).

I am thinking of kded things like directory-change monitoring, battery monitoring,
Bluetooth monitoring, etc.  There may also be some "standard" kdeinit modules
that are redundant in OS X.

> Anyway, I think we can get these issues solved together, yes.

Well, we can give it a go… :-) … and I think we can can score a few runs… :-)

> Since early this month I've had a third of the screens facing me daily being
> OS X (the other two screens are linux and windows, one of each) so I can
> test/tweak/play until we get it working well.

Wow!  What a setup!

Test/tweak/play is fine and would address the worst problems, but IMHO our
friends, along with Dr Konqi, are up for a re-design/re-write to make them truly
cross-platform --- or maybe a major re-work in which libraries will take on more
of their functions.  I don't think either of us is up for those activities…

Even in Linux kded5 has problems currently.  See:
https://bugs.kde.org/show_bug.cgi?id=337674#c53 and following comments.

I will now start compiling a list of issues and possible solutions, working from
what I found out before.

It will be great to work with you, Jeremy! … :-)

All the best, Ian W.

[1] Apple-menu->System Preferences…->Users & Groups->Login Items