Qt VKB

Realized last week that what I need (or want, luckily those match quite nicely these days) to do is a virtual keyboard prototype based on Qt... Got the basic UI in there during the weekend, so what we have now:



Works also in N810 but the performance is lacking, it's not totally fluid.

Plans:
- Have to figure out proper layout(s), wouldn't want to copy directly e.g. from iPhone or N810
- Support gestures and other usability tricks
- After this, make more eye candy, animations etc. Not too much, but to help usability
- Supporting word prediction and hit prediction is totally doable but would need more AI & grammar database integration, so not right now for this UI testing

Anyway: If you got good layout & feature ideas, please share!

Comments

havoc said…
Take a look at the Fitaly Keyboard! http://www.fitaly.com/domperignon/domperignon4.htm

Steeling a keyboard is bad, however, if you made your QT VKB modular, I could load my own keyboard layout. I purchased a license for the Fitaly KB for my Palm device years ago. I could legally load a Fitaly keyboard profile (especially if you made your software easily extensible) and use it! Others could license or negotiate with TextWare Solutions to use the keyboard.

Win, win, win! Don't underestimate the power of that keyboard layout. It is as good as they claim. That's the one thing I really miss about my old Palm.
November 3, 2008 at 7:54 PM
Kaitsu @ QUIt Coding said…
That Fitaly layout sure looks...different =)

I totally agree that QWERTY is not the most suitable layout for mobile/touch devices, but I'm also not very keen to "non-standard" layouts you first need to learn to use. Here I'd like to experiment how (QWERTY) virtual keyboard could be made nicer & more usable when we have more powerful devices. Supporting different layouts is a good goal!
November 3, 2008 at 8:38 PM
lcuk said…
Hi, i'm lcuk from #maemo :)
i've just gone through the same growing pains adding a virtual keyboard in liqbase ( http://liqbase.net )

Theres a guy who you might be interested in speaking to, hes written an svg front end for keyboards and stuff.

I had a quick look at the recent maemo summit and whilst he also had the rendering deficiencies it looked really cool and expandable, I think it might be an idea for you two to get in touch.

http://jyro.blogspot.com/2008/09/inkface-svg-based-gui-design.html


It would be great if there was only 1 vkb, but it seems every graphical kit invents their own - i wish every device had a keyboard like the n810.

gary
November 4, 2008 at 3:04 AM
deviceguy said…
There is QVKeyboard:
http://qt-apps.org/content/show.php/QVKeyboard?content=77983
November 5, 2008 at 10:22 PM
Kaitsu @ QUIt Coding said…
liquid/lcuk: Approach of using fully SVG for theming is interesting, but as a liqbase developer I'm sure you also prefer speed over XML... =)

deviceguy: Thanks, tested QVKeyboard now also! Approach in there is more traditional X11 & QWidget way, but I'm sure there is much to learn from that. My proto utilizes QGraphicsView + items and widgets, targeting into more fluid UI. For example in QVKeyboard all QMyButtons listens mouse events, but in Qt VKB the keyboard view listens the mouse and uses itemAt() to seek the pressed key. This makes it possible to switch between keys and react only after releasing the button/touchscreen, for iPhone-like character popup.
November 5, 2008 at 11:12 PM
lcuk said…
kaitsu,

heh, I've got nothing against xml - once objects are loaded they are identical.

However with liqbase I use a custom format for the sketches, this is a very simplistic rudimentary version of svg which I then render at fullspeed (as you will have seen by now).
If I allowed full svg, I *know* people would come bearing extremely heavy professionally crafted multi megabyte glyphs and expect them to operate in the same way.

I know my limitations (for now).

good luck with this project, when I get my hands on a faster compiler I might be heading for QT and I'll be sure to try it out.

gary
November 6, 2008 at 11:52 PM
Post a Comment

Popular posts from this blog

Qt 5.10 QML Shape testing

Image
When implementing component into QtQuick UI which needs something more than rectangles, images and texts, pure declarative QML hasn't been enough. Popular choices to use for items with some sort of vector drawing are QML Canvas , QQuickPaintedItem  or QNanoPainter . But with Qt 5.10 there will be supports for new Shape  element with paths that contain lines, quads, arcs etc. so I decided to install Qt 5.10 beta3 and implement all tests of "qnanopainter_vs_qpainter_demo" with also QML + Shape elements. ( This kinda makes it "qnanopainter_vs_qpainter_vs_qmlshape_demo" but not renaming now ). So here is in all glory the same UI implemented with QNanoPainter (left), QQuickPaintedItem (center), and QML+Shape (right): Hard to spot the differences right? If only there would be a way to prove this, some way to x-ray into these UIs... like QSG_VISUALIZE=overdraw  to visualize what Qt Quick Scene Graph Renderer sees? Here you can see that scene graph sees QNan...
Read more

Introducing QNanoPainter

Qt World Summit is just about to start! I’m not participating this time, but wanted to contribute one-more-thing to discuss in UI groups at the heart of Berlin ;) During the past about six months we at QUIt Coding have had a side-side-project called QNanoPainter. This library is designed for implementing custom QQuickItems into Qt5 scene graph. Currently if you want to implement custom Qt Quick item, options are at least: QQuickItem : Offers best performance due to Qt5 scene graph integration. But QSG* classes are relatively low-level with vertices, indices & materials. Painting more complicated things requires quite an expert and even then productivity is not very high. QQuickFramebufferObject : This is a good option if you want to draw with OpenGL into QQuickItem. But as we all know, OpenGL is also quite low-level API so no productivity wins here. QQuickPaintedItem : This means painting with good old QPainter C++ API. Weakness of QPainter with modern graphics accelerated ...
Read more

Qt 5.10 Rendering Benchmarks

Image
Qt 5.10.0 RC packages are available now and actual release is happening pretty soon. So this seems to be a good time to run some rendering benchmarks with 5.10, including new QML Shape element, QQuickPaintedItem and QNanoPainter . After my previous blog post , some initial comments mentioned how QML Shape didn't reach their performance expectations. But I think that might be more of a "use the right tool for the job" -kind of thing. This demo application is very much designed to test the limits of how much heavily animated graphics can be drawn while keeping performance high and while having its own strengths, QML Shape likely isn't the tool for that. To prove this point, there is a new ' flower ' test case in QNanoPainter demo app which renders a nice flower path, animating gradient color & rotation (but not path). Combining it with new setting to render multiple items (not just multiple renders per item) and the outcome looks like this with 1 and 1...
Read more