I’ve been thinking about the ways that Woopsi can be used when building applications. I’ve got some crazy ideas about task managers and base task classes, but I think that would have nasty flaws - it would add unnecessary complication and it would unavoidably prescribe the way applications were built. This is one of the major things that bugs me when I’m forced to use the latest .NET framework-of-the-week, designed by someone who thinks everything should still be done as it was in VB3. Smarter people than me may want to use it in smarter ways, and if I force them to use it in dumb ways because I couldn’t come up with anything better they just won’t use it. Woopsi would stop being a GUI toolkit and become an application framework.
I’ve got my own .NET framework-of-the-week to upload here at some point. Everyone - point and laugh at the hypocrite!
The approach I’ve come up with instead is just to suggest an application layout, but allow the developer to do whatever he wants with the GUI. If someone can come up with a better way to do things, or if a particular circumstance requires that Woopsi be used in an unusual way, the programmer can just ignore the guidelines. However, anyone who doesn’t really know where to start will undoubtedly be grateful for some guidance. I’ll flesh this out some more in the documentation once everything’s finished (and try to keep the language simple and less scatty than my blog posts, which are generally just thoughts splurged into a text editor as they arise), but here’s a few initial ideas.
Imagine you want to create a DSOrganiser-style application. Breaking this down into components gives us a single application (an organiser) that contains a multitude of smaller subtasks, such as a calendar and a text viewer. We need an “Organiser” class that controls the rest of the system, and a set of classes for each subtask.
The Organiser class needs to be able to create and delete instances of the sub-tasks as required. It’s probably easiest to think of it as a combined menu system and task manager. It would look something like this (near-pseudocode):
class Organiser : EventHandler Calendar* calendar TextEditor* editor WebBrowser* browser Woopsi* woopsi Screen* screen Window* window void createMenu() void closeTask(identifier) void handleClick(EventArgs event) end
The Organiser contains pointers to each of its subtasks. Its “createMenu” function creates a new screen and a window with a bank of buttons - each button represents one of the subtasks that the Organiser contains. When clicked, each button runs the “handleClick” function. This function works out which button was clicked, by checking the EventArgs struct, and creates an instance of that subtask.
When a subtask’s window closes, the subtask’s class calls the Organiser’s “closeTask” function. This can either do nothing (assuming we want the task to remain in memory) or add the task to a deletion queue (aha - this is where the idea for a task manager class/base task classes came from) to be deleted later. The task can’t delete itself, obviously, or the developer ends up with the same problem I had when gadgets were trying to delete themselves and were breaking the call stack.
Each subtask automatically creates its own window and handles its own initalisation; it also sets the window’s EventHandler to the subtask class, like this:
class SubTask : EventHandler SubTask() window = new Window() window->setEventHandler(this) end end
The main.cpp file would look something like this:
main() create woopsi create main screen create instance of Organiser class loop run woopsi end end
If I did go down the route of creating a task manager class, I could give Woopsi an instance of that class by default. The Organiser could be added to Woopsi’s task list and (this is the smart bit) closing that task would close all of the Organiser’s child tasks. Also (and this is another smart bit), since the Organiser creates its own screen and is essentially self-contained within a set of classes, it is a modular component. If someone wants to include your BSD-licenced (hint hint) organiser within their suite of simple window-based games, they just need to add your classes to their code and register the task with Woopsi’s task manager. They’ve instantly added a huge amount of new functionality to their own ROM.
Of course, this falls apart if the ROM exceeds 4MB or uses all of the DS’ RAM. At this point, I start thinking about time slicing and requesting memory from Woopsi, and decide that WoopsiOS is going a little too far.