Re: [XBoard-devel] gtk-branch

[Arun Persaud]

Hi

>> [getting rid of the terminal]
> I must admit that the xterm for me is often a very useful debugging tool.
> It is much easier to ustthrow in a few printfs andlookat what they do
> in real time, than making debug files all the time. For this reason I
> usually do most of the backend development on Linux now.

we only would get rid of the terminal for the ICS user, so debugging on
the terminal will always work...

>> * Add theme support: [...]
> Not sure how this offers anything different from what we already have.
> We can distribute a zipfile with textures and piece bitmaps, and a
> theme.ini file with it, so that people can run the theme by simply
> starting with the option @theme once. [...]

would make it easier in the sense that the end user doesn't have to
unzip files and put them in the correct locations, etc. all you would
need to do, is tell xboard where the zipfile is and the rest would be
automated...less chance for the user to mess things up. It also makes
distributing themes easier, the ini-file could provide an email address
for feedback to the person who made the theme instead of us getting bug
reports ;), it's easier to include error checking (e.g. are all the
necessary icons provided in the theme), it would be easy to automate a
theme page where people can download and upload them.

Since using theme is also a common problem, there might be already some
libraries out there we could use?

>> * Too many windows? At the moment XBoard can clutter the workspace with
>> tons of windows, perhaps we can reduce the number of windows used for
>> preferences and also include some other windows into the main window?
>> Perhaps use dockable windows to maintain the freedom to place the
>> windows where you want them?
> 
> I have always thought the large number of windows was one of the most
> attractive features of WinBoard. What you are not interested in, you
> simply close, and it will no longer bother you. I am not sure what exactly
> you mean by 'dockable'. Is this different from what WinBoard does now
> with the -stickyWindows option?

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...
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.

>> * I'm also for using only scalable graphics for the pieces (e.g. svg)
>> and make the window scalable and get rid of all the size option for
>> xboard.
> 
> In principle the scalability is great, but it breaks backward compatibility
> for people who have designed their own piece sets. I don't know how easy
> it is to make SVG pieces compared to making pixmaps. 

I don't think it's a lot harder... you can use inkscape for example

> The font-based
> rendering of WinBoard is equivalent to SVG, but it is a pain to make fonts.

I never really looked into this, but a while ago I had a look at some
fonts and the ones I looked at where actually generated as svg and then
converted to a font... so at least for those it would be easy :)

> I imagine many people would make pieces by simply taking a screenshot
> of a diagram they like, and cutting it to pieces with a program like MS
> Paint
> or GIMP. I doubt there exists an easy way like that to make SVG pieces.

it's a bit more complicated, such as dropping the bitmap into inkscape
and redrawing the lines...

One easy way out is of course that svg can include bitmap files, so we
could just convert them easily that way (will probaly not look good when
scaled though).

> So getting rid of the -size options is fine by me, but I think many people
> would be very grateful if we kept supporting the possibility to use a
> set of pixmaps (of any size, the size then locking the board to the
> size that belongs to it).

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

>> [...]
>> As far as timeline goes:
>> In general I think that as soon as we can turn off all the X-code and
>> are able to cross-compile for windows, we should move master to gtk
>> and only do bugfix-releases for the 4.x.x branches. What do you think?
> 
> It depends on the quality of the gtk. Getting rid of the X-code is
> not the same as having the gtk do everything that the X-code does now,
> or do it equally well, and certainly not that it does it equally well as
> WinBoard. So my main development will remain in whatever branch
> the version is in that is my main GUI in everyday life.

I think once we can cross-compile, we should be quite far advanced and
if we switch the main development to GTK at that point, we should be
able to catch up to Winboard and XBoard very fast and in the process fix
the things that are not working 100%.

> Last time I looked at the GTK version, there was still a very long way
> to go before it would be acceptable for using. E.g.
> *) animate dragging
> *) animate moving

those two might take some effort, but I don't really think that it's
that complicated

> *) using the xiangqi board pixmap as background
> *) displaying any non-orthodox pieces

This is just a matter of creating the svg and making XBoard load them.

More complicated is probably getting xboard handle the different board
sizes.

> are all major things that do not work at all,and highly non-trivial to
> program.
> And I haven't tried things like the seek graph yet.

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... that's why I think that
once we are able to remove all the X-code we should be in a position to
swap gtk with master... At which point winboard will also still exist,
just the old x-code will be gone from development. The next step would
then be to get parity with winboard and after that it's back to normal
development just with GTK.

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...

cheers
        ARUN