SpringGUI
introduction download reference examples
FAQ
- What user interface elements are currently part of SpringGUI?
Currently, SpringGUI provides the elements Button, TextField, TextArea, Choice (a selection box), List, Checkbox and RadioButton. For a screenshot of what different elements look like, check the reference. Future versions may also include FileDialogues, Menus and more.
- What systems has SpringGUI been tested with?
SpringGUI has preliminarily been tested on Windows XP and MacOS X, both with more than one Java Runtime. I'll post a list of tested systems with possible quirks as soon as I get around to do it a bit more systematically. So far, WindowsXP runs perfectly fine, while some Java versions on MacOS X have a few issues (see below). If you'll send me screenshots of possible bugs together with source code and your OS and Java Runtime version info, I'll be one happy panda.
- What are some bugs and known issues with SpringGUI?
- The user interface elements have an opaque background.
This is not a bug in SpringGUI but a general problem with java's heavyweight awt components for which I don't believe a workaround exists. The problem appears for example with OSX' rounded buttons which have a visible background and are not transparently laid over the processing canvas. The workaround for this is to position your GUI elements prudently and over a region of a common single color background, then to set the elements' background colors to this color.
MacOS generally does not seem to be quite consistent about the way it handles GUI elements. Buttons are an example for things that look different in different JRE versions, and occasionally, elements quickly flash a bright border, when they receive events. If you're working on a Windows system and want to design your Processing applications to be as cross-platform/cross-JRE as possible, make them a little larger than seems necessary and leave a bit of extra space around them. Backgrounds of Buttons behave funnily in that some versions of the JRE draw them in grey no matter what color you specify. Still, you can and should use background colors to match elements that you'd normally expect to be transparent, to a single color background.
I expect to be able to work these things out when I get some more time to tinker with MacOS X, probably until the end of the month.
- Pressing Buttons with the keyboard instead of clicking them with the mouse won't fire an event.
It's high up on the to-do list and will be fixed soon.
- There is no way of controlling the order in which the elements receive focus when the user tabs through them using the keyboard.
- On MacOS with Safari, I sometimes encountered the Applet initialising with a messed up interface. When I hit reload, everything works nicely.
I'll put some research into that as soon as I get another opportunity of working on a Mac.
- Will SpringGUI work in an applet? How about OpenGL?
To my best knowledge, SpringGUI will work fine in both the standard Processing environment (including P3D and/or present mode) and web browsers. Processing's OpenGL mode however is another issue, and the short answer is that it will in all probability not work.
The technical reason for this is that SpringGUI simply adds awt Components to the Processing applet's Panel Container - and when Processing utilizes the jogl OpenGL bindings, it adds a GLCanvas Component to the applet's Panel and performs all its drawing on this Component instead of the Panel. Since additional Components can't be placed on top of the jogl Component, GUI elements placed in Processing applets using OpenGL won't be displayed.
- What does my Processing program need to receive events from the GUI elements?
Your program must create an instance of SpringGUI and pass it a reference to the Processing application in the constructor (by calling "new SpringGUI(this); ").
Additionally, your program must implement either handleEvent(String[] parameters) for beginner mode or handleEvent(Object[] parameters) for advanced mode (if both are implemented, only the latter is used). If you do not implement either of these methods, SpringGUI will fail when the user does anything to the GUI.
- Help! I'm new to programming and arrays confuse me...
If you're just starting out with programming and feel uncomfortable working with arrays, there are a few methods SpringGUI provides that you can use from inside your handleEvent(String[] parameters) method: SpringGUI.getElementType(parameters) will give you a single String representing the type of GUI element the event was fired on (such as "Button"); SpringGUI.getElementName(parameters) will give you the element's name; and SpringGUI.getEventType(parameters) will return the type of event that happened (such as "mousePressed").
Note that you still have to compare these Strings by using the String1.equals(String2) method instead of saying String1 == String2 .
On another note, I'd like to give you my personal opinion that you should learn to get comfortable with Arrays as soon as you can, as they are an extremely useful concept.
- Do you take requests for additional GUI elements?
If they're reasonable (please refer to the next two questions) and enough people ask me about them, I might incorporate your requests into future versions of SpringGUI, so do feel invited to write in if there is something that you feel must be done for SpringGUI more than anything else.
Please be kind enough to note that I'm doing this in my spare time, and I really can't guarantee any progress at all. Also, I tend to be lazy about this written communication thing. Don't take it personal. If you're an accomplished T-Shirt designer and have a box of T-Shirts lying around, I will happily wear any T-Shirts you send me, but I still won't make any promises.
You can contact me at philipp@repeatwhiletrue.com.
- Could you make me a threedimensional analog dial GUI element that reacts to five different mouse buttons? Please?
SpringGUI uses the elements provided by Java's awt, which is now about a decade old. They're tried and true user interface components and appear in a platform dependent manner, but they're not exactly targeted towards people who'd like a standardized way of simulating a theremin with the mouse cursor.
The advantage of restricting SpringGUI to these standard user interface elements is that their handling is done by the operating system and therefore very efficient. If I started adding all kinds of non-standard elements, I'd have to write my own listeners which would in turn add a lot of overhead to your programs.
- How about giving me access to the existing TextField element's current text selection information?
Yeah. There's a bunch of interesting behaviour and info that the existing GUI elements expose and that could be incorporated into SpringGUI's event "portfolio". Some of that will probably make its way into SpringGUI in future versions, however there will be only so many people that want to write word processors in Processing, so priorities may vary.
If you can't wait, you might look into the Java documentation for the respective awt Components. SpringGUI is intentionally designed in a manner that will let advanced users access awt classes directly, which will enable you to do all those funky TextField operations I'm too lazy to adapt.
If you do work on the SpringGUI source directly, the LGPL license obligates you to release your modified source under LGPL terms... If you decide to do that and come up with something interesting, let me know and it might find its way into the next version of SpringGUI.
- I know a bit of Java. Can you give some technical background info on SpringGUI?
As mentioned in the previous answer, SpringGUI simply adds awt Components to the applet's Panel (the canvas on which all drawing is done); it then adds event listeners to the Components and makes them route and translate all important events to your Processing applications' handleEvent method, where you should handle them as desired.
In order to be able to position elements by pixel coordinates, SpringGUI sets the LayoutManager of the Processing Panel to null. Currently, Processing makes no use of LayoutManagers that I know of - as long as future versions of Processing stay that way, SpringGUI should work fine.
Since SpringGUI uses awt Components, the GUI should adopt the look and feel native to your operating system. This means that if different operating systems handle GUI widgets differently (font sizes on buttons, for example), you might need to take some safety margins into account when you design your interface (which is normally the job of the various - usually tedious and clumsy - LayoutManagers of the awt).
- So why do you use awt Components instead of Swing?
Well, first of all there is the compatibility issue as Swing was not part of all Java 1.1 releases.
The main reason however is that it's technically not possible to combine Swing components (which are leightweight) and awt components such as the Processing applet's Panel (which are heavyweight), so if Swing components were placed on the canvas, the applet's Panel (containing your fancy generative imagery) would be drawn on top of them (tried it - at best, it flickers heavily).
A solution would have been to design SpringGUI in a manner so that it would always dedicate an entire rectangular area of the applet's screen estate to nothing but the GUI (incidentally this would also be a hypothetical solution to the OpenGL problems), but I believe that this would have been an inacceptable trade-off.
- What's the license for SpringGUI? Can you explain it in plain text?
SpringGUI is released under the GNU LGPL. In practise, this means you can use SpringGUI for both open and close sourced projects, both commercial and non-commercial. However, if you change the source code of SpringGUI, you must make the changed source available under the same license and make clear where you made changes.
If that still confuses you, put even more shortly, you can use SpringGUI freely, as long as you're not hacking around with its source code (which you probably won't be doing if the above confuses you).
- So what you're saying is I can't add more functionality without giving my work away to others?
If you don't want to share, SpringGUI still enables you to get access to the awt classes it uses, so you can use them from within your Processing programs, circumventing the limitations of the LGPL. Additionally, you could adopt the principles by which SpringGUI handles the awt classes and replicate them from within Processing to add additional interface elements. These alternatives are somewhat less convenient, but then so is life.
back to the top of the page
|