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

List:       kde-devel
Subject:    Re: Single instance only applications
From:       Cristian Tibirna <ctibirna () total ! net>
Date:       1999-07-29 17:18:48
[Download RAW message or body]

On Thu, 29 Jul 1999, Carlo Robazza wrote:

> Hi there,
> 
> I have been given the task of ensuring that kcontrol and its associated
> modules can not be run in multiple instances. I am planning on using
> lock files but there are a few problems with that method and would like
> to get your opinions.

Lock files are generally a poor solution and a security hazard quite
oftenly.

IPC or XAtom checks are oftenly much better (IMHO).

> Using a lock file for kcontrol works wonderfully. However, I run into
> problems with modules like kcmdisplay. It is called with an argument to
> start up different components like screen saver, etc. The problem I run
> into is sort of a catch-22 situation. I can lock out kcmdisplay but the
> user doesn't know that when they click on screen saver they are actually
> starting kcmdisplay with a parameter. So, what message do I give them? I
> can't say that screen saver is already running because it isn't. I can't
> tell them that kcmdisplay is already running because they won't know
> what it is.

Let's check if I understood well:

kcmdisplay colors

runs already. Then user clicks on Settings/Screensavers hence attempts to
start 

kcmdisplay screensaver

Well, if you insist to use lock files, you can just write some text into
the file so that such multi-instance programs can check and decide if
they're allowed to run another instance exactly because another option is
used. E.g., writing "screensaver" in the lock file, will allow kcmdisplay
to spawn a new process if you attempt to run `kcmdisplay color` but not if
you try to start `kcmdisplay screensaver`. But, once again, lock files 
are a poor solution: a) because user can change them (their name,
delete them, or change their contents) b) and what you can do if you have
`kcmdisplay screensaver` running and user tries to run `kcmdisplay` (with
all tabs). Then you certainly want to have `kcmdisplay` running, but
you'll have the screensaver functions duplicated (which is wrong, I
agree).

> I could lock out the different components of the modules but there might
> be more than one component/module modifying the same configuration file.
> I guess I could lock out the configuration file that is being written to
> and let the user know that the file is locked so the changes couldn't be
> saved.

This is way too complicated. Better is to use IPC or XAtoms. That way you
can even pass complex messages and assure complete checks by some
intelligent code.

> Another question is, if we decide to lock out the applications, do we
> build the lock file feature into the KApplication constructor as an
> option?

Well, that was the plan. I mean, to have such a function in KApplication.
But I disagree with the lock file solution.

I believe that the lack of interest so far inside the project was induced
by the hope that once the CORBA mechanisms will be in place, all such
issues will be much easier to solve using CORBA methods.

Please, remember that KDE-1.2 is the last release of the 1.X series, and
all revolutionary (or almost :-) innovations and inventions go to KDE-2.0
 
> And finally, are there any methods for communicating between different
> applications?

IPC and XAtoms :-)

Look at how kikbd assures uniqueness on a desktop/screen/rootwindow using
Atoms.

Thanks for listening, Carlo

Cristian

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