One more thing, Xkbd allows for three different button appearances.

Square, rounded, and none.

I would just go with none so it would look something like this.



Of course the layout would look like an actual, physical keyboard though, hence the need to run Xkbd 5 different times.

Once the layout is set then I would replace all the keys with .png images. That would be over 100+ specially drawn images by the way.

I probably would need help on that since I have no graphic design background knowledge.

Anyway, I'm just saying that it can be done.

If we forked xkbd into the library it would use the library's theme system to draw the keys as buttons. The keyboard would of course be a widget and thus the theme could apply a unique style to the keys to make them look different from other buttons in the theme.

Does xkbd only allow you to define one row of keys per instance? If we fork it, our version would allow an entire layout to be defined in one file, positioning the keys inside automatic layout boxes. Each layout could also have one definition that handles both landscape and portrait or separate definitions for each orientation.

Nope. This keyboard here has just one Xkbd running.



The problem is that they're all huddled butts to elbows next to each other using the same columns.

In a physical keyboard, the keys don't line up this way, so really, the only solution I can think of is to have a separate Xkbd running for each row.

I guess I could do it with just one Xkbd running but you would need to add coding to allow for a dead key.

Touching it wouldn't be highlighted and it also wouldn't send out a text signal.

Hope that makes sense.

Hildon Input Method frameworks is based on Gtk-IM framework if I recall correctly. And it is very tightly coupled with GTK and that's why maemo's native onscreen keyboard works only in GTK apps. And I'm not even sure that it sends key events to the textfield directly because of word suggestion support.

Anyway, it seems that full-blown UI toolkit will need a couple of years of work And I don't see any reasons to consider UI toolkit as a goal.
Lets consider some practical things, like ASUI or Simp, as a goal.
If audioplayer will require text input — we will need to investigate how to implement it. If no — great, lets give up on text fields.

By the way, I have working demo with Seekbar & Player buttons from Kroll's screenshot, with cool seekbar handler transparency

You can grab the source code and track the development at github: https://github.com/IlyaSkriblovsky/lx

We don't need to add eveything to the toolkit, only what is needed at the moment. The full list of widgets was just a roadmap and if the toolkit is properly designed it can easily be extended with more widgets later on. And the entire toolkit as described in the doc is pretty easy to do, couple weeks of good development time. Even the keyboard would be easy, a simple markup language to define key names, key codes and key positions would generate widgets inside a container widget. The callbacks on the buttons just hook into the Xlib key handling code and invoke whatever callbacks are attached to them.

The hard part is coming up with a good themable and modular structure for the library that supports user-defined widgets. The widget structure just needs a bunch of callbacks to render itself, handle taps and keys, return its minimum and maximum sizes so the parent container can allocate and assign it a position and size.

Anyway, I can code up the keyboard widget and text fields after I get the file manager started since it will need them to rename files and later on for its text editor.

And good job on simp, should be fully functional by next week.

Good news: I've measured gstreamer memory consumption on n810:
* console app, playing local mp3 file (via dsp): ~2.8mb
* gtk app, playibg local mp3, with working seekbar (GtkScale): ~6.5mb

Since ps command on n810 is very limited, I've measured by VmRSS in /proc/<pid>/status


Btw, I was trying to replace maemo onscreen keyboard with my own back in 2009. I was owned N800 then, so onscreen keyboard was the most important part of the UI for me. But I was stuck trying to embed by keyboard in Hildon Input Method framework. So, the only workin code I had is keys layouting with hboxes and vboxes just like you described

NICE!!! This could be a 5meg xlib app, smaller than xmms. Gtk is likely to bloat down more when you populate a playlist widget, but even if it was 10meg it would be better than media player and canola. However you want to make it is fine with me. Maybe it could be done in Gtk to get it released sooner and if I ever get time to do the file manager we could look into porting simp over to its toolkit.


Its always harder to integrate with something else than it is if you control everything in the stack.

If you need testers for any of this, I'd like to help. I have both a N800 and a N810 in case anything ends up being specific to a particular device.

the opera guys integrated the maemo OSK via a gtk input area overlay of some kind.