Re: Gtali



On Tue, 2004-03-16 at 16:07 -0600, Trevor Hamm wrote:
> Thanks for the suggestions. I've attached a new patch for gtali with the
> changes I've made so far. It basically obsoletes my earlier patch in
> Bugzilla. The changes made by this patch are:
Could you also add the patch to your bug report. This makes sure I don't
loose it.

Naturally I'm at work and haven't had a chance to try the patch yet, but
here are my comments on the bullet points:
> 1. Adds the toolbar to the game window with the layout:
> 	New  Quit | SelectAll DeselectAll Undo
> SelectAll and DeselectAll are new functions which select all dice and
> clear all dice selections respectively. Keyboard shortcuts and menu
> entries for these functions haven't been done yet.
Are these entirely necessary ? I certainly haven't noticed the lack of
such functionality when playing. I'll try it out and see, but it strikes
me a creeping featurism. The obvious keyboard shortcut for select all is
of course Ctrl-A. There doesn't seem to be a corresponding standard for
unselect all, but the gimp used Ctrl-Shift-A.

> 2. Inserts a label above the dice which displays the roll number. This
> serves two purposes: (a) Tells the user how many times the dice were
> rolled this turn, and (b) provides that "buffer zone" between the top
> die and the toolbar/menubar.
Yeah, this is a good idea. Definitely something that has been missing.
Maybe the roll button should be disabled when three rolls have happened
too.

> 3. Bolds the text for the special rows (totals and bonus) in the score
> display, which sets them apart from the other rows that respond to mouse
> clicks.
Also good. I don't know why we didn't do this while fixing bug #92801.

> For the Preferences dialog, I had an idea to combine all the player
> options into a single GtkTreeView, with one column for the player's
> name, and another column with a toggle button to switch between Human
> and Computer. The user could add and delete players from the list with
> buttons, and edit the player options (name, human/computer) right in the
> list. This would also eliminate the need for the two spin buttons for
> number of players. Does this sound reasonable?
My one worry about this scheme is that it doesn't give any visual
indication that the code only allows six players. I suppose the correct
solution is to remove the arbitrary six player limit (which would take a
bit of care since I seem to recall that there are fixed length buffers
everywhere). Code it anyway, it will still work even if we haven't fixed
the six player limit.

 - Callum








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