More Woopsi updates. Bad news first, the TextViewer is broken again. Actually, I think it was always broken, but it’s only now that I’ve extracted the text manipulation code from it and fixed the problems there that the problems with the TextViewer have come to light. Nothing major - it’s just one of those annoyingly tricky maths things that’s obvious once you can see where the problem is.
I thought I could avoid the whole issue by inheriting from the SuperBitmap instead and just use that as a pre-made canvas, but that will double the amount of memory being copied around so I threw that idea out.
Back to the good news. Radio buttons and radio button groups now work. It’s possible to set the state of an individual button (by using a pointer to that button), or to set the selected button within the entire group (by using a pointer to the group). Radio buttons support the tri-state concept, so they can be either “off”, “on” or “something else”. I’ve called the third state “mu” in honour of “Zen and the Art of Motorcycle Maintenance”. The third state can only be activated through the API, which makes the interface tidier.
I’ve created a glyph for the radio buttons that looks fairly similar to the original Amiga button. I can’t use the originals exactly because WinUAE is playing silly buggers and won’t give me a non-doubled resolution, so my screenshots are the wrong size. More aggravating, both Photoshop and Paintshop muck up the resizing. As radio buttons have circular borders in two colours, and as I haven’t got a two-colour circle routine, I’ve just used a glyph to represent the entire gadget. This means that the radio button image can’t be resized, but (because the DS’ touch screen isn’t known for its accuracy) the rest of the button can be resized. The clickable area of the button can be much larger than the glyph.
One neat thing that the button group does is resize itself automatically to contain radio buttons as they’re added. Developers don’t need to worry about making sure the group’s container is wide/tall enough for the buttons they’re adding (that’s important in order to detect clicks and redraws, etc). Writing that feature made me realise that all of the gadgets could resize automatically to accomodate their children (or text, in the case of buttons), which would give me a completely font size-independent interface. It’d have to be optional, natch, but it might be something for version 2.
When trying (and failing) to get a decent screenshot of the radio button glyph, I noticed that the glyph shown when a depth gadget was clicked is different to the standard glyph. Woopsi’s depth gadgets now have a “clicked” image as well as an “unclicked” image.
Checkboxes are also now available, and they too support the tri-state concept. Again, the third state can only be set via the API. At the moment, I’m not convinced that the glyph for the third state is particularly good (it’s just the tick in white instead of black), but that can be fixed later. The checkbox border uses the standard Woopsi border code since it’s rectangular, so the boxes can be resized.
I’ve fixed a few daft bugs in the Text class (the data manipulator) - I’d got columns and rows upside down and multiplied all wrong (must have been late when I did that), so the glyph populated/blank code wasn’t working. I’ve added a few other useful methods to it, too - calculating line lengths in pixels as well as characters, and calculating the same lengths but with any trailing spaces trimmed.
Trailing space removal was essential for the next addition - a multiline text box. Still got a few things to do to it (limiting the number of lines of text that it will buffer in memory, block scrolling), but it functions in more or less the same way as the standard textbox (text alignment, etc) but uses the Text class to handle text manipulation. It can be used all over the place - the debug console, the About requester, the Alert requester, etc.
I started modifying the original textbox to support all of this, then noticed that most of the other gadgets inherit from that and I was breaking everything. Ooops!
Short break to reboot Parallels for the third time in 20 minutes.
If Windows would stop crashing on me, I might be able to find out what else I’ve done… (Grumble grumble.)
Aha! Mainly just tidying up - fixing bugs, moving things out of the window and screen classes into the gadget class (child redraw code - took me a while to figure out why the radio buttons weren’t getting redrawn), etc. Most gadget action methods (click(), move()) now return bools to indicate whether or not they succeeded or failed. An action can return false if it doesn’t complete - for example, calling “moveTo()” with the gadget’s current co-ordinates results in no movement, which the “moveTo()” function detects and rejects. Finally, I’ve added “enabled” and “disabled” events. I’m thinking of adding a “drawn” event, too (or “painted”, in Windows speak).
One thing I need to note down. If I do implement a preferences system in Woopsi, I’ll need to have a version with prefs and a version without. I decided last night that this was another opportunity for a bad pun, so the sans-prefs version will be called “Little Woop”, and the full-fat version will be called “Big Woop”. I might need a new circus-ey, piratey logo for that one.
The SVN code is all up to date, and should you want a demo, the ROM images are in there, too. Oh! I need to put the docs in there. I’ll do that now.
In the meantime, here’s a screenshot (scrappy layout at the moment as I’m just testing things):
(Note to self, on looking at an Amiga screenshot - textboxes that can be altered have a double-thickness border. Bevel out, then bevel in. Should be easy enough to add.)