View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0007018 | Scribus | Internal | public | 2008-05-11 16:37 | 2019-10-11 08:11 |
| Reporter | Assigned To | ||||
| Priority | none | Severity | feature | Reproducibility | N/A |
| Status | new | Resolution | open | ||
| Summary | 0007018: Single instance per user support | ||||
| Description | Some 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? | ||||
| Tags | No tags attached. | ||||
| Patch | |||||
|
|
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. |
|
|
What about tabs instead of MDIs? |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2008-05-11 16:37 |
|
New Issue | |
| 2008-05-11 16:37 |
|
Reported by | => Thread: Multiple instances of Scribus, first msg 2008-04-28 |
| 2008-05-11 16:37 |
|
Reported where | => Mailing List |
| 2008-05-11 16:38 |
|
Relationship added | child of 0007017 |
| 2008-05-11 16:38 |
|
Relationship added | related to 0001926 |
| 2008-05-11 16:40 |
|
Note Added: 0019657 | |
| 2008-05-11 16:48 |
|
Priority | normal => none |
| 2008-05-11 16:48 |
|
Description Updated | |
| 2010-01-13 19:08 | Bernhard Reiter | Note Added: 0023080 | |
| 2019-10-11 08:11 | jghali | Relationship added | has duplicate 0015847 |
