I'm having a problem when trying to run the latest head revision on Android (2.2).
The build is from yesterday, but I don't think any meanwhile commit may have fixed this. The problem was already present in a build from Tuesday.
When I press the menu hardkey in GpsMid, the menu doesn't open - nothing happens.
I should note that I am using the standard menus, not the icon menus - maybe you both, jkpj and sk750, only use the icon menus?
The console output when I press the menu key is as follows (this is actually output twice):
08-18 00:44:50.710 18498 18498 W KeyCharacterMap: Can't open keycharmap file
08-18 00:44:50.710 18498 18498 W KeyCharacterMap: Error loading keycharmap file '/system/usr/keychars/qtouch-touchscreen.kcm.bin'. hw.keyboards.65539.devname='qtouch-touchscreen'
08-18 00:44:50.717 18498 18498 W KeyCharacterMap: Using default keymap: /system/usr/keychars/qwerty.kcm.bin
Searching for "KeyCharacterMap" in GpsMid (including the build dir) shows two classes inside de.enough.polish.android.lcdui which have members of this class type.
Searching for "Error loading keycharmap" on the Internet shows threads saying either that this was only a warning and no problem or that it came because hard coded strings were used (?). Whatever it is, J2MEPolish ought to encapsulate this I'd say.
I'm using J2MEPolish 2.3.
So, a few questions:
1) Do you also get these messages when pressing the menu key?
2) Do standard menus work for you?
3) Any idea what might be the problem? Any recently introduced changes for the Android build process which I need to take care of?
P.S.: Haven't yet checked if the J2ME build from the same source works on the W800. But I don't believe this will have problems.
just checked that on Nokia 5800 (no Android yet) and almost got despaired because after switching to normal menus I found no possibility to open the menu again because the Nokia 5800 has no key mapped to menu in GpsMid.
Then I remembered that when in fullscreen mode there are no menu entries attached to the Canvas (a relict from SE K750i or C702 times that required this to be really fullscreen ).
So I touched the scale bar and turned off full screen mode and could get to Setup and switch on the icon menus again.
Maybe this helps on Android as well when you run GpsMid in fullscreen mode.
"I should note that I am using the standard menus, not the icon menus - maybe you both, jkpj and sk750, only use the icon menus?"
I usually use the icon menu, yes - I've tested the J2ME Polish menu (If I understand correctly that can't really be said to be a standard menu on Android as it's quite unline the normal Android UI conventions), but it's been a long time since the last test. I actually kind of liked the old-fashioned J2ME command menu's plain style, though it was slower to see where the needed function was.
GpsMid UI code is quite complicated - for many functions, we have at least four separate ways of getting to: the J2ME "Commands" menu (the standard menu on J2ME), keyboard shortcuts, touchscreen shortcuts, the icon menu (and maybe a couple of ways via the icon menu). Then we have a big bunch of options which modify the UI, one example being "optimize for routing". For settings forms and functions like waypoint entering we have a) J2MEPolish forms with J2MEPolish elements b) J2MEPolish with Android native elements c) Android native views. I'm all for flexibility and user choice, but as we don't have a regression test suite, the UI choice is somewhat too much for the current amount of testing&development.
To make Android users feel at home, things will probably get even more complicated - a fifth and sixth category probably will appear - fifth being bigger, moving on-map elements for UI (like the zoom etc. buttons but more lively), and sixth being pop-up menus on top of map asking for options. (Android native alerts or toasts as they're called there are kind of one example of these already).
Plus there's split screen support - GpsMid should have a proper WindowManagement system for this to take away complexity from UI coding.
Also I would like to drop what we can, this would be the native menus for me but it still seems some users do use them.
If we could hardcode "optimize for routing" instead of having it optional, this would be great as well. Any objections we do this after the release?
I have the opposite problem - I disabled the icon menu, and now I'm in the command menu (settings), but I can't find a way to get back to the map :-)
Wait, now I found it - it was "menu" and "back". (the back key didn't work)
And yes, now on the map I can confirm that there's a problem with getting to the command menu. At first, I didn't get to the command menu with the menu key. Then I pressed '*', then pressed back to cancel saving waypoint. Now pressing the menu key opens the command menu, and functions seem to work.
Can't see any KeyCharMap messages in adb logcat though, and to me the messages you quote don't seem like GpsMid output at all but the usual Android self-babbling it does all the time. Android seems to be quite talkative, much unlike the tradition of the Unix OS family it runs on.
"Plus there's split screen support - GpsMid should have a proper WindowManagement system for this to take away complexity from UI coding."
Yes, I tried to start paving the way for this with the changes to fix the problem Karel was seeing. I've also been meaning to add a feature request for a mouse cursor on keyboard-only phones. Could do some nostalgic 1980's-style windowing on the keyboard-only J2ME-phones :-) But not barely for the nostalgic value, for some functions the mouse cursor could be useful so the touch shortcuts could be used also on touch-touch phones in the familiar places, for people who use both touch phones and keyboard phones.
"Also I would like to drop what we can, this would be the native menus for me but it still seems some users do use them."
One thing I've been meaning is to put a feature request for is to speed up the icon menus.
E.g. on the Galaxy Note they feel too slow. Might be we should have smaller-size icons than huge, but then again I don't feel the icon menu to be so slow to respond on the Galaxy Mini, and on the Note the size makes a difference also in picture quality
One point probably is that the Note perhaps has a bad CPU power / pixel amount balance much like the Nokia E70 had, too little bang to move all those pixels in all situations. But could still look for possible improvement to make with the icon menu, I've seen this reported also for other devices.
For keyboard-only phones, the command menu seems well worth keeping to me, though I mostly use the icon menu on those, too. For Android though, I'd be willing to drop it from the default build and classify as much less important than other UI approaches.
> One thing I've been meaning is to put a feature request for is to speed up the icon menus.
Well, what I'd like for the icon menus to have them load/scale the icons in the background - just like a web browser it would show place holders for unloaded icons. But if there's anything else we can do to improve performance of icon menus this would be great as well.
One thing to do for example is to check if there are multiple sizeChanged() calls when opening the icon menu as this would cause the icon menu to load and scale multiple times before opening.
"If we could hardcode "optimize for routing" instead of having it optional, this would be great as well. Any objections we do this after the release?"
I'm for dropping it. Though have to say I never really bothering to find out the details of what it changed, apparently something to with if the default choose action is for selecting as destination (or showing) or routing to.
Actually I propose we hardcode "optimize for routing" before release, that'll get rid of one bug also. Objections?
" I usually use the icon menu, yes - I've tested the J2ME Polish menu (If I understand correctly that can't really be said to be a standard menu on Android as it's quite unline the normal Android UI conventions)"
Actually, I have to retract this - it's not unlike the normal Android UI conventions, appears that applications do use the menu style too. One of them is the default GUI shell on the Galaxy Note. So, I'll also withdraw my proposal of dropping the command / textual menu from Android default builds.
Which bug would hardcoding optimize for routing save? I'm not aware of any bug there.
Don't remember right no, but I mentioned it in a tracker related to the GuiSearch issue you had with the 5800. Now I remember, it's that the if the option is off, routing virtual kb button will go to destination in addition of routing to it. (Unless you fixed it already).
The trick/workaround with the waypoint menu helps.
What doesn't help is opening and closing search, after this, the menu still won't come. This is what I had tried before writing my message. (Thought I'd tried waypoints too, but obviously I haven't.)
Thanks for your replies.
Anybody have an idea which code change might be causing this? Unfortunately, I didn't update GpsMid for several weeks, so I can only say that it still worked with a version from April 30th.
I completely agree that we have a lot of UI combinations and that testing and maintaining them is not easy.
Maybe writing separate UIs for J2ME and Android will help to make things easier to understand again and maybe Jochen's work is going to push this forward.
There is still going to be the overhead of writing and testing two or actually three UIs though.
I have never been a big friend of the icon menus, you all know that, so I'd really like to keep the standard menus.
(I think we should call them just that, as they are created with the plain LCDUI API for building menus.)
Please kind in mind that Jochen's work will use standard Android APIs for menus to ensure they are barrier-free which is a primary requirement for his thesis. So if we decided to go for icon menus only in the future, we'd close the door for the possibility to incorporate more native Android menus (naturally).
One big reason though why I didn't/couldn't use the icon menu was performance: It simply didn't draw on the first try on my W800, and even on my Defy it opens quite slowly.
Second reason is that I don't like reinventing the wheel, so if there is a library for menus then why write a new one. I don't deny though that there were good reasons to want something better than LCDUI menus.
On Android you can make the standard menus look good by putting an icon next to the text if I'm not completely wrong.
Third reason was probably personal, I found it harder to find the entries I'm looking for in the icon menu as some of them are in unexpected places and/or named differently.
At the end of the day, I think this poses the question for which platform(s) we want to develop.
If we want to keep supporting slow phones such as my W800 in which icon menus don't work properly, we need to keep the LCDUI menus and can't make icon menus the only menu choice on J2ME.
If we want a better UI on Android than what Polish can offer, we need to keep implementing parts or all of our UI using native Android APIs. (I clearly want this better UI because being limited to J2ME capabilities, which also Polish doesn't always port well to Android, brings too many shortcomings.)
> At the end of the day, I think this poses the question for which platform(s) we want to develop.
Certainly some time in the future the day will come when we will stop maintaining / freeze the j2me code in a separate branch and introduce new features only for Android.
"The trick/workaround with the waypoint menu helps. What doesn't help is opening and closing search, after this, the menu still won't come. This is what I had tried before writing my message. Anybody have an idea which code change might be causing this? Unfortunately, I didn't update GpsMid for several weeks, so I can only say that it still worked with a version from April 30th. "
Good news is I have an idea of roughly what this, bad news is I don't know exactly how to fix it.
It's something which has to do with two "modes" of how GpsMid works on Android, probably something to do with that in one mode, J2MEPolish handles the menu & back keys (or mainly the back key), while in the other mode, they're handled Android-natively.
In Android native mode, something like this: if we register a handler, we get callbacks for the back key, and can handle them. If we don't register a handler, back key will do something Android, maybe put the activity away from the front, ending up so user can't access GpsMid, it's stuffed away. A few of those bugs have been fixed, some may remain.
Currently it seems there's some uncontrolled movement between the two modes. When using some Android native views (like in waypoint saving form), even if in a J2MEPolis form (like the waypoint saving) apparently we enter the Android native mode.
I've tried to make menu key handled the same way in both modes, and until now seemed to working pretty well. But of course to get into the root of this and to avoid bugs in advance, would need to properly find out how to control the different modes, and explicitly switch the modes instead of trying to cope with mode switches not anticipated.
"Certainly some time in the future the day will come when we will stop maintaining / freeze the j2me code in a separate branch and introduce new features only for Android."
My Nokia E72 has started to literally fall apart, so I'm not sure what my portable J2ME device will soon be if any. Perhaps I'll buy a second hand one, going rate seems to be ca. €40 - €100 on a net.auction, someone sold a "Brand new and Boxed" for €107.
Seems I might get my WinCE device back into active duty with the cigarette light power adapter and a mini-USB cable, so looks like that's at least one J2ME platform I'll be using. So no desire to kill the J2ME in me quite yet, quite vice versa, as Android is a very battery-hungry beast.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.