Active Topics
-
Maemo repository (5)
to Community by dredlok706 - 1 day, 16 hrs ago -
Re-commissioning N9 in 2018 (127)
to MeeGo / Harmattan by smatkovi - 1 day, 18 hrs ago -
Porting apps to Leste (41)
to Maemo 7 / Leste by Arno_11 - 2 days, 12 hrs ago -
List of well performing apps on Leste (33)
to Maemo 7 / Leste by teroyk - 2 days, 20 hrs ago -
N900 is not recognizable on any of my devices (windows 10,7, xp) What can I do? (1)
to Nokia N900 by nieldk - 4 days ago - more...
 |
|
2007-08-26
, 23:24
|
|
Posts: 305 |
Thanked: 154 times |
Joined on Aug 2006
@ Colorado
|
#2
|
I'm working on something else, but a neat feature would be a full-sized finger keyboard but instead of having it underneath the active screen, have it be transparent and an overlay. Then you could have a large keyboard AND see your full application.
Bruce
Bruce
|
|
2007-08-27
, 00:19
|
|
Posts: 29 |
Thanked: 0 times |
Joined on Mar 2007
|
#4
|
Originally Posted by BruceL
I also think it could speed up the device on some pages. When the keyboard pops up the device use quite alot of of time to re-adjust the page to the now smaller window.
I'm working on something else, but a neat feature would be a full-sized finger keyboard but instead of having it underneath the active screen, have it be transparent and an overlay. Then you could have a large keyboard AND see your full application.
Bruce
Having a transparent page with a keyboard and a field where you can see what you write would be much better than the current solution IMO.
 |
|
2007-08-27
, 01:01
|
|
Posts: 39 |
Thanked: 5 times |
Joined on Aug 2007
@ Them thar hills
|
#5
|
Originally Posted by BruceL
That's what I just implemented for Python and PyGame...
I'm working on something else, but a neat feature would be a full-sized finger keyboard but instead of having it underneath the active screen, have it be transparent and an overlay. Then you could have a large keyboard AND see your full application.
Bruce
|
|
2007-08-27
, 01:18
|
|
Posts: 21 |
Thanked: 2 times |
Joined on Aug 2007
|
#6
|
Originally Posted by tonymaro
I think i saw your post about the pygame kbd, but how do we use that to replace the
That's what I just implemented for Python and PyGame...
normal keyboard?
We need to start somewhere. Our ideas are good, we should work together to get it working!
Last edited by Brenden; 2007-08-27 at 01:23.
|
|
2007-08-27
, 05:20
|
|
Posts: 39 |
Thanked: 5 times |
Joined on Aug 2007
@ Them thar hills
|
#7
|
Originally Posted by Brenden
You wouldn't want to use Python to implement the primary keyboard - the overhead of loading python would make it way too slow. It needs written in C (which I don't do.)
I think i saw your post about the pygame kbd, but how do we use that to replace the
normal keyboard?
We need to start somewhere. Our ideas are good, we should work together to get it working!
I'd think it would be easy to grab a screenshot and use that as the background, then draw semi-transparent keys on top of it. Hooking into the GTK events that trigger the keyboard is probably the hardest part.
|
|
2007-08-27
, 05:59
|
|
Posts: 631 |
Thanked: 1,123 times |
Joined on Sep 2005
@ Helsinki
|
#8
|
Hello. We did study also a transparent keyboard option, but at least I personally didn't see it really a very viable option in terms of the UI design. The biggest problems:
- Level of transparency. Take a use case like writing in Notes or Email or Chat. It's rather hard to design a level of transparency where you see both the keyboard and the underlying text clearly.
- Moving the cursor (and other interactions). How does the user then move the cursor (or highlight the text) if the keyboard layer comes over the application area. (Using the HW keys isn't really a great solution for that...) Not to mention the other interactions there. What if the user is typing into a small text field and he wants to scroll the field using the scroll bars etc.
For instance this one: http://www.internettablettalk.com/fo...ead.php?t=9199 (Nice work Tony, btw.) But I really have my doubts whether you can actually see the text behind the keyboard.
- Level of transparency. Take a use case like writing in Notes or Email or Chat. It's rather hard to design a level of transparency where you see both the keyboard and the underlying text clearly.
- Moving the cursor (and other interactions). How does the user then move the cursor (or highlight the text) if the keyboard layer comes over the application area. (Using the HW keys isn't really a great solution for that...) Not to mention the other interactions there. What if the user is typing into a small text field and he wants to scroll the field using the scroll bars etc.
For instance this one: http://www.internettablettalk.com/fo...ead.php?t=9199 (Nice work Tony, btw.) But I really have my doubts whether you can actually see the text behind the keyboard.
|
|
2007-08-27
, 06:00
|
|
Posts: 631 |
Thanked: 1,123 times |
Joined on Sep 2005
@ Helsinki
|
#9
|
... But I'll be happy if someone proves me wrong. 
|
|
2007-08-27
, 15:01
|
|
Posts: 39 |
Thanked: 5 times |
Joined on Aug 2007
@ Them thar hills
|
#10
|
Originally Posted by ragnar
I agree, but I don't think the real point is to be able to read behind the keyboard. A text input box would be available just like on the current keyboard.
- Level of transparency. Take a use case like writing in Notes or Email or Chat. It's rather hard to design a level of transparency where you see both the keyboard and the underlying text clearly.
Originally Posted by ragnar
I think everyone is thinking about the full screen finger keyboard, not the pop-up stylus keyboard, so this doesn't really apply - the keyboard already provides it's own text box and cursor navigation features, separate from the application.
- Moving the cursor (and other interactions).
However you are correct - if you shade it darker, and it's on a dark application, it might be harder to see the keys. It's rare that a screen will be so dark that this would be an issue (near black?) but still something that must be considered.
It would be kool to count the key presses for 5 minutes of typing to find the most used keys and making them larger. QWERTY is good and familiar, however in an embedded environment it might not be the best choice to use a strictly standard QWERTY layout.
Anyone want to help look into this?