Notices

I fail to see how that has to do anything.

All it takes is making something auto-set the rotation-enabled flag to on. Some daemon/script should be able to do it, if you look at how Shortcutd does it. Could be pretty resource heavy though - but if you made it do nothing than respond to dbus signals, you could make it happen. I mean really, if you just combined the source code that allows shortcutd to enable rotation with the source code of rotate daemon, it could be done.

At any rate, I'm kinda assuming/hoping the full-scale portrait-ization of Hildon will happen soon, now that MohammadAG fixed the Qt bug that made it a problem and submitted the fix upstream. And then we won't have to worry about finding ways to enable auto-rotate on everything.

Actually, you can probably do it by using a Queen Beecon Widget which launches Conversations, then uses dbus to enable auto rotate on the just launched app. Or dbus scripts that listens to the launch of Conversations on dbus? One of those.

is it possible to add swype like movements for faster typing on the QWERTY & Alphanumberic keyboards??

Curious: Did you try swype? From what I heard it's really not that great.

On another note: Something I was going to see if I could work on eventually, or suggest for way down the line, is something Qwo/8Pen-like as a third 'keyboard' type. IE, you have Alphanumeric, Qwerty, and then "Circular"/"Swirling" (I'd use one of those words, because 8Pen is a specific proprietary product, and Qwo is open source, but presumably it wouldn't be a direct port. Also, that style of input method deserves a generic name too.)

I used it on my girlfriend's N8. I'd say it is that great, i'd love it on the N900

Cool. Good to know. That said, if gesture support is added at some point, a swype interface would be doable if realsportscars of someone else wrote the code. I'm thinking the circular/swirl input method is even better for touch screen use personally though. But if both can be implemented, that'd be great. I'm all for giving users choices.

I have tried it on NITDroid and can say it really works very well...

@Mentalist but not only:
easy buttons swapping is an improvement that i'd like to add but not in a close future. I think that it isn't too hard to add, but first I have to fix a lot of things. You have also to consider that if I ever add a "swype" option, buttons swap could be a problem.
I don't know how it works exactly but I had a couple ideas to do something similar (swype is patented but I'm quite sure that original ibm's study about this kind of input not are).
But again before I have to fix other things, my main target is now the "commit problem"
Newline and capitalization doesn't exists in alphanumeric kb but I'm telling my idea so people can say something: "prev" button becomes "shift" and its behavior is the following:
One press will capitalize only one character (usefull for name), double-press will hold the shift untill you press shift again.
In this way i can remove "ABC" and "Abc" and only leave "abc". Thanks to new space i can add a new entry in this menu: "symbol" and add newline in this layout.
I like your idea of putting it as third choice in "0" button but this introduces some problem in management of FastWrite that it is already quite complicated.

Hildon doesn't support multiple instance of kb so I can't do what you ask. hildon-input-method only handle one "application target" at a time and, by the way, manage of multiple instance could be very hard...

About adding a feature like ctrl+shift+r: I don't want do this (if ever possible) because kb must be only a kb

@MaddogG: Thank you a lot for your donation!Grazie

Well, the way I imagined it, if you ever added 'swype-like' input, you could make it a 'third' key layout. Meaning, now you have qwerty, and through that one button, you can toggle it to Alphanumeric. Now imagine you have a third entry in there called Swype, that keeps unchangeable button positions. (That said, I'm sure with enough thought, swype-like input can be written that checks what button is in what position when the vkb is loaded. But that would be a major, major PITA to code.) So you have QWERTY, AlphaNum, "Swype-like", and "Circular/Swirl" - in theory. Again, I honestly think your keyboard is good as is. I don't expect anything so radically new Swype or the circular input methods - I intend on eventually getting good enough to contribute such code myself, but that is a slow process indeed.

If you get around to doing it I'll be happy to share my ideas on making it happen. I can't write the code itself, but I'm decent enough at logic, and can understand programming without necessarily being able to word it in the coding-language-appropriate terminology.

Yeah, I definitely agree with that. (You could probably also just split the next/previous buttons into two each, couldn't you? They seem wide enough to still be usable if split into two buttons, even in portrait mode. That way everyone who likes prev/next gets to keep those buttons, but you also get an extra button, and one for the shift key.) Either way though I do like that idea. It certainly gives you even more room for symbols, although I suggest waiting to see if other people are okay with losing the Next/Prev buttons - I don't use them so far, but I'm sure there are people who like them.

I really need to get off my *** and learn how to recode Hildon, then. (It's in C, I believe?) And yes, I realize how it could he hard. You have to make sure each 'instance' is properly targeting the right application, that it can store the text correctly, etc. But on the other hand, I mean, web browsers do it all the time - they manage to store a bunch of text boxes on different web pages and don't run into collisions. So I am pretty confident it's doable. I just need to learn how to code in that language and get good at it to the point where it would be even feasible for me to try.

I agree. It's doable, but it does not belong in the vkb code. It can be released in a separate package if need be, but it shouldn't be a part of the keyboard. When you meld projects like that, things get messy and inconvenient.

The problem with losed commit is exactly due to this...vkb targets itself xD
I can solve setting the input field as read-only but this hide text cursor...really bad!

Well, I was rambling about something completely different, but that's quite informative. Thank you. How long does the input field have to stay read-only? Can't it be set to be become read/write after the vkb closes? Or for that moment between pressing 'out' of the vkb and the finishing of the text-committing?