I Blame the Trees

Still not much happening in the software world.  The real world gets in the way.  We have electricity again, but we also have dozens of downed trees to cut up and remove, which leaves far too little time and energy at the end of the day for a whole lot of this stuff.  Gotta get me a chainsaw.

Anyhow, I did somehow manage to spend a few minutes testing things, trying to identify which lib causes the image display bug in the fltk example programs when the screen is rotated.  The pure microwindows nxview program is able to display pngs, jpegs, and bmps in any orientation so libnano-X is probably ok.  The next layer under fltk is the libNX11 X Windows compatibility layer.  So I took a ride in the wayback machine and dug up the ancient xv sources. 

Ah ha!  This program does all sorts of X11 trickery and only shows a blank splash screen when the nano-X server is running rotated. 

But it looks just fine in the native orientation.  So the problem is somewhere in libNX11.  Quite possibly in the cliping functions used by both FLTK and xv.

At this rate I should have it solved by Christmas.  I just hope it doesn't snow again for a while...

Update:

Apparently nxview has trouble with alpha blending.  Here it is in the native screen orientation.  The edges of the dice in the alphademo.png image blend nicely with the background color of the window.

And here it is with the -L orientation.

No blending!  I don't believe nxview uses libNX11 so that places at least some of the problems in libnano-X.

Yet Another Calculator?

So it turns out Nano-X and FLTK 1.3 needed some extra lovin to get themselves working together real nice on IZ2S.  It took a while, but I finally got some freetype fonts loaded in the right place with the right config files.  Some small patches enabled kerning and anti-aliasing in nxlib and FLTK.

I also got the X11/rgb.txt color file installed so the Xlib example programs can use colors by name.  Unfortunately there's still some sort of clipping issue to work out when running nano-X -L to rotate the zipit screen to the proper orientation.  Images display fine when the screen is unrotated, but not when rotated.  Gotta fix that if I want to run Dillo on this thing. Anyhow this is what the mbasecalc calculator looks like, running with FLTK widgets on nxlib over nano-X.

It's got hex to decimal conversion (which I really like) and some nice shortcut keys for ease of use on the zipit.  I'm still thinking about tweaking the key bindings a bit though to minimize use of the ALT key.  And the calculator only uses part of the zipit screen, so it has room for more functions if I ever get really motivated.

Here's an FLTK font browser showing the list of fonts currently installed on my IZ2S setup.  Unfortunately there's currently a bug somewhere in either FLTK or nxlib that prevents all but the various sizes and shapes of the "helvetica" sans font family from loading. The good news is that font family looks pretty good, and fills most of  my needs.

I also fixed a few more issues with flwriter that were most likely caused by the jump to FLTK 1.3 from whatever old version it was last compiled with.  It works pretty well if you stick with the one working font family.  The default xhtml files load up just fine in the various browsers available on IZ2S, and the single rtf export file I created loaded up ok in word.  This is what flwriter looks like on the zipit with the anti-aliased fonts.

And here's the upgraded FLTK filebrowser with the shinier gtk+ theme and antialiased freetype fonts.  I'm not quite sure what to think of the microscopic  text in the preview pane.

Not too shabby though...

Refining the Layers

Just a quick update for now.  After playing with the FLTK demos for a while on the zipit I began to realize they could do with a bit of refining.  For example, the keymap still wasn't quite right, and nothing was really tuned to fit on the 320x240 screen.  I did a bit of tweaking in the microwin layer and got the alt key recognized as altgr so the keymap would work as loaded in all the microwin demos.  But then the nxlib layer needed another similar tweak before the fltk demos would work right.  I got that done, and moved onto the FLTK editor demo. 

I figure the editor demo might actually be useful as a simple text editor when launched from say gmenu2x, so I decided to take a look at that one first.  Most FLTK apps seem to have a few hardcoded window coordinates located in or near the main() function.  This turned out to be the case with the editor demo.  I adjusted the coordinates to fit nice and tight on the 320x240 screen and all seemed well and good until I hit the file save dialog.  Apparently the builtin FLTK dialogs are just a wee bit chubby for the zipit screen.  So I adjusted them a bit as well.  Here's the tweaked FLTK file dialog. 

I think it looks pretty nice on the zipit.

And since the simple editor worked out so well, I thought maybe I'd take it one step further.  So I poked around the internet and found some references to an abandoned old fltk word processor program that works with xhtml files and can export to rtf.  Hmm, that's almost borderline useful.  Maybe with some helper utilities to convert things...

So I compiled flwriter and tweaked it a bit for the zipit screen.  So far, so good, but it revealed a problem.  I still need to figure out how to install the fonts for nano-X.  I suppose that's next.  It'd be really nice If I could work out how to share the dejavu fonts in the netsurf package.

Layers and Layers (revisited)

Yet another of my long term goals for the zipit is to get FLTK working so I can build the Dillo browser, maybe murgaLua, and play with some light embedded GUI development.  FLTK applications have worked out quite well on some of the smaller linux distros like TinyCore and Puppy Linux.  So perhaps some of that good stuff could be squeezed onto the zipit.

Recently someone built FLTK 1.3 on Nano-X on DOS, so I figured if that was now possible, then a zipit port ought to be workable as well.  I followed some of the directions from the DOS port, and eventually figured out which options to select in the MicroWindows config file to convince Nano-X to build and run on the zipit.  The mouse was a bit tricky, but I eventually figured out the fake z2mouse was emulating a PS2 serial mouse, so all I had to do was softlink /dev/input/mice to the /dev/mouse device Nano-X was expecting, and it worked.  I still don't know exactly what to do about all the font options, but so far I haven't needed to sort that out just yet.

Now we all know by now that the framebuffer device on the zipit is actually a 240x320 pixel LCD oriented at a 90 degrees right rotation from the keyboard.  This must be accounted for whenever you want to display something on the screen.  Nano-X has a handy -L command line option to rotate the screen to the left for 320x240 pixels aligned with the keyboard.  But it also rotates the mouse coordinates, making the pointer 90 degrees off.  However, I found the spot in the Nano-X code where the mouse coords come in from all the various drivers.  So I added a 3 line zipit patch to rotate them 90 degrees to the right to match the real orientation of the screen.  And they remain matched up when the both the screen and the mouse are rotated by the -L command line option.  Nice!


I gotta revisit DirectFB and try to apply a similar mouse fix.  Especially now that I've got glinks running properly on SDL instead of DirectFB.  That leaves me completely free to discard the broken IZ2S DirectFB libs and start again from scratch.

I may also revisit the z2mouse driver itself.  The more I use it, the more I'm convinced that maybe the left mouse button should be on the play key instead of the center of the dpad.  It's nice for pointing and clicking to have all the functionality right on the dpad, with the lesser used center and right buttons off to the left on the play and stop keys.  But dragging anything takes 2 fingers, and it's really hard to get both of them in the confined space of the dpad.  So I'm thinking now that maybe the left and right buttons do most of the dragging work, so they should be moved off to the side of the dpad on the play and stop keys.  That leaves the center of the dpad for the center mouse button.  Easy to remember and it doesn't cross my fingers up dragging things around, or highlighting text.

Anyhow, FLTK seems to work.  Now I gotta just find me some FLTK apps to tinker with that work well in 320x240, or I suppose 240x320 if they don't need the keyboard.  These look pretty good, for example.  Perhaps eigenmath?  Or alsamixergui?