On Jul 24, 2010, at 3:46 PM, Krzysztof Kosiński wrote:
There are only two sane approaches:
- Open every document in the existing instance.
- Open each document in a separate instance.
[SNIP]
Advantages of #2:
- better stability: crash will only destroy unsaved work in the window
that crashed
- different versions of the executable can be run side by side naturally
- easy to implement
Another advantage is leveraging multiple cores on a single box. For modern systems, it's slightly frustrating for end users to see their CPU use max out at only 50% or 25% and have to keep waiting two or four times as long for Inkscape to do something. Of course, this is a short-term advantage, but one many people have been leveraging for some time.
Commercial vector editors usually go for #1.
There are many strong reasons to look at this. However... in the past year or so applications have started doing "process per document", even if they are presenting inside the same GUI. We might want to look and weigh/evaluate some of the same reasons web browsers are switching to this approach.
IMO the preferences issue is the largest obstacle to #2. It means we have to use IPC in both cases, but in #1 we only use it to tell the running instance what to open. In #2 we have to synchronize a lot of settings over the lifetime of the application and propagate change notifications to all instances.
There are actually some very simple ways to address this. And we do have two separate areas to work on: 1 - Inkscape code needs to be changed to update the UI in response to preference changes. 2 - Inkscape needs to sync changes between instances
For problem number 1, we have to address things anyway. There are several bugs that currently are happening due to preference changes not being reflected properly in the UI (there are many widget-bound workarounds, but we did see a slew of these types of bugs in winding up 0.48). So that's a "we need to code this regardless" point.
For problem number 2 a very simple mechanism would be to watch the preferences file and reload it when it changes. Then instance A writes out a change and instance B, C and D see and pick this up. This may not be as elegant as a DBus based solution, but it does have the advantage of being doable with existing code in Inkscape.
It is not the business of the user, because most users do not know what an application instance is and how it's different from a window. But the application cannot ignore this issue. Otherwise we get really weird behavior.
This is a *very* good point. We definitely need to keep that as a prime concern.
On each build we can generate an UUID to be stored in inkscape-version.cpp and start a new instance if there's no instance with this UUID already running. There's a little more complexity in it, because we need to generate a different exclusion ID for every user session, so if you log in locally, start Inkscape, then lock the screen and log in remotely via SSH, you can start a distinct instance of Inkscape.
We also would need to tie things to different environment variables, etc. If one launches an instance of inkscape with different XDG variables from a current instance of the same version, things still should treat that as 'different'. And there are a few other such factors to consider. So it does look as if UUID itself does not solve the problem.