xboard-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [XBoard-devel] gtk update


From: Arun Persaud
Subject: Re: [XBoard-devel] gtk update
Date: Thu, 16 Jun 2011 10:28:45 -0700
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110414 SUSE/3.1.10 Thunderbird/3.1.10

Hi

> So what is the planned path to the GTK porting now? After the Engine #N
> Settings is ported, most dialogs and auxiliary windows should work in GTK.
> It would leave:
> 
> Engine Output
> Move History
> Game List Tags
> Main window
>
> I want to start working on the Move History, to make it WinBoard style.
> This should result in a completely front-end-free implementation, which I
> then also want to put into the X-version development branch.

I'm working on the game list at the moment. John Cheetham is also
joining in (GNU paperwork is being filed, so he should be able to commit
to git soon) and starting on ErrorPopDown and ErrorPopUP and perhaps
some other smaller items.

So Move History sounds good, if you want to give it a try

For some of the windows we might be able to use some nicer features of
GTK, for example I could think of a tabbed interface for the
preferences? So whoever finds something implemented in some other GTK
program that they think would be nice to have in xboard, feel free to
post it here...

> Then I would probably want to try my hand at some modest GTK stuff, to see
> if I can enhance the GTK port of the generic popup to also do the Engine
> Output window. (This would require equipping Label options with some
> formatting info in currently unused fields of their Option struct, that
> will cause them to be displayed with specified size on the same line,
> rather than always taking on the full width of the dialog, and panes to be
> stacked rather than displayed side by side, under control of an extra
> modifier bit in the break option. These should be very easy changes.)

sounds good... but perhaps it's in some cases easier to just write a new
glade file than creating new generic popups.

> That leaves the Game list Tags (about which I am not yet decided), and the
> main window.
> 
> We could throw out the promotion menu completely. At first I thought it
> would have to stay in for the benefit of the JAWS version, but the easiest
> way for blind people to enter moves is to type them (which requires far
> fewer keystrokes than indicating from- and to-square with the keyboard
> arrows), and in that case they might as well type the promotion piece. The
> drop menu is also deprecated, now we display holdings. Only the piece menu
> might still be of importance to the blind to set up a position; but I
> think it would be just as easy for them if I replace it with a keystroke
> that would upgrade or downgrade the piece on the currently selected
> square, reading out the new name. To them that would basically be exactly
> the same behavior as using the arrow key to step through a menu, and have
> the screen reader say the items.

I think GTK also has some option to support accessibility, I haven't
looked into that, but we need to do that at one point...

> Can the changes that have been done in xboard.c for the plain GTK version
> be easily transferred to the gtk-xt version? I don't recall I did that
> many changes in xboard.c. (I did move some drawing-initialization code
> around to put it in separate subroutines, to make it callable during a
> session, though, for the benefit of the Board Options dialog.)

Most changes from the old GTK-branch can be transferred, but the old
version wasn't complete (e.g. no variation support) and many things have
changed, so it is probably easier to recode things and use the old
xboard.c and especially the glade file as a template.

As for how we should go ahead, I think it should be easier now to keep
two branches up to date in parallel... If you can get the Xt side into a
state where frontend and backend separation is where we want it, I think
that would be great... I'll try to merge the gtk version as often as
possible with master. We just  should make sure that we don't work on a
xt->gtk transition before the code got cleaned up.

Apart from the list you mentioned there is also the help menu that could
be updated and I think lots of other smaller items.

Arun



reply via email to

[Prev in Thread] Current Thread [Next in Thread]