2007-10-17

Woopsi Version 2 Ideas #3, PALib Licencing, and Woopsi Docs

More Woopsi ideas that might make it into version 2. First of all, I pre-ordered a GP2X F200 as soon as I received an email announcing it. I’m hoping that the d-pad isn’t as spectacularly unusable as the mini joystick employed on the original GP2X and the three revisions of GP32, and I’m also hoping that it won’t suffer from the quality control problems that plagued the first edition of the F100 (though mine doesn’t seem to have any of the reported issues).

Anyway, rubbish d-pad or not, I’m planning on investigating the possibility of porting Woopsi to the new GP2X. Unless GPH manage to screw up the touchscreen as badly as they screwed up the joysticks, that is - if that happens I’ll just write it off as a bad idea.

Another idea - as I’m going to have to alter all of the hardware-specific sections of Woopsi for the GP2X anyway, I might look at stripping the PALib code out at the same time. I foresee there being two major barriers to widespread adoption of Woopsi - firstly, it uses C++, whereas most DS developers probably use C, and secondly, it uses PALib, which abstracts away the complexities of the hardware and is therefore frowned upon by the more purist homebrewers. C++ has to stay, as only a crazy person (or Linus Torvalds, apparently, who it seems will approach every problem with the same rusty screwdriver he’s been using for the past 20 or so years, because he’s seen a few people make a mess when using other tools such as step ladders or those new-fangled electric screwdrivers) would try to write a GUI with C when there are more suitable alternatives around. PALib isn’t a necessary requirement, however, and it would be annoyingly tedious but possible to strip it out of Woopsi and replace it with libnds calls instead.

On a side note, I’m slightly disturbed to discover that no-one seems to know what licence PALib has been released under. SourceForge lists its licence as “None Listed” (helpful), whilst no-one on the PALib forum has responded to a question I posted about it. The PALib installer doesn’t contain a licence or any mention of one. It doesn’t even have a copyright notice anywhere. To me, this suggests that it’s considered public domain. Either that, or choosing a licence didn’t occur to the developers. If it’s the former, then I could strip out the PALib dependency simply by merging the functions I use into the Woopsi sourcecode. If it’s the latter, then I’m dubious about using PALib when I have no idea what terms I’m implicitly agreeing to follow every time I hit the compile button.

Some other things that I think may be potential barriers to Woopsi adoption are:

  • It looks like an operating system from the early 90s
  • It hasn’t been designed specifically for the DS’ ergonomics (contrast with the beautiful iPod Touch/iPhone interface)
  • Homebrewers generally don’t want to use other peoples’ code - they want to create and discover things for themselves

I disregard all of these minor barriers because they are intentional in the design of Woopsi - I want to create an interface that looks like Workbench 3.0.

Here’s an idea that I want to integrate into version 1 - bitmap buttons. These are just like standard buttons, except they display a bitmap instead of text. When held down, they show a different bitmap. Should be easy to implement.

The addition of bitmap buttons will let me take Woopsi in unusual directions. For example, we can create a window the size of a screen, make it borderless, and add a superbitmap to it. We can then add a set of borderless bitmap buttons, and we’ve created an interface more akin to MenuDS than a windowing system.

Lastly, I’ve added a load of documentation to the Woopsi SourceForge project, which you can find here:

woopsi.sourceforge.net

Comments

Jeff on 2007-10-18 at 03:08 said:

Actually, one thing I’d like to see is the ‘libreset’ code (that floats around) being wired in and strongly supported. I have never been able to get it working (on my R4) but I can see that the media player (moonshine) manages to work

I think that it means you need to build the arm7 part of your app differently, which means messing with parts of PAlib that it doesn’t look like you should mess with.

I think that having Woopsi handle the hard-problem of resetting back to the firmware makes it more likely that it gets used for small applications and less vulnerable to the criticism that it’s “not a very good windowing operating system”.

Jeff on 2007-10-18 at 03:16 said:

Oh, and a ‘console’ gadget - you know, something that the rest of your code can just ‘printf’ into during debugging. I don’t think the current textviewer fits the bill, does it?

ant on 2007-10-18 at 05:01 said:

libreset is a good idea. Resetting comes up regularly on the PALib forums, so there might be a solution on there.

A console gadget is also a good plan. I need to make a multiline textbox anyway, so I might extend that with block scroll functionality. That’d do the trick, I think.

Jeff on 2007-10-18 at 08:24 said:

The difference between a console and a text-box with scrolling is that I’d be happy for the lines that scroll off the top to disappear. ie, you only really need the last ten or so lines of debug information whereas you might generate hundreds of lines of debug in order to get to where your problem actually is.

Jeff on 2007-10-18 at 08:24 said:

Of course, you are leaving me no excuse whatsoever to writing the “personal organiser” application that my wife needs before she switches from iPod to DS.

ant on 2007-10-18 at 16:54 said:

libreset has apparently been superseded by RebootLib. There seem to be quite a few issues with it, though - aside from the fact that it’s a bit of a bodge, hardware support is shaky (due to the fragmented nature of the DS’ flash cart market) and it’s got a custom licence with some unfortunate clauses that make it non-free.

Jeff on 2007-10-19 at 02:01 said:

It may well have been rebootlib that I was thinking of. I’m not so sure that its ‘non-free’

According to http://forum.gbadev.org/viewtopic.php?t=12774 1.1r is licensed under MIT/GPLv2 and http://www.opensource.org/licenses/mit-license.php is pretty clear that the MIT license looks pretty free - just include the license text in your source release, and perhaps an about box gadget and you should be fine.

Jeff on 2007-10-19 at 02:06 said:

One further point to note. Lick seems to aggressively want to hand responsibility/ownership of rebootlib to someone else. As such, its highly unlikely he’s going to come gunning after anyone violating licenses, and thats the worst case. Since all you’d be doing is shipping out the same source code (in the same manner as PALib does), you’d be fine. It would only be if rebootlib got upgraded to use a different more restrictive license that you’d have a problem, and that seems fairly unlikely.

Jeff on 2007-10-19 at 02:08 said:

In fact, it does raise another issue. A different framework I worked on eons ago specifically provided support for automatic “credit-display” for incorporated libraries. If you included libfoo in your application, it was trivial for libfoo to arrange for the appropriate credit to appear in your applications about box.

An “about gadget” that automatically did “all the right things” might also be a valuable addition to Woopsi - that way, application authors can wire libgif, libjpeg, etc and have a simple mechanism for meeting their license commitments

ant on 2007-10-19 at 05:16 said:

Lick must have altered the licence again at some point after the thread I was reading (on the gbadev forum). He’d decided on a custom licence like MIT, but with some badly thought out clauses. I’d have to get the source and check it. It was originally a GPL licence, which would have prevented me from using it.

Approaching development with a BSD hat on really makes you see the GPL in a new light. Even if you just want a tiny piece of functionality from a GPL project, you can’t use it without everything suddenly becoming GPL’d. Shame the LGPL is such a mess, really (I’ve had to help explain that one to a technology lawyer - if they can’t get past its ambiguities what chance do the rest of us have?).

An about box is a good idea, but I’d implement it as a requester (predefined window) rather than a single gadget. Not sure how I’d make it automatic, though.

I’ll put all of this off until I’ve got the basics sorted, but I’ll add the ideas into the SourceForge project tracker.

Jeff on 2007-10-20 at 00:47 said:

I don’t think the credit window has to be completely automatic. But if it becomes trivial (like, the application just has to call “Woopsi::AddCreditForThis(const char *module)” and that pulls in all the appropriate plumbing, that makes it a lot simpler.

The predefined window could be the actual Woopsi credit window by default, which isn’t a bad thing for Woopsi to have anyway. And all you are exposing is the ability to add extra lines of text at the bottom.