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