this toolkit will play nice with the maemo WM, yes?

I was really close to having the perfect desktop if not for the stupid 1 pixel border.
http://talk.maemo.org/showthread.php?t=52562

Maybe I should give that a revisit some day.

Sure. ASUI tells the WM not to draw window decorations and to always be on top. The toolkit wouldn't do either of these and would get a nice box below the statusbar. When it receives the fullscreen key it just tells the WM to go fullscreen (not sure how) and then the WM either increases its window size and sends a configure event or the library increases its own window size (not sure which one). That should be all that needs to happen for it to work like a GTK app. Telescope will even display the ASUI window or the ASUI popup clock window if something glitches and you're able to open Telescope. So nothing special needs to happen to work with it either.

The titlebar and close button are drawn by the WM and all XLib apps send their name to the WM.


Can you tap those statusbar applets? Do they hide when using fullscreen in apps that don't support fullscreen? Not sure how well that would work with apps that have important stuff behind the statusbar...

Yeah, it was actually pretty nifty.

All apps launched automatically in full screen mode.

Pressing the full screen key would simply toggle the status bar on top of whatever app was running. Pressing it again would make it disappear.

The status bar worked just fine too by the way.

The only thing I didn't care for was not being able to use transparent icons in the status bar anymore for some weird reason.

auouymous, I leaved a couple of comments in your googledoc in part about mainloops.

Actually, your document is great. You have covered all different parts of the UI.

By the way, i don't know how to make a custom text field that will work with native on-screen keyboard.

And I have replied to your replies...

I haven't looked into it yet but I believe the keyboard is a separate window or part of the WM as it doesn't appear in Telescope and the overall window sizes decreases when attached to it. It should be injecting key events into the window so all we have to do is figure out how to open the keyboard and resize our window if the WM/keyboard doesn't already do that. (made a note of this in the doc)

The hildon-input-method process should be what draws the virtual keyboard and its source is at http://maemo.gitorious.org/fremantle...d/trees/master , maybe someone could dive in and figure out how to interact with it.

Another option could be to embed the xkbd source into a keyboard widget so it can be 'slid' into the window when needed by text widgets or embedded with its keys sent to a callback.
Advantages:

• would use the same theme as the app
• multiple layouts, swipe up to see a list of them for quick selection, swipe left or right to slide through them or swipe down to close (unless embedded). Layouts: stylus keyboard with keypad (like current hildon keyboard), alpha only (slightly larger keys), numeric only, larger alpha only (like the fullscreen keyboard), larger numeric only and various other special key layouts.
• the hildon keyboard can gray out alpha keys when opening for a numeric entry widget, a custom xkbd keyboard could only show the keypad layout.
• don't know if hildon keyboard supports user-defined layouts but xkbd looks to have layout files that could be used to define custom layouts that would appear when swiped and apps could select specific layouts or include their own.
• the app would be aware of the keyboard's height and could alter its layout if needed.
• we could kill that 10meg hildon-input-method process after we replace all gtk apps, or use a button in ASUI to toggle it on and off as needed for gtk apps

Cons:

• more work
• no handwriting input unless we code it as well

Here is the page with the commits for Qt that enabled it to support the Hildon Input Method. And, while it doesn't seem to work, Austin Che also looked into it a little bit: https://garage.maemo.org/plugins/scm...ch&view=markup

Xkbd needs a little touch up.

The repeating keys value should probably be over 100.

In the original build I think it was set at 5.

I asked Ukki to recompile it with a setting of 45 I believe.

I still on occasion get unnecessary key presses.

Also, there's really bad coding if you touch one of the keys, especially if they are quite large.

It's suppose to give a shift value if you touch a key and slide your stylus on the screen.

Honestly, that code needs to be gutted out.

Lastly, Xkbd always produces an error on 2 keys that aren't supported.

This should be removed or surpressed as well since many scripts will stop once it hits that error message.

By the way, I could do a proper, almost full screen keyboard like this, something I have yet to try.



To get the keys to lay out like an actual keyboard though, I would need to run 5 separate Xkbd processes.