Re: hacking on same-gnome

["Callum McKenzie" <callum physics otago ac nz>]

>> In the end session saving is just a specialised way of doing automatic
>> saving. Doing automatic saving properly is difficult but highly
>> desirable.
>> You don't have to treat each sub-game separately, but you do have to
>> treat
>> each instance of the program separately. Although as you point out there
>> would have to be queues based on game name (or somethng else hidden in
>> the
>> .desktop file) so that the same program called in different ways does
>> the
>> right thing.
> Uh, this sounds like treating each sub-game separately would be the
> easiest way. Someone could easily have made other shortcuts that use
> --variation.
>
My vision was to have a stack of saved games. Each time you close you add
the game to the top of the stack, then when one is opened you remove it
from the stack. (Note how this doesn't handle the program-crash case, but
the data might have been bad anyway.) If we tagged each saved game with
the variant name then if the variant is selected explicitly we just search
down the stack for the first matching game which we then remove form the
list and use (obviously no match = new game).

Technically the "stack" would probably be a separate file which just lists
the files with the real saved games in the appropriate order with the
appropriate meta-data. This decouples most of the save-game logic from the
automatic restore logic which means the save-game logic can be written and
used in other ways until such time as the stack code is written (or proven
to be complete crack).

> I'm not convinced there's a sensible behaviour for the case where you
> run two instances of the same subgame simultaneously. Someone opening
> two instances of a game, partially playing through a game on one
> instance, closing it, reopining without closing the first one, and
> then expecting to get the game back, uh, seems highly unlikely and not
> worth planning for.
Well the stack does solve this for free. Opening a game opens the most
recent closed game. As for a plausible scenario: open a game in one
workspace, play it a bit and then leave it open. Do some real work in
another workspace and forget about first game. Decide you need a break, so
start a new game. Then you hear the boss approaching, so you quickly close
it. Once the boss has passed you open it again - you're going to be
surprised if it is a different game than the one you were playing.

Now that scenario has the problem that you may have remembered the last
game, but forgotten that the instance was still running. Then you might be
surprised that the second instance doesn't open with that game. Hopefully
you will remember the unclosed game at this point - but I wouldn't
guarantee it.

The other option is to only have one instance of the game running ever.
i.e. in the scenario above you launch aisleriot the second time and rather
than opening a new window you get transported to the first instance
somehow. Personally I hate that sort of behaviour. (It would also be a
pain-in-the ass for development purposes when I often have an old and a
new version of a game open for comparison purposes - but the person
playing the game should be the consideration here.)

Either way we should try and treat every case the best we can.

 - Callum