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