Subject: Reconfigurable panels From: Jay Gowdy Date: Fri, August 23, 2002 12:34 To: rhexphone@umich.edu Well, they seem to be at the beta release stage. I did have to tweak RHexLib/libutils a tiny bit, as well as flame, the frankenstein monster FLTK/Amulet merger I worked up, so to compile you should update RHexLib, cd RHexLib/libutils and do a make install, check-out flame, put it in the same level of hierarchy as RHexLib, update RHexOps, cd RHexOps/OCU/RHexGUI, make flame, cd RHexOps/OCU, make. You can run rhex_gui with no supervisor, and bring up the panel editor in the tools menu. This will bring up the list of templates, and you can double click on them to bring up editing windows (they have to be closed manually, sorry). If you want to play around with a "toy", then make paneltest, and run ./paneltest. Pop up all three templates and play around with changing things starting in BasePanel, and working down to BasePanel22, and see the inheritance propagation working. You can drag and resize widgets in this window, bring up a pop-up window with right mouse (which will tell you the keyboard shortcuts you need so you never have to pop up the window again). You can also double click on a widget to bring up the widget panel, which allows you to change a _huge_ number of things about the widget, including whether the widget will be taking joystick input or is purely a graphical interface. I have working a reconfigurable turbo mode, walk mode, and sit mode. My sit mode looks like Al's current sit mode with the four state button (1 bit for what you asked for, 1 bit for confirmation), but I do not have it hooked up to joystick buttons (easy to do, just didn't). Turbo mode looks nothing like the last turbo mode you may have seen. It has a 3x3 panel which works as you would expect, hooked to right stick. It has a cruise toggle button hooked to forward left. Putting the thing in cruise disables the middle row of buttons, latching the forward (or backward) motion, and allowing the diagonals to change the turning directions. Flip and jump are one-shot buttons which get reset when the mode starts. Walk mode is vaguely reminiscent of our existing walk mode. Fore/aft speed is controlled by forward/center/back buttons/right stick, modulated by the throttle. Turn speed is controlled by a horizontal slider (connected to the X axis of the right stick) with a 25% deadband in the middle. There is a big stop button which is depressed when the joystick is centered, but, more importantly, in non-joystick operation will zero both the fore-aft and turning speed. Bumping the left stick will increment the manual offset by 0.05, pulling down decrements by 0.05. There is also a check button there for inclination control not hooked up to the joystick. There is a surprising amount of chicanery and complexity going on to make these interfaces work. For example, I make large use of "invisible" buttons as helpers and containers of internal state. If you go into the panel editing area you will see these as grey'ed out widgets. Some uses are - Invisible widget which listens to the joystick and takes actions (used in incrementing and decrementing manual offset, for example, more subtly, there is a button listening for zeroing of right X axis in turbo mode which guarantees that when the stick is centered we are not goingn to be issuing a steering command) - You can configure a button to "trigger" another button, i.e., you can chain buttons together. I use this to set multiple database fields with a single button push (each of the 3x3 buttons in turbo mode sets foreaftSpeed to a particular value, and then chains to a invisible button whose action sets turningSpeed to a particular value). Buttons also can "master" other buttons, i.e., their state can determine if the other buttons are active or not, for example, the cruise button in turbo masters the three buttons in the middle row of the 3x3. There is also an internal name-space for storing floats which can be used as the source and destination of any of the widgets. Right now, the only thing using the internal name-space is the valuator widgets, which can be configured to output to the database the result of multiplying their internal value by an element of the name-space (that is how I build the walk mode speed control, for example). All widgets can be connected to buttons and axes on the joystick. The left, right, and pad axes are mapped into "virtual" buttons (this is how the 3x3 control panel in turbo mode works). The mapping seems fairly robust, and you can simultaneously use the joystick and the mouse without too much conflict. There are still large holes which I believe are acceptable for the near term. - Limited "choice" widgets (i.e., something that chooses from a list of alternatives) , and no ability to hook them up to the enumerations. Until a suite of these are in place, there would be no good way to implement calibrate, for example. For example, I use 6 individual button to choose between parameter sets in turbo mode. It would be better to have one widget with 6 choices to choose from, like a radio button panel, a pop-up menu, whatever. - A serious lack of editing tools. No cut. No paste. No align. No group. You can shift click on widgets and move them en masse, and you can pop up the widget editing window and use a lovely FLTK feature in their X,Y,Width,Height fields where if you drag through those fields you increment and decrement the values, and the widgets whiz around and and morph on the screen. Other than that it's just plain tedious. - It's quite bloated. There is a HUGE amount of stuff I didn't bother to cut out which is entirely unnecessary (unless someone really thinks we can use animation or gesture recognition, realistically). Just don't look at the size of the executables. Disk space is cheap. - Can't save/load parameter set files or suddenly decide when you are running that now you want to use JoelDebugginTurboMode rather than plain TurboMode as your interface to the mode. - Probably somewhat fragile when editing while running. Cosmetic things I trust to propagate, such as changing colors, positions. I'm not so sure about adding/removing widgets, etc. I just haven't played with it enough. For all I know it's perfect. "Doctor, Doctor, it hurts when I do this." "Well, don't do that" - As expected, the pad buttons are not mapped correctly on my laptop. No big deal, but we should figure out a consistent solution, as otherwise that's 8 buttons we can't use consistently. Anyway, while writing a new mode from scratch is daunting, this approach will definitely solve the "I want one more widget" problem. It will also solve the "But I want this on the left joystick" problem. Just subclass (or to be more precice create a new instance) from the prototype panel of your choice and proceed. I think I would like us all to consider what are some good basic types of control panels to use as prototype. My walkmode and turbomode panels are starting points for styles of control panel, but I would prefer if people thought about it a little more generally so that we have a prayer of a consistent look and feel. Jay