public inbox for xconq7@sourceware.org
 help / color / mirror / Atom feed
* SDL interface thoughts
@ 2004-11-22  4:10 mskala
  2004-11-22  5:53 ` Eric McDonald
  0 siblings, 1 reply; 7+ messages in thread
From: mskala @ 2004-11-22  4:10 UTC (permalink / raw)
  To: xconq7

So, tonight I had a bit of time for XConq hacking, and I grabbed a fresh
snapshot out of the Sourceforge CVS.  Compiling that took longer than I
expected because I had to install ParaGUI, and ParaGUI required something
called "sigc++", and a new version of SDL, both of which had to be
downloaded and installed, but after I got it up and running I gave the
current SDL interface a try.

I have one thing that may be a bug:  After playing for a while in the
standard game, the interface seemed to get into a state where I couldn't
proceed.  I could switch between move and select modes and click on units,
but all the units I selected seemed to already have orders and be out of
movement points. I couldn't seem to wake them, or override or change their
current orders. I wondered if maybe I'd run out of movement points. I
figured out by trial and error that I could press "enter" to end the turn,
but that didn't help; it let the computer units move but it didn't seem to
let me give commands to my own units.  I also couldn't tell what turn I
was on, or whether the turn actually had ended - "end turn" is my best
guess of what "enter" was doing because it seemed to cause the enemy units
to move.  It's just as well there were enemy units visible on my screen at
that point (it took me a while to find them) because otherwise
"enter" would have had no visible effect at all.

I typed and deleted a rant about the hidden input states and lack of any
kind of menu in the SDL interface, so that it's impossible to use
comfortably, because I imagine that those things are already in the
process of being corrected.  The bug, though, might actually be a bug.
-- 
Matthew Skala
mskala@ansuz.sooke.bc.ca                    Embrace and defend.
http://ansuz.sooke.bc.ca/

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: SDL interface thoughts
  2004-11-22  4:10 SDL interface thoughts mskala
@ 2004-11-22  5:53 ` Eric McDonald
  2004-11-22  7:23   ` mskala
  0 siblings, 1 reply; 7+ messages in thread
From: Eric McDonald @ 2004-11-22  5:53 UTC (permalink / raw)
  To: mskala; +Cc: xconq7

mskala@ansuz.sooke.bc.ca wrote:
> Compiling that took longer than I
> expected because I had to install ParaGUI, 

Hopefully the provided RPM packages or Windows installer were of some use.

>and ParaGUI required something
> called "sigc++",

Yes and no. The 1.0.x stable versions of ParaGUI do not require 
libsigc++. The >=1.1.5 devel versions of ParaGUI do require it, IIRC. 
However, I am developing against 1.0.4, so this should not be necessary. 
One of the reasons that I went with 1.0.4 over 1.1.8 is that, not only 
is 1.0.4 stable, but it was one fewer dependency to foist upon other 
developers.

> and a new version of SDL,

Which version did you previously have? It may have worked with ParaGUI, 
and maybe I just need to make the configure script version-checking less 
aggressive.

> I have one thing that may be a bug:  After playing for a while in the
> standard game, the interface seemed to get into a state where I couldn't
> proceed.  I could switch between move and select modes and click on units,
> but all the units I selected seemed to already have orders and be out of
> movement points. I couldn't seem to wake them, or override or change their
> current orders. 

I can't tell exactly from your description, but this sounds like the bug 
I squashed this afternoon. Perhaps my commit had not yet reached the 
outward-facing CVS pserver when you did your checkout. Were you using 
the delay ('d') command at all during the game?

>I wondered if maybe I'd run out of movement points. I
> figured out by trial and error that I could press "enter" to end the turn,
> but that didn't help; it let the computer units move but it didn't seem to
> let me give commands to my own units.  

This sounds weird, and it does not sounds like the delay bug. It does 
sounds like a bug with 'autonext_unit' and friends and/or the Xconq 
kernel scheduler.

I wish I had hooked in the save game code to the SDL interface, because 
then I could ask you to see if it was reproducible.

>I also couldn't tell what turn I
> was on, 

Were you in full screen mode? If not, then you should have seen the turn 
number on the titlebar. (No, that's not the best place to put it, but 
until I get some more display space inside the window, that's where it 
is going to have to be.)

> I typed and deleted a rant about the hidden input states and lack of any
> kind of menu in the SDL interface, so that it's impossible to use
> comfortably, because I imagine that those things are already in the
> process of being corrected.  The bug, though, might actually be a bug.

It might. Hopefully we can get some more information on what was 
happening. Feel free to use the bug submission form on the Sourceforge 
site, if you get more information.

As far as hidden input states go, the cursor usually gives some 
indication of what is expected [1]. Also, the "mouseover" panel becomes 
"locked" with a prompt when the interface is in a modal state.

As far as menus go, __it depends on what you mean by menu. Two of the 
ideas that has been circulating around the list on and off for the past 
year is the idea of the "clean rectangle" and the "enchanting 
interface". These seem to speak against the traditional menu bar. I am 
sure that you must have noticed the unit action buttons along the bottom 
of the screen, though; these are a menu. There will be more such 
buttons, not just for unit actions and side research, but also for other 
side- and game-related functions....

Eric

[1] There is a bug, where, if the interface is in survey mode, you 
select an enemy unit, and hover the cursor over one of your own units, 
then the cursor will change to the battle cursor. This should be quite 
simple to fix, but I haven't gotten around to it yet.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: SDL interface thoughts
  2004-11-22  5:53 ` Eric McDonald
@ 2004-11-22  7:23   ` mskala
  2004-11-22 19:02     ` Eric McDonald
  0 siblings, 1 reply; 7+ messages in thread
From: mskala @ 2004-11-22  7:23 UTC (permalink / raw)
  To: Eric McDonald; +Cc: xconq7

On Sun, 21 Nov 2004, Eric McDonald wrote:
> Hopefully the provided RPM packages or Windows installer were of some use.

Not really, because I'm running Slackware - my general approach was to
find out the name of each thing I needed, and then install the latest
version of that item, recursively getting and installing each prerequisite
as they showed up.

> is 1.0.4 stable, but it was one fewer dependency to foist upon other 
> developers.

Okay... I didn't really pay attention to the version number required, just
saw "Oh, it wants ParaGUI" and so grabbed the latest version.

> > and a new version of SDL,
> 
> Which version did you previously have? It may have worked with ParaGUI, 
> and maybe I just need to make the configure script version-checking less 
> aggressive.

I had 1.2.4, it wanted 1.2.6, and I installed 1.2.7.  It was ParaGUI that
complained about it, not XConq, but it was ParaGUI 1.1.8 that complained,
so the version you're using might have been fine with 1.2.4.

> I squashed this afternoon. Perhaps my commit had not yet reached the 
> outward-facing CVS pserver when you did your checkout. Were you using 
> the delay ('d') command at all during the game?

I was, and I think that was probably the bug that bit me because it seemed
to get stuck right after the first time I used "delay".

> Were you in full screen mode? If not, then you should have seen the turn 
> number on the titlebar. (No, that's not the best place to put it, but 
> until I get some more display space inside the window, that's where it 
> is going to have to be.)

Okay - I only looked at the titlebar when I attempted to click the "close"
button (with no effect).  I didn't know there was a full-screen mode,
which brings up my next point:

> As far as menus go, __it depends on what you mean by menu. Two of the 

I meant "menu" in a very general sense.  The principle is that I want to
be able to *see* every command that I can use.  Even if I may eventually
want to make that display go away for more screen real estate once I
memorize the command, it should always be easy to bring back the
information of "what are all the commands I can use?" when I want to be
reminded.  Whether it's an item on a list that drops down (as in the TCL
interface), or a button on a panel, or whatever, doesn't matter; it's just
that as far as I'm concerned as a user, a command doesn't exist if the
interface doesn't tell me about it.

Oh - and on hiding the menu information for expert users, don't do what
the Konqueror Web browser does.  By default it starts up with an "info"
page.  That info page explains that if you want the browser to start up
faster, you can disable the info page by going to such-and-such obscure
menu and unchecking a check box.  So I did that.  It turns out that
turning off the info page does not actually make the browser start any
faster, but DOES have the side effect of making it start up with a very
small window by default, which is really annoying.  So I figured I'd turn
the info page back on... but the menu on which that has to be done is
several levels deep, only documented on the info page which I could no
longer see because I'd turned it off, and took a lot of searching to
find.  Moral:  let the user turn off informational displays if you think
they'll want to, but also make it easy to turn the displays back
on.  Other moral:  configuration settings should not have weird unexpected
side effects.

> sure that you must have noticed the unit action buttons along the bottom 
> of the screen, though; these are a menu. There will be more such 

Yes; things like that would be fine.
-- 
Matthew Skala
mskala@ansuz.sooke.bc.ca                    Embrace and defend.
http://ansuz.sooke.bc.ca/

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: SDL interface thoughts
  2004-11-22  7:23   ` mskala
@ 2004-11-22 19:02     ` Eric McDonald
  2004-12-17 19:17       ` Mark A. Flacy
  0 siblings, 1 reply; 7+ messages in thread
From: Eric McDonald @ 2004-11-22 19:02 UTC (permalink / raw)
  To: mskala; +Cc: xconq7

mskala@ansuz.sooke.bc.ca wrote:

> Not really, because I'm running Slackware - my general approach was to

Ah yes, Slackware, venerable old Slackware. Almost forgot that it 
existed.... (No offense.)

> I had 1.2.4, it wanted 1.2.6, and I installed 1.2.7.  It was ParaGUI that
> complained about it, not XConq, but it was ParaGUI 1.1.8 that complained,

I see.

> so the version you're using might have been fine with 1.2.4.

Yes, it should be, considering that I built ParaGUI 1.0.4 against a SDL 
lib that was earlier than 1.2.6 on my Linux system.

> I was, and I think that was probably the bug that bit me because it seemed
> to get stuck right after the first time I used "delay".

Well, with this bug, you wouldn't get stuck until all of the units had 
the chance to act. Then, when it came time to give the delayed units 
another chance is where it would get stuck. But, like I said, that 
should be fixed in the latest CVS.

> Okay - I only looked at the titlebar when I attempted to click the "close"
> button (with no effect).  

I added code to intercept the quit event (which is triggered by clicking 
close) over a month ago. You should have seen a prompt in the mouseover 
panel asking you whether you wanted to save the game. (Such prompts will 
be replaced with modal dialog windows as ParaGUI becomes more fully 
integrated into the SDL interface.)

>I didn't know there was a full-screen mode,

There is, but it is not something that one can switch to, at present. 
Depending on the results of Xconq's interrogation of your display 
configuration, the interface decides whether you get it or not. Or, at 
least, that is what I remember seeing when I looked at the relevant 
piece of code early on when I was getting acquainted with the interface 
code. Of course, I think that on systems where the full screen mode is 
supported, the user should have the option to switch back and forth. 
But, __haven't got that far yet....

> I meant "menu" in a very general sense.  The principle is that I want to
> be able to *see* every command that I can use.  

Sure. I agree 100%. Matter of fact that is what I was working on before 
I got distracted by Sourceforge, ParaGUI, etc.... If you don't mind 
briefly coming into contact with a forum, you can see what I have in mind:
   http://www.xconq.org/modules.php?name=Forums&file=viewtopic&t=9
It's the fourth post on that topic. There is a list of command buttons 
that should appear, if the current unit/selected units support them in 
the current context.
And, I think I made an even more detailed listing in the sources, either 
in the 'update_unit_info' function or a function that it calls, IIRC.

>Even if I may eventually
> want to make that display go away for more screen real estate once I
> memorize the command, 

Sure. The "Hide" button is available to make the whole commands panel go 
away. It is more proof of concept than anything right now; it was a test 
to make sure that events handling would be okay in the absence of the 
panel. The unit action panel comes back when another unit is 
[auto]selected; that behavior will change once my attention returns the 
unit action buttons.

The other thing I plan on doing is displaying in the mouseover panel the 
"shortcut"/keyboard command needed to do the equivalent of clicking the 
button. I am thinking about setting it up so that the button is no 
longer displayed if the player uses the keyboard equivalent instead. 
This is useful for brushing aside buttons like "Delay" and "Skip" in 
favor of the construction buttons, etc....

As far as bringing the unit action panel or individual buttons back into 
view once they have been hidden, __a preferences screen or three are 
needed in the long run. That was one of my motivations for taking the 
"time out" to pursue ParaGUI integration.

> find.  Moral:  let the user turn off informational displays if you think
> they'll want to, but also make it easy to turn the displays back
> on.  

Quite reasonable. In terms of our discussion, I think that will simply 
imply making the preferences screens easily accessible (and with some 
indication that the user can achieve the desired goal of showing hidden 
UI elements again).

Eric

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: SDL interface thoughts
  2004-11-22 19:02     ` Eric McDonald
@ 2004-12-17 19:17       ` Mark A. Flacy
  2004-12-18  3:11         ` Eric McDonald
  2004-12-19  3:31         ` Eric McDonald
  0 siblings, 2 replies; 7+ messages in thread
From: Mark A. Flacy @ 2004-12-17 19:17 UTC (permalink / raw)
  To: xconq7

>>>>> "Eric" == Eric McDonald <mcdonald@phy.cmich.edu> writes:
Eric> 
Eric> Ah yes, Slackware, venerable old Slackware. Almost forgot that it
Eric> existed.... (No offense.)

Yeah, last release June 2004.  Old indeed.

I'm sure that RPMs go over real well with the Debian crowd too.


As a Slackware user myself, I don't expect you to provide Slackware
packages.  I would expect the source tar balls to be fairly straightforward
to build, with perhaps some dependency information in the README or in the
autoconf messages.

You may wish to look at http://asic-linux.com.mx/~izto/checkinstall/ if you
ever were to start creating other distribution's packages for XConq.  It
can make RPMs too, for that matter.

-- 
 Mark A. Flacy
 Any opinions expressed above are my own.  Any facts expressed above
 would imply that I know what I'm writing about.  Sometimes, I do!

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: SDL interface thoughts
  2004-12-17 19:17       ` Mark A. Flacy
@ 2004-12-18  3:11         ` Eric McDonald
  2004-12-19  3:31         ` Eric McDonald
  1 sibling, 0 replies; 7+ messages in thread
From: Eric McDonald @ 2004-12-18  3:11 UTC (permalink / raw)
  To: Mark A. Flacy; +Cc: xconq7

Hi Mark,

On 17 Dec 2004, Mark A. Flacy wrote:

> Yeah, last release June 2004.  Old indeed.

I was referring to how long Slackware has been around, and not 
when the last release was. To be honest, I was pleasantly 
surprised to discover that at least 1 person was still using it. 
In my perception, the distro faded alot after the Slackware vs. 
Redhat debate of the mid-90's. Other distros such as Suse, 
Mandrake, and Debian seemed to displace it in the competition with 
Redhat.

> I'm sure that RPMs go over real well with the Debian crowd too.

Well, if there is some implication that I am RPM-centric, the 
truth is that I'm not. If you look through the list archives, you 
can find several places where I expressed a desire to find 
packagers for not only other Linux distros, but the BSD's and 
other Unixes as well. I also said that I would look into making 
debs myself, if someone could not be found to do it. As it turns 
out, the present maintainer of the Xconq 7.4.1 packages for Debian 
has volunteered to make packages for 7.5.0, once it is released. 
There was also some talk about making Gentoo ebuilds of the CVS 
snapshots that I occasionally release on Sourceforge.

The reason why Xconq has RPM packages of its prereleases is quite 
simple:
(1) I develop on a Fedora Core system; I used to develop on a 
Mandrake 8/9 system. Both distros use the Redhat package manager. 
It is a matter of convenience to release RPM packages.
(2) I have not yet had time to develop the necessary packager 
files for things such as Debian or Gentoo (or Slackware). It is on 
my list of things to do.

> As a Slackware user myself, I don't expect you to provide Slackware
> packages.  I would expect the source tar balls to be fairly straightforward
> to build, with perhaps some dependency information in the README or in the
> autoconf messages.

If "./configure --help" is a bit too concise, please let me know 
what sort of additional documentation would be nice. I think that 
'doc/INSTALL' also talks about the config options, but it hasn't 
been updated in a while.

> You may wish to look at http://asic-linux.com.mx/~izto/checkinstall/ if you
> ever were to start creating other distribution's packages for XConq.  It
> can make RPMs too, for that matter.

Thanks for the URL. I will look at it tonight.
I would still be concerned about testing the packages on the 
other distros though.

Eric

P.S. I haven't forgotten the Forth implementation that you (IIRC)  
suggested for a Xconq interpreter last year. Seeing as Xconq 
doesn't have as many developers as it could have, I've been far 
too busy with other things to give it any more consideration.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: SDL interface thoughts
  2004-12-17 19:17       ` Mark A. Flacy
  2004-12-18  3:11         ` Eric McDonald
@ 2004-12-19  3:31         ` Eric McDonald
  1 sibling, 0 replies; 7+ messages in thread
From: Eric McDonald @ 2004-12-19  3:31 UTC (permalink / raw)
  To: Mark A. Flacy; +Cc: xconq7

Mark A. Flacy wrote:

> You may wish to look at http://asic-linux.com.mx/~izto/checkinstall/ if you
> ever were to start creating other distribution's packages for XConq.  It
> can make RPMs too, for that matter.

Looks interesting.

I think the way that might prove best for the Xconq project to use it 
would be:
   checkinstall rpm -i xconq-common-7.5.0-0pre.0.somedate
etc..., to track the installation of RPM packages and generate Slackware 
and Debian packages from that. Of course, 'alien' can do this in a more 
direct manner, but I think it requires certain tools, such as 'dpkg' to 
already be installed.

One must be careful to get the right directory structure for each 
distribution though, and I don't think CheckInstall solves that problem. 
And it always better to be able to actually test the packages on a 
native system.

Eric

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2004-12-18  3:11 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-11-22  4:10 SDL interface thoughts mskala
2004-11-22  5:53 ` Eric McDonald
2004-11-22  7:23   ` mskala
2004-11-22 19:02     ` Eric McDonald
2004-12-17 19:17       ` Mark A. Flacy
2004-12-18  3:11         ` Eric McDonald
2004-12-19  3:31         ` Eric McDonald

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).