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

RE: UI proposal

[Brandon J. Van Every]

Bruno Boettcher wrote:
>
> but i thought that adding other interfaces was hard due to the deep
> interwindling of xconq game machine and UI, the stuff that prevented a
> clean client server design IIRC?

That is certainly my assessment.  Xconq does not have usable / doable
code for writing new UIs.  I am going to look around to see if anyone on
the net has already written a generic hex-based game UI.  (Civil?)  If
not, I'll probably write one.  Then people who know the Xconq codebase
can worry about plugging the Xconq code into it, if they want to.  I'm
not going to bother, I don't need Xconq to write a 4X TBS UI.

I'm still willing to work on Python integration for AI and game design
purposes, language interop, and incremental OO-ification of the Xconq
codebase.  These are efforts that have to happen if the number of Xconq
developers is to grow significantly.  Otherwise, newcomers are going to
take one look at all the hundreds of C functions and conclude pretty
much what I've concluded.

Now, one major problem with that agenda is you guys are currently in
stable feature freeze / bugfix mode.  So, when do you plan to kick 7.5
out the door?


Cheers,                     www.indiegamedesign.com
Brandon Van Every           Seattle, WA

Taking risk where others will not.

Re: UI proposal

[Lincoln Peters]

On Wed, 2003-11-19 at 08:54, Eric McDonald wrote:
> Yes. I have built a number of GTK apps, but never actually looked 
> into it much. I will do so this weekend. We should, however, keep 
> in mind that the Mac is one of Xconq's target platforms. Perhaps 
> GTK already comes with MacOS X (and could almost certianly be 
> built for it), but I haven't checked to see about the options for 
> the MacOS 8 and MacOS 9 families. Of course, if Hans and Stan were 
> content to just maintain a seperate MacOS GUI, then this is moot.

This might not be exactly what you had in mind, but MacOS X 10.3 now
ships with X11.  Therefore, as long as everything (Xconq, GTK+, et al.)
compiles on MacOS X (which, in my experience, is not always certain), it
can be used on MacOS X.  And I know that GTK+ is available for MacOS X
via the Fink project (although it's an older version of GTK+).

Of course, the same is not true for "classic" MacOS (before X).

RE: UI proposal

[Lincoln Peters]

On Wed, 2003-11-19 at 00:33, Brandon J. Van Every wrote:
> Lincoln Peters wrote:
> >
> > http://homepage.mac.com/lmpeters/gtk-xconq.png
> >
> > DON'T PANIC!  This screenshot does NOT, on its own, illustrate what I
> > was thinking about!
> 
> Glad to hear that.  It's definitely too cluttered.  But if you were able
> to bang it out quickly, that's of interest.  My biggest question: can
> GDK+ do right-click popup menus with icons in them?

Yes.  I've seen them implemented in countless programs, including the
one I'm using for e-mail.  I think that Freeciv also uses GTK+, and it
uses pop-up menus extensively.

> 
> Second big question is: do you know if SDL GUI builder tools exist, or
> are you speculating?  It is not clear from your comments that Glade has
> anything to do with SDL.  If SDL requires manual labor to get results,
> that's a loss.

I used Glade simply because it was easy to bang something out.  As far
as I know, there is no similar tool for SDL.  However, I don't know
anything about SDL programming.

Re: UI proposal

[Eric McDonald]

Hi Bruno,

On Wed, 19 Nov 2003, Bruno Boettcher wrote:

> but i thought that adding other interfaces was hard due to the deep
> interwindling of xconq game machine and UI, the stuff that prevented a
> clean client server design IIRC?

I am no authority on adding interfaces to Xconq as I haven't spent 
much time with the UI code, but the kernel is essentially 
abstracted from the interfaces. I also believe that Stan(?) 
pointed this out recently, and he said that the ability to add 
new interfaces was the primary motivator for this. From a kernel 
hacker's perspective, I can tell you that I don't see alot of 
evidence of deep intertwining.

However, I will agree that a client-server model would be nice. I 
currently don't feel ambitious enough to attempt the separation, 
and dropping in the clisrv communication layer in between. I don't 
plan on doing this in the 7.6 release cycle either. But perhaps 
others are more ambitious....

The reason I have thought about a clisrv architecture in the past 
was not for the GUI's, but for the AI's.

  Regards,
   Eric

Re: UI proposal

[Eric McDonald]

Hi Lincoln, others,

On Thu, 20 Nov 2003, Peter Garrone wrote:

> On Tue, Nov 18, 2003 at 11:11:13PM -0800, Lincoln Peters wrote:
> > I've been looking at the tcltk and SDL interfaces and thinking about
> > some of the suggestions for the Xconq UI.  Then I fired up Glade (the
> > GTK+ UI designer) and tried to figure out what the interface should look
> > like. 
> 
> Good idea. So long as it isnt interpreted. gtk is available for windows
> as well, though not for cygwin.
>  peter.

Yes. I have built a number of GTK apps, but never actually looked 
into it much. I will do so this weekend. We should, however, keep 
in mind that the Mac is one of Xconq's target platforms. Perhaps 
GTK already comes with MacOS X (and could almost certianly be 
built for it), but I haven't checked to see about the options for 
the MacOS 8 and MacOS 9 families. Of course, if Hans and Stan were 
content to just maintain a seperate MacOS GUI, then this is moot.

Eric

Re: UI proposal

[Bruno Boettcher]

On Wed, Nov 19, 2003 at 06:59:04AM -0800, Erik Jessen wrote:
> I've used Glade a little tiny bit - it's open-source, and has multiple
> interfaces.  What about asking the developers the questions you have -
> it may be already there, just not obvious.  Or, an easy improvement.
its possible with glade to have the GUI interpreted (functionality of
    libglade) or static... its a devel choice... you could easily have 2
interfaces with each paradigm using the same glade conf files...

but i thought that adding other interfaces was hard due to the deep
interwindling of xconq game machine and UI, the stuff that prevented a
clean client server design IIRC?


-- 
ciao bboett
==============================================================
bboett@adlp.org
http://inforezo.u-strasbg.fr/~bboett
===============================================================

Re: UI proposal

[Peter Garrone]

On Tue, Nov 18, 2003 at 11:11:13PM -0800, Lincoln Peters wrote:
> I've been looking at the tcltk and SDL interfaces and thinking about
> some of the suggestions for the Xconq UI.  Then I fired up Glade (the
> GTK+ UI designer) and tried to figure out what the interface should look
> like. 

Good idea. So long as it isnt interpreted. gtk is available for windows
as well, though not for cygwin.
 peter.

RE: UI proposal

[Erik Jessen]

I've used Glade a little tiny bit - it's open-source, and has multiple
interfaces.  What about asking the developers the questions you have -
it may be already there, just not obvious.  Or, an easy improvement.

Using a pre-existing, portable GUI builder sure sounds nice...

Erik

-----Original Message-----
From: xconq7-owner@sources.redhat.com
[mailto:xconq7-owner@sources.redhat.com] On Behalf Of Peter Garrone
Sent: Wednesday, November 19, 2003 6:26 AM
To: Lincoln Peters
Cc: xconq7@sources.redhat.com
Subject: Re: UI proposal

On Tue, Nov 18, 2003 at 11:11:13PM -0800, Lincoln Peters wrote:
> I've been looking at the tcltk and SDL interfaces and thinking about
> some of the suggestions for the Xconq UI.  Then I fired up Glade (the
> GTK+ UI designer) and tried to figure out what the interface should
look
> like. 

Good idea. So long as it isnt interpreted. gtk is available for windows
as well, though not for cygwin.
 peter.

RE: UI proposal

[Brandon J. Van Every]

Lincoln Peters wrote:
>
> http://homepage.mac.com/lmpeters/gtk-xconq.png
>
> DON'T PANIC!  This screenshot does NOT, on its own, illustrate what I
> was thinking about!

Glad to hear that.  It's definitely too cluttered.  But if you were able
to bang it out quickly, that's of interest.  My biggest question: can
GDK+ do right-click popup menus with icons in them?

Second big question is: do you know if SDL GUI builder tools exist, or
are you speculating?  It is not clear from your comments that Glade has
anything to do with SDL.  If SDL requires manual labor to get results,
that's a loss.


Cheers,                     www.indiegamedesign.com
Brandon Van Every           Seattle, WA

Taking risk where others will not.

UI proposal

[Lincoln Peters]

I've been looking at the tcltk and SDL interfaces and thinking about
some of the suggestions for the Xconq UI.  Then I fired up Glade (the
GTK+ UI designer) and tried to figure out what the interface should look
like.  I have a screenshot of the result at:

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

DON'T PANIC!  This screenshot does NOT, on its own, illustrate what I
was thinking about!  What it tries to illustrate is how the interface
could have several collapsible panels that may appear around the main
window.  The screenshot shows all of those panels at once, which I think
few people would actually want.

Using GTK+/GNOME, it is fairly easy to make menus, toolbars, etc.
detachable, so that something on the top of the screen could be moved to
the bottom of the screen or be made into its own window (I think tcltk
can do this with menus).  I assume that it would be possible to do this
with SDL (since nobody wants Xconq to look like an Office app).  I also
assume that, using SDL, these panels could be revealed and hidden with
little fuss.

The panels shown are listed, starting at the upper-left corner and
proceeding counter-clockwise:

* Messages:	This panel would serve the same purpose as the "Notices of
events and other info" panel in the tcltk interface, except that error
messages ("Can never do this!", "Out of ammo!", etc.) would appear in
the status bar on the bottom of the screen instead of here.

* Units:	This panel would list all units currently owned by the player. 
Optionally, it could be restricted to show only certain units, such as
those that have some ACP's left.

* Details:	This panel would show most of the same information as the
"Details about the current unit" panel in the tcltk interface.  However,
it does not show any of the information that might be unrelated to the
unit.
It is worth noting that, in this UI, the Units panel easily allows a
player to use semi-automatic AI control.  Simply give a unit a plan, a
goal, and/or a task, and the AI code would take it from there.  I would
imagine that, if the player selected a goal such as "Hold area" or "Move
to", additional fields would appear to store the relevant information. 
I don't know how that would be accomplished in SDL, but I know that
Ximian Evolution does it using GTK+ 2.

* Stats:	This panel would show any of the following numbers that could
apply to the unit: ACP, HP, Size, Morale, and CXP.  If any of these do
not apply to a unit (e.g. it does not act, it only has 1 HP, it's not
advanced, etc.), it would not show up.  If, for some crazy reason, the
selected unit does not have any of those properties, this panel would
not appear at all.

* Occupants:	This panel would show a list of the units that are
occupying the selected unit.  They would most likely show up as small
icons followed by the name or number of the unit.  If the selected unit
has no occupants but could, it would show up as an empty frame.  If the
selected unit has no occupants and cannot have any occupants, the panel
would not appear at all.

* Tooling:	This panel would show the icons for all units that the
selected unit could potentially build, followed by how many TP it has
towards that unit out of how many are needed to build it.  If it cannot
build any units that require tooling (usually either because it cannot
build anything or because tooling is not required for anything in the
game), the panel would not appear.

* Materials:	This panel would list all materials that the selected unit
can store, followed by how much it is storing out of how much it could
store.  If an icon is associated with the material, the icon appears
instead of the material's name (the player could hover over the icon to
get a tooltip that reveals the name of the material).  If the unit
cannot store any materials, the panel would not appear.

* Build:	This panel would list all types of units.  If the selected unit
can build other units, the option menu at the top could be used to
restrict the panel to only show the units that the selected unit can
build.  Other options on that same menu would allow the player to show
only those units that could be built without additional tooling, tech
development, and/or advances.

* Advances:	This panel would list all types of advances.  The option
menu at the top could be used to tell it either to show all advances, or
to only show advances that are available at the moment.  Perhaps it
could also restrict the listed advances to those that have (or have not)
yet been discovered, or those that have specific effects.

* Technology:	This panel would list all units that require tech points
to be build, and how many tech points the side has versus how many it
needs to build it.  Units that don't require tech points would not
appear here.  If no units require tech points, this panel would not
appear at all.


Obviously, there are a few things that Glade did that I didn't want
(although I assume that, if I really meant to code this thing, I could
have changed them).

First, I imagine that any of the icon lists would, rather than showing a
large icon and text underneath (a.k.a. "large icon" style), they would
show a small icon and text to the right (a.k.a. "small icon" style).

Second, there should actually be entries in all of the option menus (for
example, the option menu next to "Plan" would have options Passive,
Offensive, Defensive, Exploratory, Colonizing, Improving, and Random).

Third, there should be more appropriate icons throughout the UI.  The
icons I used here are all stock icons from Ximian Desktop 2 (the little
house icon appears wherever I couldn't find an icon that even remotely
resembled what I wanted), and are inappropriate for Xconq.

Finally, Glade does not provide any easy way to hide dock items (so that
I could illustrate what it would look like when only a few panels are
active).  As a result, this (in my opinion) elegant design ends up
looking like the interface from hell.

Any questions or comments?