View Issue Details

IDProjectCategoryView StatusLast Update
0007018ScribusInternalpublic2019-10-11 08:11
ReporterringercAssigned To 
PrioritynoneSeverityfeatureReproducibilityN/A
Status newResolutionopen 
Product Version 
Target VersionFixed in Version 
Summary0007018: Single instance per user support
DescriptionSome people want single instance per user support, where new documents opened get a new subwindow in an existing Scribus instance.

Pluses:

- Saves RAM
- Saves startup time
- Some users prefer this UI model
- Eliminates confusion - when I make a new doc or open one from within Scribus I get a new MDI subwindow. When I open one externally or use a Windows template to make one, I get a new Scribus instance.

Downsides:

- Wasted RAM due to heap fragmentation (of which there's a vast amount in Scribus), any subtle leaks, no-longer-required big fonts, etc will remain loaded and waste RAM. Not as bad as it sounds because the OS can swap most of this crap out.
- If Scribus crashes, all documents go down at once.
- MDIs are horrible. Horrible. Horrible. See related.

Issues that must be considered:

- An unreliable single instance per user setup is way worse than none at all. Lockfiles are of extremely dubious reliability when faced with NFS home directories and similar. A practical implementation must make use of OS-level mutural exclusion, and should have the ability to detect and KILL a non-responsive existing instance.

- Aliveness of the instance means more than "responded to open document message". A document open helper (like gimp-remote) should stick around until the app confirms the document was successfully opened. If the app crashes, fails to respond, etc, the helper should offer to close the program and restart it.

- The launcher must be designed never to block on the main instance without a timeout or other handling of a non-responsive main instance.

- It should be possible to disable single-instance-per-user operation and launch multiple instances.

- The app must, even if it's designed never to permit multiple instances, cope with multiple instances accessing the same config files etc. Consider NFS home directories, where there's only one instance on a given host but the user might've left Scribus running on another host with the same config files.

I'm not sure what the best option is. There are articles out there on implementing correct single instance behaviour (it's harder than it sounds).

A critical test is: if you attach a debugger to the master instance, pause its execution at a random point, and attempt to open a document, does the launcher detect and kill the non-responsive master?
TagsNo tags attached.
Patch

Relationships

related to 0001926 closedale Single-document interface mode 
has duplicate 0015847 closedjghali Single instance mode doesnt work on windows 
child of 0007017 acknowledged Metabug: Multiple instance safety / single-instance-per-user support 

Activities

ringerc

2008-05-11 16:40

reporter   ~0019657

IMO this is only viable if Scribus's GUI can be separated out to the point where it can support either:

- windows where each has its own toolbars, menus, etc (like OO.o) as per 0001926; or
- Free-floating document windows that share the same toolbars, etc, like Photoshop on Mac OS.

MDIs, without the option to avoid them by launching new Scribus instances, will drive many users insane.

Bernhard Reiter

2010-01-13 19:08

reporter   ~0023080

What about tabs instead of MDIs?

Issue History

Date Modified Username Field Change
2008-05-11 16:37 ringerc New Issue
2008-05-11 16:38 ringerc Relationship added child of 0007017
2008-05-11 16:38 ringerc Relationship added related to 0001926
2008-05-11 16:40 ringerc Note Added: 0019657
2008-05-11 16:48 ringerc Priority normal => none
2008-05-11 16:48 ringerc Description Updated
2010-01-13 19:08 Bernhard Reiter Note Added: 0023080
2019-10-11 08:11 jghali Relationship added has duplicate 0015847