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.

4 comments:

  1. Nano-X and XFDOS have a port of flwriter that works with FLTK 1.3.3. Was wondering if you tried that version and not just the original version. There's also the fldev IDE at Sourceforge. It was updated for FLTK 1.3.3 by the developer of Nano-X and XFDOS to use on those systems. If you need any recommendations for other FLTK software that ports to FLTK 1.3.3 and nano-x, I know several interesting applications.

    One other interesting editor that might be worth a look if you haven't tried it yet, is Dingux-Write. There are several variants of the program for various console devices including Caanoo-Write, GP2X-Write and PSPWrite. It uses SDL (not FLTK).

    Hope to hear more about your fgui project. I've been looking for a lightweight C GUI alternative for SDL. Would like to use a lightweight GUI with the mupdf library and create a portable SDL front-end. My other option would be to use pdcurses with the SDL backend to create a GUI for SDL applications. I have SDL_ttf working with pdcurses so there's currently support for rendering any Unicode characters in the UCS-2 character set.

    ReplyDelete
  2. Wow, a new comment. Cool. I'm way overdue for another blog entry, but I haven't been able to find the energy to put anything together worth reading about. Instead I rescued a crate of record albums from the turn of the 70s that were destined for the dumpster, and have spent nearly all of my spare time this summer converting them into mp3s for the zipit in the car.

    Anyhow, I'm always interested in interesting apps that might work well on the zipit, so feel free to recommend away. I'll have to check out the Nano-X and FLTK stuff and see what's new. I think I already ruled out Dingux-Write as not offering any features beyond what's available in an ordinary console text editor, but I could be wrong.

    You should grab the sources to the fgui project from my github fork (link above) and see what features are still lacking for you mupdf plans. Then comment here and it might inspire me to abandon my mp3 recording project and jump back into zipit coding. I don't tend to look at all that many pdfs on the zipit, so I couldn't really tell you what sort of GUI elements I'd want to add to nupdf to make it better. I can't even remember if nupdf uses the mupdf library, or something else...

    ReplyDelete
  3. You might be interested in some of the FLTK programs used on the Agenda PDA. There's a list of them at Sourceforge under the agtoys project. I'm using the wordsearch program from there. There's also a FLTK program called npuzzle (for the Agenda) which I like. Haven't had any trouble running them on Linux or other systems besides the Agenda. There are some settings to adjust screen size. Some other interesting FLTK applications are flcalc, fltkmm, qubix, yareversi. There are links to them at the FLTK site. I left some notes at the site regarding build issues for Linux/Windows. At some point, I'm going to try to upload all my patches and build scripts to a common location. I've done patching to several programs to customize file locations, key handling, etc. Not sure how they'd fit on the screen of a zipit but photocoloring and rendera are nice FLTK based graphics editors. There are a couple of FLTK applications for file comparison, but personally I like diffh and viewing the output in a web browser better. D+ (at Sourceforge) is a nice minimal FLTK web browser. I was also experimenting with some modifications to D+ to use it for scripts (similar to dialog). See www.distasis.com/cpp/lmbld.htm for patches if you're interested.

    I tried out mElite which you mentioned in one of your posts. Looks really nice. I'm using picogl (with SDL backend) with some modifications instead of tinysdgl. Seems to work fine. I've been trying to add enough features to picogl to use it for Emilia pinball instead of requiring OpenGL. I currently have it working, but there's still room for improvement.

    Since you mentioned converting records (which sounds like a worthy goal as well), you may want to check out gramofile (curses based application). It has some filters for cleaning up recordings. Haven't experimented with it much but declick (home.snafu.de/wahlm/dl8hbs/declick.html) also does some filtering. You can also view waveforms using apcstudio (FLTK based audio editor) and the wview program that's part of wavetools. I added an SDL backend for wview.

    I'll try fgui with my mupdf project and see how that goes. I just tried using some of the dialogs from the dialog library (with pdcurses and SDL) and it isn't exactly what I want. nupdf does use mupdf as a backend (although it might need an update after the mupdf changes in version 1.7a). I was looking into using the pdfapp code that's part of mupdf and adding a different front end. They already have X11 and WIN32 front ends. There's a FLTK and poppler based PDF reader (FlaxPDF), but it's very X specific. The same developer is also working on Fifth, a FLTK webkit based browser. The developer of XFDOS and Nano-Linux is also working on a FLTK webkit browser called Netrider (at Sourceforge). I built the first version of Netrider and the wkccc library. You can use the wkccc library with a command line application or SDL as well as FLTK. Haven't been able to build the latest version. Several dependency libraries have changed. I also updated my version of gcc and I'm unable to get the earlier version of netrider/wkccc to build anymore. Lastest version of mupdf can display HTML, but it's for viewing only. It's not the same as an interactive web browser.

    Look forward to your future posts. You have some really interesting projects in the works.

    ReplyDelete
    Replies
    1. I was just re-reading this comment. All those wonderful ideas for things to try... Anyhow, it dawned on me that I would also like to get Emilia pinball running, and I think maybe libfixgl could possibly make that happen on the zipit. Gotta investigate that before I forget.

      http://libfixgl.sourceforge.net/

      Delete