[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: KApplicationServer?
From:       "Friedrich W. H. Kossebau" <Friedrich.W.H () Kossebau ! de>
Date:       2002-08-25 16:52:03
[Download RAW message or body]

Tim Jansen wrote:
> 
> On Sunday 25 August 2002 14:56, Friedrich W. H. Kossebau wrote:
> > * for kuniqueapplication check if an instance is already running by a
> > simpel lookup in the table of running apps. Should be a lot quicker than
> > to first go the long way of loading and linking the executable only to
> > find out there already exists an instance.
> 
> I also thought about doing something like this. The trick is to use the
> X-DCOP-ServiceType in the .desktop file, and if the app to start is a unique
> app, just ask the window manager to show the app's window instead of starting
> the new process. Unless somebody finds a reason against this, a patch for 3.2
> would be appreciated :)

Sorry to disappoint you: Not only don't I have KDE 3.x installed but am
I heading to finish work on my diploma thesis. You can guess what I
would like to do more ;) but all I can do is dreaming and thinking about
KDE things (because I can't stop this; i.e. I have to write such emails
to get rid of these thoughts at least). Hopefully you or somebody else
might find my ideas usefull.

> (BTW There is no need to have a special table of apps, because each KUniqueApp
> is already registered in the DCOP server).

Nice to know (hoping for a free time besides regular job time in the
near future ;) (but don't count on me, I haven't managed this for the
last two years)
 
> > * for _stable_ running normal kapplications the request for a new
> > document window would be transported (via DCOP) to an already running
> > instance of the same app. Perhaps this could be limited to the scope of
> > a desktop so that in the case of a crash one doesn't loose all windows
> > of an app.
> 
> The problem here is that in the case of a crash you lose everything. That is
> why I often have several instances of Konqui running instead of opening new
> windows.

That is why I emphasized _stable_.  I have my experiences, too... ;)

> But it should be possible that the app launcher sends a DCOP message to a
> running instance of the app to ask whether the app would like to open a new
> window or the launcher should create a new process.

Idea:
----
What about this (ignoring the fact that app settings changes by now
effect all the "windows" of the same process):
Each app controls up to x "windows" (read documents/files/...) in a
process. For some further "windows" a new process is started. This way
the amount of lost "windows" is bordered. The value x might be, yes ;),
configurable by the experienced user. One more: when there are already x
"windows" opened by a process it could start the next process in the
back to have it there right on demand for the next "window". Wow, this
might make KDE feel totally fast :)

Hey, more stuff for thinking. I have to go out again and do cleaning of
flood trashed things...

> > 1. Now I am curious whether there is already such an infrastructure in
> > KDE 3.
> 
> No.

Maybe I am on track for KDE 4 ;)
 
> > 2. Would it be possible to get another independently running instance of
> > an app (e.g. kwrite) by doing a fork() (no experience) in the app, this
> > way circumventing the loading and linking while being save from the
> > crash in another "window" of the app?
> 
> kdeinit already uses forking to avoid some linking. Doing a fork in an app
> that is already running would be extremely complicated (because that would
> duplicate everything, including things like the X11 connection and the DCOP
> handle).

To ask more precisely: 
What is faster, starting a new executable or forking a already running
instance? After a fork I expect all the data of the forked process have
to be resetted to get the state of a fresh started app, right? 
So it would not make much sense to fork especially for processes with a
lot of allocated memory, right?

But if I have understood you correctly this is more like: would these
questions have made sense? ;)

Friedrich
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]