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...
Wednesday, October 26, 2011
Monday, October 17, 2011
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.
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.
Tuesday, October 11, 2011
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?
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?
Thursday, October 6, 2011
My Kingdom for a Calculator
Building the bc utility reminded me (yet again) that given it's form factor, the zipit really ought to have a decent calculator program. Bc is ok I guess, but I can't remember more than the most basic syntax, and besides, it segfaults when I run it with the -l switch to pull in the math functions like sin() and cos(). I gotta see if I can fix that. Maybe the IZ2S mathlib is busted. I sorta remember removing all references to doubles from nightsky to get it to run right. Maybe I need to rebuild a new libm.so with different floating point settings...
Anyhow, what I'd really like is to get bc working well and get a nice GUI wrapper for it like x-bc so I don't have to remember the syntax. I've already got something *almost* like that with the emacs calculator mode.
The emacs calculator has it's own command line math system like bc that works pretty well, and comes with a GUI that's ok with a real mouse, but quite a chore to navigate with the zipit dpad or via emacs key commands. Besides, it's Reverse Polish Notation (RPN). Yuck! That's just not natural. And finally, all the digits are still ALT key combinations on the zipit keypad which makes them difficult to type. I suppose it could handy though if I want to calculate some numbers and paste them into a document, or vice versa. I might look into tweaking the emacs lisp code to let me type digits into the calculator pane without the ALT key, but I'm not sure where my ancient lisp skills stand aftar all these years.
I did find a fairly simple SDLcalc program for the caanoo that might meet my needs someday. It looks nice, but it has no keyboard input yet. Apparently the caanoo has a touchscreen? Plus it's got some screen refresh issues, possibly due to the rotated screen on the zipit. I think I'm gonna try to keep the GUI but add keyboard support and maybe switch to a bc backend when (if?) I get the bc mathlib problem fixed.
I'm not sure if it uses SDL, but the cal2x calculator for the gp2x looks pretty decent. It even does some grahping if you're into that. Me, I really want that hex button. Unfortunately the source web site is korean and full of dead links. Oh well.
Meanwhile, I thought to myself, there's gotta be an ncurses calculator out there somewhere that'll do the trick. However the only ones I could find were all RPN style, like dcalc. Err, yuck?
Then I stumbled onto tcalc, the mighty console calculator. It's nothing more than a simple bash script, with ANSI escape sequences to draw the boxy graphics characters. Wow! Talk about retro, low-tech chic. I had to dig up a console font with the box chars small enough to display the entire calculator. And I had to adjust the ANSI sequences to move the whole display to the top left of the screen so it would show up on the zipit. I'd like to add some color, but even so, I think it looks ok as is.
The last tweak I did was to adjust the key parsing routines to let me enter all the digits and the basic math keys without touching the dreaded ALT button. That's a huge win for me! It could do with a few function buttons, and once again, maybe a bc backend. Someday, maybe...
tcalc-iz2s.zip
Anyhow, what I'd really like is to get bc working well and get a nice GUI wrapper for it like x-bc so I don't have to remember the syntax. I've already got something *almost* like that with the emacs calculator mode.
The emacs calculator has it's own command line math system like bc that works pretty well, and comes with a GUI that's ok with a real mouse, but quite a chore to navigate with the zipit dpad or via emacs key commands. Besides, it's Reverse Polish Notation (RPN). Yuck! That's just not natural. And finally, all the digits are still ALT key combinations on the zipit keypad which makes them difficult to type. I suppose it could handy though if I want to calculate some numbers and paste them into a document, or vice versa. I might look into tweaking the emacs lisp code to let me type digits into the calculator pane without the ALT key, but I'm not sure where my ancient lisp skills stand aftar all these years.
I did find a fairly simple SDLcalc program for the caanoo that might meet my needs someday. It looks nice, but it has no keyboard input yet. Apparently the caanoo has a touchscreen? Plus it's got some screen refresh issues, possibly due to the rotated screen on the zipit. I think I'm gonna try to keep the GUI but add keyboard support and maybe switch to a bc backend when (if?) I get the bc mathlib problem fixed.
I'm not sure if it uses SDL, but the cal2x calculator for the gp2x looks pretty decent. It even does some grahping if you're into that. Me, I really want that hex button. Unfortunately the source web site is korean and full of dead links. Oh well.
Meanwhile, I thought to myself, there's gotta be an ncurses calculator out there somewhere that'll do the trick. However the only ones I could find were all RPN style, like dcalc. Err, yuck?
Then I stumbled onto tcalc, the mighty console calculator. It's nothing more than a simple bash script, with ANSI escape sequences to draw the boxy graphics characters. Wow! Talk about retro, low-tech chic. I had to dig up a console font with the box chars small enough to display the entire calculator. And I had to adjust the ANSI sequences to move the whole display to the top left of the screen so it would show up on the zipit. I'd like to add some color, but even so, I think it looks ok as is.
The last tweak I did was to adjust the key parsing routines to let me enter all the digits and the basic math keys without touching the dreaded ALT button. That's a huge win for me! It could do with a few function buttons, and once again, maybe a bc backend. Someday, maybe...
tcalc-iz2s.zip
Subscribe to:
Posts (Atom)