[ ... ]
> Unfortunately it does not. But I remember that you fixed
> this problem some time ago for the former versions already,
> so it seems an old missbehaviour to be reintroduced here.
>
It seems to work for me, even if not perfectly. Note that windows are
"deiconified" but some may stay below others. That is you may see the Main
window but the PGN window may be overlapped by Firefox for example.
I will try to fix this, but not a big priority for me.
- Docked mode ignores autoopen windows (Options /
> Startup)
>
> Fixed. But for example restoring the PGN window has no
> sense if you don't know where to put it in the tree of
> sub-windows / notebooks.
>
I agree. Though I do not know how you want to handle it,
> thats why I reported the missunderstandable GUI here. I
> think there are two logical ways to do it:
>
> 1. Disable the "restore windows upon startup" in the new
> mode and have them only in classic mode. This goes with a
> dedicated mode separation.
I agree this is a good solution. Note that menu entries should be accessible
in any mode (because the user may switch from one mode to another).
>
>
> 2. Integrate both modes into window placement so that no
> "startup windows" would be necessary and one could just close
> Scid down and gets all windows, tabs and whatsoever restored
> when one restarts Scid. I think it would be imperative here
> to store also the windows docking state, and this would also
> mean to handle individual windows and tabs at the same time
> and to get rid of the different modes for only one windowing
> mode that allows docked and undocked windows simultaneously.
My first idea is
- to prove that docked windows is feasible in Tk -> ok, done
- see if it's far better than classical mode -> ok, done (from my point of
view)
- polished -> not yet, for example mouse wheel does not work in main board
right now, and I am not sure to be able to solve all shortcut problems
So for now I made things so the classical mode is left unchanged (a kind of
backup mode, in case ... ).
>
>
> I think, from a coders point if view the first option it the
> least work, and most likely the one to go for the time
> being.
Yes, I will remove the autostart of windows, given that the layout #1 can
already be auto-started in docked mode.
>
>
> However, from a users point of view I think the second one
> would probably be the best and ease up the GUI as well as
> one gets rid of modes.
The way I coded things, I can leave the classical mode here. But if nobody
needs it any longer, I can switch to a docking only mode, where any window
(except main board) can be undocked. That's not a problem.
[...]
> Additionally, I think (I may be wrong
> here) that if restoring a layout also handles undocked
> windows properly one is almost there already.
>
Not done yet, but pretty straightforward. First I'd like to know what is the
fate of the classical mode. I personally no longer use it.
>
>
> So the use of the menu save / restore layout is certainly
>> a better alternative (I set an auto load option for one of
>> the layouts).
>>
>
> This will then also point towards alternative one above, ie.
> strict separation of both modes, and then only suitable
> menues should show up, I think. Otherwise it is a bit
> confusing.
Confusing, I agree. But I am also a bit disturbed by menus changing
depending upon the context.
Pascal
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Scid-users mailing list
Scid-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/scid-users
