[RFC] How do I tell the MainWindow that the Part won't work?
christian.loose at hamburg.de
Sat Jun 7 15:21:43 BST 2003
Am Samstag, 7. Juni 2003 13:36 schrieb Simon Hausmann:
> Asking the obligatory question :) : Why use a separate process for
> this very task in the first place? Are there locking issues that are
> very hard to solve when doing the CVS handling in-process (i.e.
> launching the cvs process from inside cervisia, not using a second
> proxy process) ?
Sometime ago, after looking at George's dcop services
(kdenonbeta/dcopservices), I was thinking about creating a cvs dcop service.
I started to make one, because I hoped that it would evolve in to a global
KDE service, so that it would be easy for other apps to provide version
control functionality (Quanta, KDevelop, file dialog, etc...) to their users.
Since I was working at a cvs tool anyway, I started to also work on Cervisia.
In Cervisia, the functionality was tightly coupled to the GUI, so I was
thinking about how to separate them. Well this is, when my cvs DCOP service
came into the game. That's it. :-)
> It seems to me that there is a lot of communication between the cvs
> service process and cervisia as client, which is where things get
> complicated with DCOP (how to recover when the process dies?) .
> Imagine how simple the code in cervisia could be if you could deal
> with CvsJob C++ objects directly.
> Just a though. Feel free to ignore :)
Well, the code is simple, thanks to dcop stubs. :-)
Error handling might become a problem. But I guess that's a problem that other
DCOP services (KWeather, RSS news feed, etc) also have, so maybe we should
think about a more global solution. Just a thought. :-)
More information about the kde-core-devel