[scribus] Multiple instances of Scribus

[John Brown]

Craig Ringer wrote:
> 
> John Brown wrote:
> 
>>> That's a lot of platform specific messing around, though, for a pretty 
>>> trivial feature. Personally I wouldn't bother.
>>>
>> 
>> A simple way would be to create a lock file the sole purpose of which
>> is to indicate that Scribus has already opened the file.
> 
> Lock files are IMO about the *worst* way of doing it.
> 
> If Scribus crashes, the lock file may not be cleaned up
> (depending on whether or not the crash handler can run successfully).
> 
> This is OK on non-networked storage, because we can store the process
> ID in the lockfile and see if there's a Scribus process with that ID
> running. If there isn't the lockfile is clearly stale and can be removed.
> 
> On network storage, however, we cannot test to see if the lockfile
> creator is still running. In fact, even if the lockfile creator is still 
> running, it might no longer have access to the network volume. That 
> leaves the poor user to deal with the mess.

The whole point of issuing a warning is to give the user a chance to
take some action. All Scribus has to do is give a warning that somebody
may be in the file (like vi). Whatever happens, well, it tried. 
> 
> Avoid lock files at all costs. If locking is required, it's much better 
> to use the advisory or mandatory locking mechanisms provided by the 
> operating system.
> 

Which you don't want to do because it is too much work. The lock file is
less work, isn't it?

> QuarkXPress has an interesting spin on lock files. It creates a 
> temporary file in the same directory as the original file, and holds an 
> exclusive access file handle open on the temporary. Nobody else can 
> create a temporary with the same name, so the file is "locked" that way. 
> If the Quark user loses their connection the file handle on the 
> temporary is closed and another instance can open it and offer to 
> recover the unsaved work, or can just delete and recreate it when 
> opening the file again.
> 
> Scribus doesn't need such temporaries, so it makes more sense to just 
> lock the original file if that's desired.

You just rejected what seems to be an elegant solution.
_________________________________________________________________
Back to work after baby–how do you know when you’re ready?
http://lifestyle.msn.com/familyandparenting/articleNW.aspx?cp-documentid=5797498&ocid=T067MSN40A0701A