Re: illume keyboard button (was Openmoko on Design)
On Wed, 30 Jul 2008 15:01:52 +0200 Andreas Bogk <[EMAIL PROTECTED]> babbled: as its just a button provided by the theme - the theme determines if the ui element is there or not - the code will still respond to the signal from the theme saying 'someone pressed the keyboard toggle". the idea here is that now the designer can decide if the button is there or not, where it is, how it looks, how you interact with it etc. - and the designers have spoken that it is not to be there. it is up to you to provide a package of your own that changes this. otherwise you;ll just have to wait until i get to changing how it works. > Dear community and OM Powers That Be, > > I have read the "Openmoko on Design" thread with a certain alienation. > I'll try to resist the temptation to pick up one of the many flame > baits, but even after sleeping it over for a night, I feel inclined to > comment on the issue here. > > First, I think that the complaints of users about "the phone should know > when it expects keyboard input, and automatically bring up the keyboard" > are right. The work going into this direction is correct. > > However, there are situations when a manual override is needed. The > automatic detection could be wrong, for instance. But much more > important: the user could be in a situation where keyboard input is > theoretically possible, but not currently desired, because the keyboard > is taking away screen real estate. This happened to me yesterday, when > I was sitting in the train, and reading some code using the terminal > application. > > So, in my opinion, the decision to remove the button is incorrect. Even > more so, the strong reaction of the users should have been an indication > that the decision was incorrect. It's always a good idea to listen to > your users. > > It has been said that, since OpenMoko is an open project, the community > has the chance to come up with a different solution. Now let's take a > look at what the community (read: folks who actually write code instead > of participating in lengthy discussions) did, the day the button was > removed from illume: > > http://gitweb.openembedded.net/?p=org.openembedded.dev.git;a=blob;f=packages/openmoko-projects/illume/configure-keyboard.patch;h=589fe53f38afc59be95a13ed67a9f9d1fc452148;hb=HEAD > > They re-enabled the feature in their branch, and went on with their > life. However, the patch stopped applying this morning, and I had to > lock down illume to r170. > > Raster: if you could make the keyboard button a configuration option, as > in the above patch, you'd make me and a couple of other people happy. > Thanks in advance. > > Andreas > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community -- Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]> ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: illume keyboard button (was Openmoko on Design)
On Wednesday 30 July 2008 15:01:52 Andreas Bogk wrote: > http://gitweb.openembedded.net/?p=org.openembedded.dev.git;a=blob;f=package >s/openmoko-projects/illume/configure-keyboard.patch;h=589fe53f38afc59be95a13 >ed67a9f9d1fc452148;hb=HEAD > > They re-enabled the feature in their branch, and went on with their > life. However, the patch stopped applying this morning, and I had to > lock down illume to r170. Hey Andreas, you actually want to have a different illume.edj file. So the fso guys created one[1] and use that. It is on the distro team's todolist to make it possible to easily replace (update-alternative) the illume.edj file with other versions (installable through the installer). Personally I hope people will be more creative than just adding a qwertz button and will play with edje to try other things as well. About the patch you posted. The sad truth is that X/freedesktop.org lacks a way to identify virtual inputmethods and this means we have no way to find out which apps might be able to send key events, let alone switching between these... So for ASU we can only instantiate one virtual keyboard and we decided to use the Qtopia keyboard. So what my patch for fso did was to make that "#if 0" compile time configurable. It was not applied upstream as raster wanted to make it runtime configurable and the patch doesn't apply anymore as this has happened. For post ASU we want to propose E_VIRTUAL_KEYBOARD_STATE (probably _NETWM_...) to freedesktop.org and want to establish the means to find out which keyboard implementations are available... i hope this helps z. [1] http://gitweb.openembedded.net/?p=org.openembedded.dev.git;a=blob_plain;f=packages/freesmartphone/illume-theme-freesmartphone_git.bb;hb=HEAD ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
illume keyboard button (was Openmoko on Design)
Dear community and OM Powers That Be, I have read the "Openmoko on Design" thread with a certain alienation. I'll try to resist the temptation to pick up one of the many flame baits, but even after sleeping it over for a night, I feel inclined to comment on the issue here. First, I think that the complaints of users about "the phone should know when it expects keyboard input, and automatically bring up the keyboard" are right. The work going into this direction is correct. However, there are situations when a manual override is needed. The automatic detection could be wrong, for instance. But much more important: the user could be in a situation where keyboard input is theoretically possible, but not currently desired, because the keyboard is taking away screen real estate. This happened to me yesterday, when I was sitting in the train, and reading some code using the terminal application. So, in my opinion, the decision to remove the button is incorrect. Even more so, the strong reaction of the users should have been an indication that the decision was incorrect. It's always a good idea to listen to your users. It has been said that, since OpenMoko is an open project, the community has the chance to come up with a different solution. Now let's take a look at what the community (read: folks who actually write code instead of participating in lengthy discussions) did, the day the button was removed from illume: http://gitweb.openembedded.net/?p=org.openembedded.dev.git;a=blob;f=packages/openmoko-projects/illume/configure-keyboard.patch;h=589fe53f38afc59be95a13ed67a9f9d1fc452148;hb=HEAD They re-enabled the feature in their branch, and went on with their life. However, the patch stopped applying this morning, and I had to lock down illume to r170. Raster: if you could make the keyboard button a configuration option, as in the above patch, you'd make me and a couple of other people happy. Thanks in advance. Andreas ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
