bug-gnubg
[Top][All Lists]
Advanced

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

Re: [Bug-gnubg] Menus + Toolbars


From: Christian Anthon
Subject: Re: [Bug-gnubg] Menus + Toolbars
Date: Fri, 29 Feb 2008 11:34:47 +0100

On Fri, Feb 29, 2008 at 10:34 AM, Jonathan Kinsey
<address@hidden> wrote:
>  Massimiliano Maini wrote:
>  >
>  > File menu:
>  > * Maybe "Load command file" and "Generate html images" can be hidden
>  > somewhere else, guess they are not often used.

The load commands file naturally belongs here.

>
>  I agree, I doubt many people use either of these.  The "Generate html 
> images" could probably be a button in the export settings dialog.

This is mostly redundant as the code automatically checks for the
existence of the image directory and creates it as necessary.

>  Copy as could easily be moved to the game menu.  I always found it odd that 
> there isn't a menu entry which corresponds to the edit button, I think there 
> should be a "edit position" entry somewhere.

I believe that the copy/paste/edit functions naturally belong in the
edit menu, I'd rather move a few things from the game menu into the
edit menu.

>
>  > View menu:
>  > * The Python shell thing does not work for me (and in the past it
>  > has been a pain). Is it useful anyway ?
>  > * I would add a menu for swapping the direction (like the Direction
>  > toolbat button). Maybe something like "Play clockwise" (checkable).
>
>  I agree with both of these points.

Agreed. Though I don't know about the python shell thing, it is
currently the only way that windows user will be able to run python
scripts. But I'm still an advocate of removing python entirely now
that the db code has been ported to native sqlite.

>  > * Eval: what's used for ? Just the name of the evalulator ?
>
>  I think it can be useful in some obscure cases.  Odd things like this should 
> be removed from the menus (and only accessible from the command window), IMO.
>

The eval function is useful to get information on how a position is
evaluated so I believe that we should keep it as it is.

>  > * Analyse: separate submenus for match and session ?
>
>  I think we should have a dialog for a single menu (and toolbar) "Analyse" 
> command, here you could select match/game/move, whether to add to the 
> database, whether to open the statistics at the end, a button for the 
> analysis settings etc.  If the options are remebered, this will be quicker 
> than doing it manually.

Needs some thought, and worse work, but besides that it could be good.
What I miss most at present is a swift way to set up a position (and
dice for a move or no dice for a cube action) and have that analyzed.
Right now you need to do setup -> complete move or cube action ->
navigate back -> analyze move otherwise we don't have a move record to
pin the analysis result on.

>
>  > * Game stats/Match stats/Session stats: maybe only one can do the
>  > work, since match/session stats are the same and game stats can be
>  > accesses from match/session stats.
>
>  Yes, just have stats, and select the game from the list.

Agreed.

>
>  > * Player records + Add to player records: do we need to keep this ?
>  > The relational DB looks much more powerful (and culd be just as easy
>  > to use).
>
>  This is very likely to be removed soon, or more likely the same two entries 
> will add to the database rather than the file (and the rel db entries 
> removed).
>
>  > * Distribution of rolls: uh, first time I use the feature. Cool !
>
>  > * Eval speed: maybe to be put in "Settings/Options/Others" dialog,
>  > under the number of threads.
>

I like it better in help->about together with info about the nn.

>  Yes, this is a rarely used function.
>
>  > Settings menu:
>  > * Why don't we replace this with a single menu entry (Options)
>  > and a complex dialog like in firefox "Tools/Options..." or in
>  > VLC "Settings/Preferences..." ? The dialog should have
>  > "OK", "Save" and "Cancel" buttons (should help underlining that
>  > once an option is changed you must save to have it next time you
>  > start gnubg).
>
>  The options do need a bit of a rethink, not sure it's worth the effort at 
> the moment.

For a start I would like to have only two menu points. One for the
appearance and one for a settings notebook containing all the rest.

>
>  > Go menu:
>  > * Horrible name. Maybe something like "Navigate" ... I would also put
>  > it in between the Game and Analyse menus, or evenunder the Game menu.
>  >

The Go menu is a standard name, but it could be cleaned up.

>  > Help menu:
>  > * Report bug: what is this supposed to do? On win it just opens an
>  > Explorer (not Internet Explorer, just the resource explorer).
>
>  This should open the browser at the bug entry page.

I haven't tried on windows lately, but it works on Linux.

>
>  > *Copying gnubg and gnubg warranty: are duplicated in "Help/About gnubg/
>  > Copying conditions" and "Help/About gnubg/warranty", we can just remove
>  > the menu entries and leave the buttons inthe About gnubg dialog.
>
>  Yes, no-one wants to read these anyway.
>

Having them in there is good practice for a GNU program, but besides
that nobody really cares.

>  > * Stop: the most dangerous button (and very rarely needed). Move all the
>  > way to the right, if really necessary to have it.
>

We could move the stop button down to progress bar and it could pop an
optional "are you sure" dialog.

>  > I would also like to have a context menu popping up when right-clicking
>  > in the play area (anywhere on the board, except chequers) with:
>  >
>
>  I'm not so sure about these, right-click should be context sensitive.  Most 
> of these actions are infreqent and easily available form the menu/toolbar.
>

I agree with Jon here.

All in all I think this change should wait till after the upcoming
release as I predict that this will influence a lot of things and thus
could take a lot of time before things settle down again.

Christian.




reply via email to

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