From kde-devel Sun Aug 25 16:52:03 2002 From: "Friedrich W. H. Kossebau" Date: Sun, 25 Aug 2002 16:52:03 +0000 To: kde-devel Subject: Re: KApplicationServer? X-MARC-Message: https://marc.info/?l=kde-devel&m=103029438831302 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 <<