This is the mail archive of the xconq7@sources.redhat.com mailing list for the Xconq project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Help menu position


>> The technical question of how to get a menu to scroll is a valid one,
>> but my overall reaction to that question is that the menu shouldn't be
>> that long in the first place.  If we really want users to be scrolling
>> through a long list, better to have it part of the help dialog box,
>> rather than in a menu (which is harder to play with for an extended
>> period, because it tends to do things like disappear).
>>
>> I'd probably just say have Unit types, Materials, and Terrain do what
>> they do now (that is, open the help dialog), rather than try to do
>> sub-menus (which would have the same problem, if there were too many
>> items in the sub-menu).
>
>My idea was that, should one of those lists not fit on the screen
>without scrolling, it could be divided into lists, by alphabetical
>order.  It could be made to work much the same way as traditional
>printed encyclopedias (one menu for 'A-G', one for 'H-N', one for 'O-U',
>and one for 'V-Z').  It would take some extra coding (particularly to
>determine the optimal groupings), but it might make for an elegant
>solution.

I'll look into the submenu solution, though I'm not too enthusiastic about
it either. The nice thing about one menu is that you see everthing at one
glance without having to dig around in submenus. In most games one menu is
also adequate. It is only games with advances or many units (like Bellum)
that run into trouble.

Hans



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]