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: UI proposal


The comments that follow in this message assume that (most of) the
developers still want to use SDL for a new Xconq interface.

On Wed, 2003-11-19 at 10:37, Hans Ronne wrote:
> >I think this is a great idea, specifically the
> >occupant and build windows and especially the option
> >to show only what can be built by the current unit.
> >This would clean up my games, for sure.
> 
> If you check out the Mac interface, you will find that several of the ideas
> discussed already are implemented there.
> 
> 1. A unit list can be brought up in a separate window, which contains much
> more information (plans, tasks, build status, materials etc) than the tcltk
> unit list.
> 
> 2. By right-clicking on any unit you bring up a small floating window with
> all the information you find in the unit info pane in the tcltk interface.
> Plus images of occs or transports. Clicking on these bring up new floating
> windows with information on those units. And so on. There is also direct
> access to the relevant help node through a help button in each floating
> window.
> 
> 3. When a unit needs a new build task a small floating window pops up with
> a menu that shows only what can be built by that unit. Picking an item
> closes the window and sets the build task.

Using dock items in GTK+/GNOME interfaces, it is possible not only to
move a dock item from one edge of the screen to another, but also to
turn a dock item into a floating window.  That would very closely mimic
the behavior of the Mac interface.  How difficult would it be do set
that up using SDL?

Perhaps I should try this in Glade and make some more screenshots.

> 
> The key thing here is that stuff like this pops up only when you need it
> (or ask for it). The Mac interface is similar to the SDL interface (and
> differs from the tcltk interface) in that emphasis is put on a whole-screen
> heads-up display. The map covers the entire screen. Lincoln's proposal
> included a lot of useful stuff, but there was not much space left for the
> map. And the map is the most important part of a game like this.

It should not be difficult to set up a GTK+ interface so that
unnecessary panels disappear (i.e. "turn invisible") when they are not
needed.  In the standard game, this would have two significant effects:

1. The "Tooling", "Technology", and "Advances" panels would be disabled
completely.  Furthermore, the "Stats" panel would not show any size,
morale, or CXP data; it would only ACP and HP (because of these, only
ACP and HP are used in the standard game).
2. If the "Build" panel is set to only display units that the selected
unit could build, it would only appear if the selected unit could build
something.  For example, if you had selected a town, the "Build" panel
would appear and list everything a town could build, but if you then
selected something incapable of building (e.g. a fighter), the panel
would automatically disappear.  The panel would automatically re-appear
if you selected the town again.

Again, I don't know how easy of difficult it would be to do such things
using SDL.


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