Re: [XBoard-devel] gtk-branch

[h.g. muller]

At 14:31 12-10-2011 -0700, Arun Persaud wrote:
> we only would get rid of the terminal for the ICS user, so debugging on
> the terminal will always work...

OK, good. In WinBoard stdout is always closed, and for developing that
can be a real pain.

> Well for some items I think it's nice to have them in separate windows,
> but I don't see the point in for example for all the preference windows...

I am not sure what exactly you mean by 'preference windows'. When I
talk about windows, I mean things like engine output or game list,
which you would like to be in constant view because they provide core info.
Menu dialogs I don't really count as windows. There can be only one up
at a time, and it does a grab-exclusive, so it does not matter what it covers,
because you could not do anything with that anyway.

> As far as dockable windows, Inkscape for example has them  (at least on
> linux). Preference windows start as part of the main application, but
> you can drag them outside the main application and they get their own
> window. You can also drag them back into the main application and they
> merge back into it... That way, if there are in the main application
> they take up less space or you drag them outside and position them
> whereever you want.

Sounds a bit like floating toolbars. I never used Inkscape, but I will 
check it out.
I still can't imagine well how something like that could be applied to XBoard's
main window, because the board is inflexible. I have seen Windows applications
working with panes, and there, when you drag a floating window onto the
main one, it some times merges in by reducing the hight of the remaining
panes that were already there.That is nicefor texts, but you cannot very well
reduce the width of the chess board by half, and provide a vertical scroll
if there happened to be something on the part of the board now out of view...

> I rather get rid of it completely and provide a way to help migrate
> those to svg. I'm happy to help out there...

Well, as warming up you can try it out with the shogipixmaps...

> yep, those things will probably take most of the work... and at the
> moment they are implemented in X and therefore need to be ported first
> before we can remove that piece of X-code...

Actually the seek graph has very good frontend-backend separation,
and hardly touches the front-end at all. The only thing it needs is routines
to draw squares and dots of requested sizes at requested positions.
It can probably be converted inless than 10 min by someone who knows
how to draw in GTK. Mouse handling is 100% backend there.

> I just think that having a clear idea at what point we will switch, will
> make it easier to avoid too duplicate work on 3 frontends, instead of
> just doing it in the GTK version...

Well, speaking of front ends, how about an Android front end?