Re: Automatic pop up kbd
On Friday 16 May 2008 08:53, Tick wrote:
Hi Zecke,
We are going to make the kbd show and hide automatically.
Would you please send a x-event with message
_MTP_IM_INVOKER_COMMAND with operations
typedef enum {
MTPRemoteNone = 0,
MTPRemoteShow,
MTPRemoteHide,
MTPRemoteToggle,
} MTPRemoteOperation;
When ever input is needed and dismissed.
Thanks.
Tick
Please can you make it possible to switch this off and / or force the keyboard
to hide. There's nothing worse than having an external keyboard connected and
being forced to waste screen real estate on something you don;t need.
--
Andy / ScaredyCat
Re: Automatic pop up kbd
On Fri, 16 May 2008 10:33:13 +0100 Andy Powell [EMAIL PROTECTED] babbled:
On Friday 16 May 2008 08:53, Tick wrote:
Hi Zecke,
We are going to make the kbd show and hide automatically.
Would you please send a x-event with message
_MTP_IM_INVOKER_COMMAND with operations
typedef enum {
MTPRemoteNone = 0,
MTPRemoteShow,
MTPRemoteHide,
MTPRemoteToggle,
} MTPRemoteOperation;
When ever input is needed and dismissed.
Thanks.
Tick
Please can you make it possible to switch this off and / or force the
keyboard to hide. There's nothing worse than having an external keyboard
connected and being forced to waste screen real estate on something you don;t
need.
design decision was made to remove manual control even though it has been
there from the beginning. no can do.
--
Carsten Haitzler (The Rasterman) [EMAIL PROTECTED]
Re: Automatic pop up kbd
On Friday 16 May 2008 10:46, Carsten Haitzler wrote:
On Fri, 16 May 2008 10:33:13 +0100 Andy Powell [EMAIL PROTECTED]
babbled:
On Friday 16 May 2008 08:53, Tick wrote:
Hi Zecke,
We are going to make the kbd show and hide automatically.
Would you please send a x-event with message
_MTP_IM_INVOKER_COMMAND with operations
typedef enum {
MTPRemoteNone = 0,
MTPRemoteShow,
MTPRemoteHide,
MTPRemoteToggle,
} MTPRemoteOperation;
When ever input is needed and dismissed.
Thanks.
Tick
Please can you make it possible to switch this off and / or force the
keyboard to hide. There's nothing worse than having an external keyboard
connected and being forced to waste screen real estate on something you
don;t need.
design decision was made to remove manual control even though it has been
there from the beginning. no can do.
is that code for 'someone just decided it shouldn't be there, we all said it
should but they just told us to get rid of it'?
how difficult is it going to be to patch this feature back in, I presume I
could write a panel plugin to send the same x event as above to toggle it
off? Or are applications going to be really annoying and toggle it for every
field causing me to track down the person that made the decision in the first
place and tie them to railway lines.
--
Andy / ScaredyCat
Re: Automatic pop up kbd
On Fri, 16 May 2008 11:02:03 +0100 Andy Powell [EMAIL PROTECTED] babbled:
On Friday 16 May 2008 10:46, Carsten Haitzler wrote:
On Fri, 16 May 2008 10:33:13 +0100 Andy Powell [EMAIL PROTECTED]
babbled:
On Friday 16 May 2008 08:53, Tick wrote:
Hi Zecke,
We are going to make the kbd show and hide automatically.
Would you please send a x-event with message
_MTP_IM_INVOKER_COMMAND with operations
typedef enum {
MTPRemoteNone = 0,
MTPRemoteShow,
MTPRemoteHide,
MTPRemoteToggle,
} MTPRemoteOperation;
When ever input is needed and dismissed.
Thanks.
Tick
Please can you make it possible to switch this off and / or force the
keyboard to hide. There's nothing worse than having an external keyboard
connected and being forced to waste screen real estate on something you
don;t need.
design decision was made to remove manual control even though it has been
there from the beginning. no can do.
is that code for 'someone just decided it shouldn't be there, we all said it
should but they just told us to get rid of it'?
no comment :)
i just removed the button in the theme ui actually.. so it was a
/*
...
*/
blob :)
edje_decc illume.edc - find the qwerty button - remove the comments rebuild,
plonk back into place. button is back. :)
how difficult is it going to be to patch this feature back in, I presume I
could write a panel plugin to send the same x event as above to toggle it
off? Or are applications going to be really annoying and toggle it for every
field causing me to track down the person that made the decision in the first
place and tie them to railway lines.
--
Andy / ScaredyCat
--
Carsten Haitzler (The Rasterman) [EMAIL PROTECTED]
Re: Automatic pop up kbd
Hi all, On Fri, 2008-05-16 at 21:26 +1000, Carsten Haitzler wrote: On Fri, 16 May 2008 11:02:03 +0100 Andy Powell [EMAIL PROTECTED] babbled: On Friday 16 May 2008 10:46, Carsten Haitzler wrote: On Fri, 16 May 2008 10:33:13 +0100 Andy Powell [EMAIL PROTECTED] babbled: Please can you make it possible to switch this off and / or force the keyboard to hide. There's nothing worse than having an external keyboard connected and being forced to waste screen real estate on something you don;t need. design decision was made to remove manual control even though it has been there from the beginning. no can do. is that code for 'someone just decided it shouldn't be there, we all said it should but they just told us to get rid of it'? no comment :) I initially wrote the multitap-pad with no instruction or input from anyone (I'd noticed that no one had any interest in creating a sane input method for a phone and figured one would eventually be necessary): http://chrislord.net/blog/Software/multitap-pad.enlighten With that in mind, it's not a case of someone just decided it shouldn't be there, we all said it should but they just told us to get rid of it'?, it's a case of no one actually designated anyone to work on an input method, or if they did, that work was never done. In my opinion, I have no idea why you'd ever want to manually enable/disable the input, unless some other design issue was causing this wish. To back me up, I'll point out that zero touch-screen phones have the ability to manually disable automatic input-method display. This is just my opinion though. There's no technical reason that makes this hard, however - the code for the multi-tap pad is very few lines and pretty simple stuff ( http://svn.o-hand.com/repos/misc/trunk/multitap-pad/src/multitap-pad-main.c ), instead of complaining about decisions being made that conflict with your wishes, you could focus that energy on writing a patch. If I were to write this patch, I'd suggest adding a boolean gconf key, something like '/desktop/poky/interface/auto_show_im' and add the necessary code in multitap-pad-main.c to listen to this key. This would require very few additions to the code (of course, adding some interface to configure this option and so on is another issue). Hope that helps explain a few things. --Chris p.s. Not having a button on the actual keypad to hide the pad was an oversight, however, that should probably be there...
Re: Automatic pop up kbd
On Fri, 16 May 2008 15:31:57 +0100 Chris Lord [EMAIL PROTECTED] babbled: thats not the issue, there is auto-bringup if a widget is focused. bring-down if no widget is focused. fair enough. that's good. saves a manual press somewhere, but now there is no manual bringup or pop-down anymore. this means: 1. any app that does NOT send messages to root will never be able to get keyboard input. every app now needs modification OR MUST use a modified toolkit. so existing apps like scummvm or other sdl games or machine emulators that also may know nothing about the state of the game and if it wants input or not, have no way to do this without adding manual controls to each and every app. 2. if it comes up because some entry widget HAPPENS to be focused, you have no way to pop it down. eg - qtopia's notes app for starters. the whole window is 1 big multi-line entry widget. if the window is focused, the entry is focused. that means the keyboard is ALWAYS up. if u want to scroll up and down and read a note, but not type, you are stuck with 50% of your screen being eaten up by a keyboard. like it or not. there is no choice. well ok - there is - specially modifying all apps that behave like this so that you need to add an edit button to enable/disable editing - now start adding that all over the place. it's really silly when you can have 1 unobtrusive universal location for a control that solves all these kind of cases. this removes functionality for a user. it does not let them decide anymore. they now have lost control. Hi all, On Fri, 2008-05-16 at 21:26 +1000, Carsten Haitzler wrote: On Fri, 16 May 2008 11:02:03 +0100 Andy Powell [EMAIL PROTECTED] babbled: On Friday 16 May 2008 10:46, Carsten Haitzler wrote: On Fri, 16 May 2008 10:33:13 +0100 Andy Powell [EMAIL PROTECTED] babbled: Please can you make it possible to switch this off and / or force the keyboard to hide. There's nothing worse than having an external keyboard connected and being forced to waste screen real estate on something you don;t need. design decision was made to remove manual control even though it has been there from the beginning. no can do. is that code for 'someone just decided it shouldn't be there, we all said it should but they just told us to get rid of it'? no comment :) I initially wrote the multitap-pad with no instruction or input from anyone (I'd noticed that no one had any interest in creating a sane input method for a phone and figured one would eventually be necessary): http://chrislord.net/blog/Software/multitap-pad.enlighten With that in mind, it's not a case of someone just decided it shouldn't be there, we all said it should but they just told us to get rid of it'?, it's a case of no one actually designated anyone to work on an input method, or if they did, that work was never done. In my opinion, I have no idea why you'd ever want to manually enable/disable the input, unless some other design issue was causing this wish. To back me up, I'll point out that zero touch-screen phones have the ability to manually disable automatic input-method display. This is just my opinion though. There's no technical reason that makes this hard, however - the code for the multi-tap pad is very few lines and pretty simple stuff ( http://svn.o-hand.com/repos/misc/trunk/multitap-pad/src/multitap-pad-main.c ), instead of complaining about decisions being made that conflict with your wishes, you could focus that energy on writing a patch. If I were to write this patch, I'd suggest adding a boolean gconf key, something like '/desktop/poky/interface/auto_show_im' and add the necessary code in multitap-pad-main.c to listen to this key. This would require very few additions to the code (of course, adding some interface to configure this option and so on is another issue). Hope that helps explain a few things. --Chris p.s. Not having a button on the actual keypad to hide the pad was an oversight, however, that should probably be there... -- Carsten Haitzler (The Rasterman) [EMAIL PROTECTED]
Re: Automatic pop up kbd
Subject: Re: Automatic pop up kbd On Fri, 16 May 2008 10:33:13 +0100 Andy Powell [EMAIL PROTECTED] babbled: On Friday 16 May 2008 08:53, Tick wrote: Hi Zecke, We are going to make the kbd show and hide automatically. snip Thanks. Tick Please can you make it possible to switch this off and / or force the keyboard to hide. There's nothing worse than having an external keyboard connected and being forced to waste screen real estate on something you don;t need. design decision was made to remove manual control even though it has been there from the beginning. no can do. -- Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] Could we get someone to forward the logic of this design decision? Not giving the user a way to turn something off that occupies 30% of the screen seems like, dare I say, a bad design decision. -- If it doesn't make you smile, you're doing something wrong.
Re: Automatic pop up kbd
On Friday 16 May 2008 12:26, Carsten Haitzler wrote: snip i just removed the button in the theme ui actually.. so it was a /* ... */ blob :) edje_decc illume.edc - find the qwerty button - remove the comments rebuild, plonk back into place. button is back. :) Mmmm... so if, for example, someone left it commented out in the ui, but accidentally left in, say, a dbus interface to the code behind it. -- Andy / ScaredyCat
Re: Automatic pop up kbd
On Friday 16 May 2008 15:31, Chris Lord wrote: Hi all, snip In my opinion, I have no idea why you'd ever want to manually enable/disable the input, unless some other design issue was causing this wish. To back me up, I'll point out that zero touch-screen phones have the ability to manually disable automatic input-method display. Then I guess you didn't actually read what I wrote then, here it is again: There's nothing worse than having an external keyboard connected and being forced to waste screen real estate on something you don;t need. It's also particularly annoying when a keyboard pops up on the first field of a screen covering up the actual field you wanted to fill out, unless the keypad provides tab navigation or something. snip ( http://svn.o-hand.com/repos/misc/trunk/multitap-pad/src/multitap-pad-main.c ), instead of complaining about decisions being made that conflict with your wishes, you could focus that energy on writing a patch. Actually, it was a request at first, it only became a complaint when choice was taken away. If I were to write this patch, I'd suggest adding a boolean gconf key, something like '/desktop/poky/interface/auto_show_im' and add the necessary code in multitap-pad-main.c to listen to this key. This would require very few additions to the code (of course, adding some interface to configure this option and so on is another issue). Yes, both of which are pretty trivial, but that wasn't the point I was making. Hope that helps explain a few things. It only explains that you seemed to think I was saying your keyboard was shit or something. We aren't even talking about your keyboard. Carsten has provided a mechanism we can use to fix his keyboard when it appears. -- Andy / ScaredyCat
Re: Automatic pop up kbd
On Sat, 2008-05-17 at 00:47 +1000, Carsten Haitzler wrote: On Fri, 16 May 2008 15:31:57 +0100 Chris Lord [EMAIL PROTECTED] babbled: thats not the issue, there is auto-bringup if a widget is focused. bring-down if no widget is focused. fair enough. that's good. saves a manual press somewhere, but now there is no manual bringup or pop-down anymore. this means: 1. any app that does NOT send messages to root will never be able to get keyboard input. every app now needs modification OR MUST use a modified toolkit. so existing apps like scummvm or other sdl games or machine emulators that also may know nothing about the state of the game and if it wants input or not, have no way to do this without adding manual controls to each and every app. So to reduce coding work, we want to add awkward/remove nice features? Case in point, maemo/hildon require a fair amount of changes to integrate correctly, but they went ahead with things all the same and the user experience is better for it. If apps don't integrate with the platform, those apps should be changed - sure, make allowances to make these changes easier, but in my opinion, crippling (sorry, this is too strong a word, but I couldn't think of a better one) the user experience isn't something you should do to support legacy applications. 2. if it comes up because some entry widget HAPPENS to be focused, you have no way to pop it down. eg - qtopia's notes app for starters. the whole window is 1 big multi-line entry widget. if the window is focused, the entry is focused. that means the keyboard is ALWAYS up. if u want to scroll up and down and read a note, but not type, you are stuck with 50% of your screen being eaten up by a keyboard. like it or not. there is no choice. well ok - there is - specially modifying all apps that behave like this so that you need to add an edit button to enable/disable editing - now start adding that all over the place. it's really silly when you can have 1 unobtrusive universal location for a control that solves all these kind of cases. You'll notice in the 'p.s.' at the end of my original mail that I thought not having a hide button on the pad was an oversight. this removes functionality for a user. it does not let them decide anymore. they now have lost control. There's such a thing as having too much control. I appreciate the power steering in my car, even if it removes an amount of control. --Chris Hi all, On Fri, 2008-05-16 at 21:26 +1000, Carsten Haitzler wrote: On Fri, 16 May 2008 11:02:03 +0100 Andy Powell [EMAIL PROTECTED] babbled: On Friday 16 May 2008 10:46, Carsten Haitzler wrote: On Fri, 16 May 2008 10:33:13 +0100 Andy Powell [EMAIL PROTECTED] babbled: Please can you make it possible to switch this off and / or force the keyboard to hide. There's nothing worse than having an external keyboard connected and being forced to waste screen real estate on something you don;t need. design decision was made to remove manual control even though it has been there from the beginning. no can do. is that code for 'someone just decided it shouldn't be there, we all said it should but they just told us to get rid of it'? no comment :) I initially wrote the multitap-pad with no instruction or input from anyone (I'd noticed that no one had any interest in creating a sane input method for a phone and figured one would eventually be necessary): http://chrislord.net/blog/Software/multitap-pad.enlighten With that in mind, it's not a case of someone just decided it shouldn't be there, we all said it should but they just told us to get rid of it'?, it's a case of no one actually designated anyone to work on an input method, or if they did, that work was never done. In my opinion, I have no idea why you'd ever want to manually enable/disable the input, unless some other design issue was causing this wish. To back me up, I'll point out that zero touch-screen phones have the ability to manually disable automatic input-method display. This is just my opinion though. There's no technical reason that makes this hard, however - the code for the multi-tap pad is very few lines and pretty simple stuff ( http://svn.o-hand.com/repos/misc/trunk/multitap-pad/src/multitap-pad-main.c ), instead of complaining about decisions being made that conflict with your wishes, you could focus that energy on writing a patch. If I were to write this patch, I'd suggest adding a boolean gconf key, something like '/desktop/poky/interface/auto_show_im' and add the necessary code in multitap-pad-main.c to listen to this key. This would require very few additions to the code (of course, adding some interface to configure this option and so on is another issue). Hope that helps explain a few things. --Chris p.s. Not having a button on the actual keypad to
Re: Automatic pop up kbd
On Fri, 16 May 2008 17:24:49 +0100 Chris Lord [EMAIL PROTECTED] babbled: There's nothing worse than having an external keyboard connected and being forced to waste screen real estate on something you don;t need. Sorry, I missed this - I agree. or any other situation you don't want it... :) It's also particularly annoying when a keyboard pops up on the first field of a screen covering up the actual field you wanted to fill out, unless the keypad provides tab navigation or something. The keyboard should only come up when the user explicitly selects an input entry - of course, this is up to the application to make sure it doesn't force the keyboard up by auto-focusing an entry. Or up to the toolkit that it doesn't fire off the X event when an entry isn't focused explicitly. Not the keyboard, anyway. yup, though in the case of a bug full-window text entry for a note application.. you're going to be pretty stuck for scrolling, selecting text for copy and paste etc., here. :) finger-scroll (drag finger up and down on text entry to scroll) is going to focus it in reality... Actually, it was a request at first, it only became a complaint when choice was taken away. Who took the choice away? (I'm not in charge of OpenMoko or what patches get accepted of course, so maybe someone did, but I've not been aware of this?) It only explains that you seemed to think I was saying your keyboard was shit or something. We aren't even talking about your keyboard. Carsten has provided a mechanism we can use to fix his keyboard when it appears. In fairness, it is pretty shit, it was only meant as a starting point and it's mostly just tying together other peoples' work with string and masking tape :) But it sounded to me like blame was being attributed when there was no one/thing at fault? i was the one who removed the buttons/widget/gadget that gives manual control. i did it because i was instructed to do so by management. if people have an issue with losing manual keyboard popup/down control there is the place to take it up. i am just relaying the facts as they stand. -- Carsten Haitzler (The Rasterman) [EMAIL PROTECTED]
Re: Automatic pop up kbd
On Fri, 16 May 2008 17:30:08 +0100 Chris Lord [EMAIL PROTECTED] babbled: On Sat, 2008-05-17 at 00:47 +1000, Carsten Haitzler wrote: On Fri, 16 May 2008 15:31:57 +0100 Chris Lord [EMAIL PROTECTED] babbled: thats not the issue, there is auto-bringup if a widget is focused. bring-down if no widget is focused. fair enough. that's good. saves a manual press somewhere, but now there is no manual bringup or pop-down anymore. this means: 1. any app that does NOT send messages to root will never be able to get keyboard input. every app now needs modification OR MUST use a modified toolkit. so existing apps like scummvm or other sdl games or machine emulators that also may know nothing about the state of the game and if it wants input or not, have no way to do this without adding manual controls to each and every app. So to reduce coding work, we want to add awkward/remove nice features? Case in point, maemo/hildon require a fair amount of changes to integrate correctly, but they went ahead with things all the same and the user experience is better for it. If apps don't integrate with the platform, those apps should be changed - sure, make allowances to make these changes easier, but in my opinion, crippling (sorry, this is too strong a word, but I couldn't think of a better one) the user experience isn't something you should do to support legacy applications. you remove manual controls once all automatic controls are working everywhere. you don't remove them and then think about oh - we haven't got automatic controls done yet. removing the control didn't buy anything but removal of a button in an area already blank and allocated as empty space. we could argue validly it might be better hidden further away and not in plain sight - but total removal is silly. and i disagree with your assessment of hildon. forcing changes on apps when not needed is bad. it creates work where non is actually needed. if removing the control bought something in return it'd be a weight up of a balance of positive vs negative result. as it stands it bought nothing (beyond possibly not confusing people - but hell. that's the least concern. i challenge people to wonder how to out in a return or a space... or change layouts! behavior has been mostly imitated from the qtopia predictive keyboard, but this is what was requested, so an obvious keyboard button now is gone and instead you need to know that swiping your finger to the right enters a space and goes to the next word... know that wipe-to-left is backspace. nothing on screen hints or tells you this, so u'd better read the documentation). 2. if it comes up because some entry widget HAPPENS to be focused, you have no way to pop it down. eg - qtopia's notes app for starters. the whole window is 1 big multi-line entry widget. if the window is focused, the entry is focused. that means the keyboard is ALWAYS up. if u want to scroll up and down and read a note, but not type, you are stuck with 50% of your screen being eaten up by a keyboard. like it or not. there is no choice. well ok - there is - specially modifying all apps that behave like this so that you need to add an edit button to enable/disable editing - now start adding that all over the place. it's really silly when you can have 1 unobtrusive universal location for a control that solves all these kind of cases. You'll notice in the 'p.s.' at the end of my original mail that I thought not having a hide button on the pad was an oversight. as there was already a show/hide button, on the top-left of the screen this was unnecessary and left more room for word corrections/completions. this removes functionality for a user. it does not let them decide anymore. they now have lost control. There's such a thing as having too much control. I appreciate the power steering in my car, even if it removes an amount of control. and an automatic car STILL provides manual gears you can shift - not just D but 3, 2 and 1 for when the auto just won't guess right. as it stands this is the same as a gearbox with only D. :) --Chris Hi all, On Fri, 2008-05-16 at 21:26 +1000, Carsten Haitzler wrote: On Fri, 16 May 2008 11:02:03 +0100 Andy Powell [EMAIL PROTECTED] babbled: On Friday 16 May 2008 10:46, Carsten Haitzler wrote: On Fri, 16 May 2008 10:33:13 +0100 Andy Powell [EMAIL PROTECTED] babbled: Please can you make it possible to switch this off and / or force the keyboard to hide. There's nothing worse than having an external keyboard connected and being forced to waste screen real estate on something you don;t need. design decision was made to remove manual control even though it has been there from the beginning. no can do. is that code for 'someone just decided it shouldn't be there, we all said it should but they just told us to get rid of
