The Future of Woopsi

After this week, I won’t be able to work on Woopsi for a couple of weeks. Other commitments getting in the way, as usual. Based on this, and because I don’t want development to stagnate, I’ve decided to open-source Woopsi this week under a BSD licence. The source will be out some time before Monday.

My plan is to pick up where I left off in the middle of October, but I’m hoping that releasing the source will allow other people to cast their eyes over it and submit suggestions/criticisms/bugfixes/optimisations/new features. I’ve compiled a list briefly detailing everything I intend to get into the system before I consider the first version finished.

Feedback I’m most interested in is in the following areas:

  • Can the rectangle splitting code be done in a more efficient way?
  • Is the event handling system a sensible way to do things from the point of view of programmers who use Woopsi in their own applications?
  • Are there any major architectural blunders?

If there is any interest (from experience, I’m pretty sure that I’ll get virtually no feedback at all…), I might even set up a Woopsi SourceForge project.

If you do decide to download the source, I’d suggest holding off from starting any major projects with it - the released source will be subject to change in later revisions until I hit version 1. At that point, version 2 will probably fork the code whilst version 1 gets maintenance releases, which will ensure that new releases don’t break existing projects. That’s if there is a version 2, anyway - I can’t really think of anything else I want to add to the system other than the list below.

Of course, you could just take the code and run with it if you’re happy with it in its current state. The BSD licence means you can take the code, fork your own version and keep it to yourself, but it’d be much more beneficial for everyone if any patches get submitted back to me, either via email (my address will be in the readme bundled with the source) or as comments in this blog. I’ve even got an empty forum somewhere on the site that I set up and didn’t use; perhaps I can add a Woopsi section to that.

Regarding documentation, I intend to write two sets of docs. One set will be for “standard developers”, who just want to use Woopsi to create GUIs for their applications. It will contain instructions on wiring up events, creating windows and gadgets, etc. The second set of docs will be for “gadget developers”, who want to extend Woopsi with custom gadgets, etc. There’s a whole framework of gadget drawing, clipping, event handling and hierarchies within Woopsi, which any gadget developer will need to understand to be able to fully integrate their code into the existing system.

At some point, once Woopsi version 1 is ready, I might even write a Woopsi GUI creation system (using Woopsi itself, natch) that allows people to draw their own GUIs, then save the C++ code that describes the GUI to their DLDI flash carts.

This is the Woopsi to-do list:

  • Drawing commands for SuperBitmap:
    • drawLine
    • drawBitmap (draw another bitmap onto the SuperBitmap)
    • drawEllipse (need to find an ellipse function from somewhere)
    • drawFilledEllipse
    • drawRect (unfilled rectangle)
    • drawText (print function)
  • New gadgets:
    • Vertical scroll bar (will consist of two gadgets - a container bar gadget, and a child slider gadget
    • Horizontal scroll bar (ditto)
    • Checkbox
    • Vertically-scrolling list box (possibly re-use the TextViewer?)
    • Drop-down list (perhaps)
    • Glyph button (if we create this then we don’t really need the window close, window depth and screen depth buttons - they’ll all be instances of the glyph button)
    • WindowBorderBitmapTop, WindowBorderBitmapSide and WindowBorderBitmapBottom gadgets, which can be used in place of the standard border gadgets and display user-specified bitmaps (ie. skinning system)
  • Requesters (pre-defined windows that produce output):
    • OK/Cancel
    • File requester (ASL-style)
    • OK
    • Keyboard (one button for each of the most important keys on the keyboard)
    • Numeric keypad (one button for each of the keys on a keyboard’s numeric keypad)
  • Misc
    • Allow windows to be set as non-draggable
    • Allow windows to be set as non-closable
    • Allow windows to be resizable (now that the clipping code is in place, this might be trivial to add)
    • Optimisation
      • Merge rectangles where possible during rectangle split
    • Allow gadgets to be made visible/invisible
    • Change clicking on screen background behaviour so that it makes no windows active (thus making the screen active)
    • Right-mouse menu (perhaps - holding one of the shoulder buttons would switch the screen to right-mouse mode and show the menu at the top of the screen, in the same way that holding Ctrl on a Mac switches to right- mouse mode. Alternatively, the top menu could always be displayed)
    • Allow colours to be changed on a per-gadget basis
    • Allow font bitmap to be specified on a per-gadget basis (at the moment, the font is hard-coded in most places to use “font_Bitmap”)
    • Screen dragging (may be possible, but may not be appropriate for the DS)
  • Bug fixes
    • TextWriter clipping
    • TextViewer clipping
    • Borderless windows are currently broken (just need to send borderless status into constructor, and prevent creation of border gadgets if false)