Re: OpenMoko application as Final Year Project
On Fri, 2007-09-28 at 10:42 +0100, Thomas Wood wrote: On Thu, 2007-09-27 at 17:56 +0100, Sebastian wrote: Hi everybody! I'm a student from Germany doing my last year in England, Staffordshire University. To finish my studies I have to do a project, that has not done before, and of course I have to do it on my own. So when I stumbled across OpenMoko I thought it would be a great idea to write a application for it. It's a little bit different for me to work out an good idea so I'm asking you if anyone has got an idea what kind of application would be a must-have or a pretty nice one for a OpenMoko phone, but is not jet implemented. thx and have a nice day, You really need to find something that will interest yourself, not something that is suggested by anyone else. Take a look in the subversion repository to see what is already implemented. Regards, Thomas On the other hand, if input methods interest you, openmoko could really do with a fairly quick and novel input method (People tell me T9 is patent-encumbered, which is why I use the word 'novel'). There's plenty of research and things to write about for such a project and it could be applied outside of openmoko too. --Chris
Re: [PATCH-RFC] openmoko-contacts: phonebook import
On Tue, 2008-03-04 at 18:11 +0800, Chia-I Wu wrote: Hi Chris, This patch adds support for phonebook import from the SIM card. The import process is manual. I add a toolbar button to the details page for it. Ideally, we don't need a button. The import process should be automatic, and happen before the UI (in phonekit?). But to go automatic, openmoko-contacts needs to be at least phonebook-aware first. Otherwise, confusions arise, as discussed in this thread, http://lists.openmoko.org/pipermail/openmoko-devel/2008-February/002014.html The place I chose for the import button is also, well, quite random. A better place (and a better icon) for the button might be needed. Nice work (although patch isn't attached, apparently :)) - I'd suggest that this be made into a small stand-alone utility application though. Having an extra button that you'll likely only want to use once, if ever, seems overkill. Even better would be an addition to phone-kit to synchronise phonebook entries with EBook entries - this could be done by setting a custom property, say X-MOKO-PBENTRY, that contains a reference to the phonebook entry, then checking for this property on the contacts-modified/contacts-removed signals and synchronising accordingly. phone-kit would need to check through all contacts on start-up to see which SIM contacts have EBook partners, and add/alter/remove when there is any inconsistency. This could just be done in contacts as well of course, but phone-kit is always running and other clients may have reason to change contact details. I suggest whatever you do, you file a bug about this ,if there isn't already one, and attach this and any future patches. Regards, --Chris
Re: Usability Review of OpenMoko GTK+ Applications
On Thu, 2008-03-13 at 10:17 -0700, Shawn Rutledge wrote: On Thu, Mar 13, 2008 at 8:20 AM, Esben Damgaard [EMAIL PROTECTED] wrote: But for some more hardcore stuff: You shouldn't have to close programs. This is not good usability. Instead give the option, but if we run out of ram, the OS should close the oldest program. But then a program should be able to say to the OS that the program is meant to be running for a long time.. Or maybe this is a bad idea.. I suggested that a long time ago: the important thing is not closing the current app, but getting back to the main menu. It should work more like PalmOS, because the user doesn't usually care in what state the current app is, he only cares which one he's going to run next. I think most of us have agreed that this is definitely the way to go, but until someone steps up and writes (or ports from Maemo) some kind of power policy manager, this isn't feasible. As time/resources are finite things, it would be good to have a reasonable interim solution than to just mark this as 'future' and forget about it. --Chris
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 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
