[scribus] Multiple instances of Scribus

[Craig Ringer]

Gustavo Homem wrote:
> Hi,
> 
> Running Jumping late on this thread I'd like to point the fact that when a 
> user double clicks a .sla file a new instance of Scribus will allways be 
> launched, regardless of whether or not Scribus was already running.
> 
> This is, to me, an usability problem and the opposite of what users expect 
> from current software.

It certainly differs from how other apps in the same broad domain (GIMP, 
OpenOffice, Quark, InDesign, etc) work. It's also costly with something 
as memory-hungry as Scribus.

> In this regard I think Scribus should behave as the other common desktop 
> aplications where the running instance is reused for when more documents are 
> opened (See Adobe Reader, Firefox, Kaffeine, etc).

I generally agree. Single-instance-per-user seems to be surprisingly 
hard to get right, though. I'm always having to kill half-exited firefox 
and thunderbird instances off the thin clients at work then manually 
remove their lock files.

OpenOffice on some of the Windows machines likes to die while leaving a 
process running, too, so a new instance can't tell the lockfile is 
stale. This leaves users wondering why nothing happens when they try to 
open a document - because the new OO.o instance signals the zombie one 
to open the file, then exits, but the zombie one never acts on the request.

As Scribus is single-threaded and single-process it's probably not going 
to have too much trouble with these issues. That has its own issues too, 
though. Scribus often enters states where it doesn't return to the 
normal event loop for long periods. It would be unable to process queued 
messages (like "open this file") while in those states, so if Scribus is 
busy doing something opening a file might take quite some time with no 
visible feedback.

If single-instance-per-user is attempted, it's important to think about:

- Multiple users per machine (win32 "Fast User Switching", multiple X 
servers on UNIX, X11 thin client terminals, etc)
- Handling of an instance that is unusable and broken but has not exited.
- Handling of an instance that is working, but busy and unable to open a 
file for an unknown period of time.
- Handling of stale lockfiles and other state caused by a sudden program 
crash, hard system reboot, etc.

--
Craig Ringer