RE: UI proposal

RE: UI proposal

[Elijah Meeks]

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.

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

RE: UI proposal

[Hans Ronne]

>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.

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.

Hans

RE: UI proposal

[Lincoln Peters]

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.

RE: UI proposal (more screenshots)

[Lincoln Peters]

On Wed, 2003-11-19 at 11:06, Lincoln Peters wrote:
> 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.

You can now find a screenshot that illustrates GTK+ floating panels at:

http://homepage.mac.com/lmpeters/gtk-xconq-floating.png

As before, it should be possible to turn these panels invisible
automatically or on demand.
Although I think that it looked better when they were docked to the
edges of the window; that may just depend on who you ask.  At least it
should be possible to allow the user to set it up his or her preferred
way (just click the handlebar and drag).


Additionally, to demonstrate panel-hiding, I created another screenshot
in which panels that would not appear in the standard game are hidden
(actually, I just made the "hidden" panels into floating panels and
moved them to the side, but the screenshot still makes the point):

http://homepage.mac.com/lmpeters/gtk-xconq-standard.png

In the standard game, the "Advances", "Technology", and "Tooling" panels
would be removed, since advances and tooling and not used in the game
and technology only applies to one unit (the nuclear bomb) that can only
be developed by one other unit (the city).  Perhaps in the case of the
"Technology" panel, it would appear when a city is selected and nuclear
bombs have not yet been developed, and it would disappear when a
different unit is selected.

RE: UI proposal

[Eric McDonald]

On Wed, 19 Nov 2003, Lincoln Peters wrote:

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

I am still have much to learn about both GTK and SDL, but I am not 
sure that these two things are diametrically opposed. I 
can see using SDL to do cross-platform graphics/video work, while 
using GTK to do cross-platform UI work (similar to my suggestion 
about wxWindows). The downside is that this makes Xconq have two 
external software dependencies instead of one.... Also, I could be 
way off base here. Like I said, I will research it more this 
weekend.

> 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?

One thing that any solution should address is whether layout 
managers are available. Being able to plop down a window or any 
other component and have the other components be rearranged in an 
aesthetically pleasing manner with minimal functional impedance to 
the user and with minimal guidance from the programmer is a 
desirable trait.

Eric

RE: UI proposal

[Elijah Meeks]

> 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.
> 
> 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.

I still haven't managed to play a game successfully on
the Mac, but from how it looks and what you're
describing, it sounds perfect.  Lincoln's proposed UI,
though, would be an improvement over the current PC
interface, and if all the information windows are made
on-demand (Or most of them, at least) then the screen
is only ever as cluttered as a player wants.  It'd
look better if the information boxes could be truly
floating (And only docked if the player wants) so that
when you're right-clicking for info or a build, the
box has the appearance of a dialog box common to many
strategy games.




__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

Re: UI proposal

[Andreas Bringedal]

> 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.

Sounds like this is a Mac game first and foremost and only a windows game
last after the other platforms...Can the Mac Xconq game be run on windows by
some sort of win-mac imitate program?

Andreas