Monday, March 2, 2015

Out of Focus

Adding the SDL-rtf driving directions viewer to PSPMaps got me thinking once again about word procssing on the zipit.  Every so often I find myself wishing for something like Wordpad, to go just a wee bit outside the domain of the traditional text editor and wander into the territory the word processor.  This was one of those times.  The example viewer program included with the SDL_rtf sources was compact and simple, and solved what appeared to be half of the problem, drawing the formatted text onto the screen.  All that remained to be done was the editing functions, and some sort of user interface.

Once upon a time I got fairly close to the goal, with flwriter and nanox, but was derailed by a particulary nasty early winter snowstorm and never got back on track.  I dug up the old executable and took some screen shots of the user interface, which unfortunately requires a mouse, or the mouse emulator.  However, it really looks almost useable.  I really must finish that up someday.

Meanwhile, could I do something similar on SDL to add a simple editing interface to the SDL_rtf example?  The one requirement would be a small widget set in C using SDL for the backend.  It all seemed so simple.  But in fact it was not.

While C++ GUI widget toolkits are truely a dime a dozen, finding anything for plain vanilla C can be quite a chore.  Finding such a beast that runs on SDL is even more difficult.  I did find AGAR, but something about it just didn't fit my plans.  Perhaps it used cmake or one of those crazy build systems based on python.  Or maybe it pulled in some other huge library as a dependency.  I can't remember, so I'll have to get back to it someday and at the very least jot down what it was that turned me away.

With nowhere to turn I looked backwards, at an old blog post.  I once used a throwaway simple GUI sample program called fgui to prove out the native iz2s compiler on the zipit.  I pulled up the code from my fgui github fork, only to realize it was not actually the same fgui.  I eventually tracked down a copy of that one on an old SD card, although I can't find it anywhere on the internet.  But in the meantime I was looking at an entirely different fgui.  One with perhaps a bit more promise.

The github fgui had just 3 (or 4 if you count a label) basic widgets.  And it wasn't particularly pretty.  Plain old boxy widgets with a seriously ugly font.  But it was written well enough that I could understand it quickly, and certain features made it a good fit for the zipit.  For example, while it could potentially support a mouse, the widget focus traversal and activation is currently all keyboard driven.  I like that.  It also has no dynamic memory allocation calls and it's example test code made a very small executable, under 20K.  Excellent for the zipit.  Plus it doesn't take over the entire SDL program.  In fact it's only connection to SDL is a single drawpixel function and an fgui event handler hook somewhere in the main loop of the SDL program.  Nice modular design.  I like it.

Naturally I had to ruin it.  So I swapped the ugly bitmap font with an SDL_ttf font, breaking the pristine modularity somewhat, but not actually too much.  I may someday restore the ugly built-in font as a make/compile time option, or possibly a runtime fallback option, or both.  But first I'll have to dig up a better looking bitmap font...

fgui demo with ttf font and "fancy" buttons

The next thing I did was add a bit of texture to the flat boxy buttons.  Nothing too modern, but I can now imagine developing a GUI with it that I'm not embarrassed to show.  I also roughed in a checkbox widget, a list box widget, and pretended to make a menubar several times out of the few existing widgets.  I came to the conclusion that I need to add some widget traversal setup functions so I can complement the TAB key with the arrow keys (when appropriate) to change widget focus and get around on the screen.  I also need to modify the widget focus mechanism to allow for menu hotkeys, and to develop a way for parents to pass along focus to their child widgets.  Then maybe I can make a real menubar.

After which the RTF editor code should be a piece of cake.

Oh, wait.  Did I forget to mention my lack of focus?  At some point during the fgui development I got distracted with an sdl asteroids game that looked too good not to play with.  So I compiled a version for the zipit.  I'll try to post it here, when I get a chance.

I also went a bit off the rails and added a theme color option to the fgui widget code.  Here's an example running a green theme with a totally fake mockup menubar widget.
Ha,  fooled ya!  The menubar is truly fake, and I really did add theme colorizing functions in a moment of weakness (It was surprisingly easy due to the well thought out  fgui design).  But in reality, that's actually a screenshot of fgui running in Arch linux on the zipit.  Apparently the Arch fbgrab program only knows about green, or possibly I used it wrong.  But who cares.  The cool thing is I finally loaded the zipit Arch image onto an SD card, installed the Arch packages for gcc, make, sdl, and sdl_ttf  and was able to compile and run fgui right there on the zipit itself.  To keep things on the small side I installed the Arch SDL package without dependencies, and then used the SDL environment variables to select the built in fbcon driver and set the correct rotation for the zipit screen.  Arch runs a bit heavy for the zipit's paltry 32 megabytes of RAM, so every little savings helps.

So now what should I do?  Finish fgui and work on the SDL_rtf editor program, or play some more with Arch linux on the zipit?  I can't decide.

Ok, I guess I decided Arch Linux is more fun right now.  I compiled qemacs on the Arch zipit so I could be more productive, and got busy.  I'm considering installing X11 to see how well (poorly?) that behaves, so I built the zipit mouse emulator and tried it out in the old fgui SDL demo.  I also compiled gmu with mp3 support so I could play some internet radio.  Here it is in the simulated retro green theme imposed by fbgrab.  In real life it's much prettier.


I think next up I'm gonna have to build proper working version of fbgrab for Arch.