Hello Kevin,
> Only very few applications could do that,most applications require
DCOP for
> the application<->session service communication.
> Some examples: KWrite will need to talk to klauncher for requesting
IO
> slaves
Oh - I see. I wasn't expecting so much general functionality being
wrapped
by kde libs. O.k., now I really understand.
> Developing KDE applications is quite easy because you can just use
> the kdelibs APIs and not care how the libs implement something,
because
> it will just work.
Yes, now I see. Even more than changing the apps code, it would be a
question of applying the no-dcopserver awareness to the kde libs,
but this, instead of just not serving the request, would need alternate
handlings, as the requests deal with so much basic functionallity.
But then again this would contamine the whole idea of wrapping these
basics to isolate them from the underlaying platform.
O.k., I am convinced now, that this is the wrong go.
Now I think about copying the dcopserver with all its shared
libs to the mini-system and try to start a dcopserver over there.
What would be missing then? Some config files? Some more servers?
Too much to even try it, or good chance for success?
(Installing kde is not possible, as there's not enough space.
May not even for the package infos ...
When I talk about "just copying", this actually goes to a nfs mount.)
Thomas
___________________________________________________
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
