Some suggestions

karel
2012-08-14
2013-05-29
1 2 > >> (Page 1 of 2)
  • karel
    karel
    2012-08-14

    Hi,
    below are some suggestions/bugfixes/feature requests that I collected during using GpsMid. May be some of them help you to improve GpsMid before release.

    1) Big on-left-corner navigation icons on map screen are partly covered by gui buttons on 320x480 display. Is it possible to change their position to right-top corner under GPS-related info? May be the position could be optional.

    2) Left map screen gui buttons are off-screen in landscape mode on 480x320 display. I remember that the layout of this buttons changed from 4x1 to 2x2 and vice versa during screen rotations. But it does not anymore. Or am I wrong? Status bar is off-screen too. For me it is not important, I use portrait mode most of time.

    3) Some (a little bit long) time ago I encountered a "division by zero" problem in pointerPressed() method in GuiSearch.java. According to pointerReleased() method I added the (fontSize == 0) condition at the begining of the pointerPressed() method. The same condition should be IMHO added to the autoPointerRelease() too.

    4) "Filesystem: " substring removal in GuiDiscover.java (lines 1045 and 1347) should not IMHO depend on trailing space of "Filesystem: " string (using …url.indexOf(":") + 2). It would be better to use url = url.substring(Locale.get("guidiscover.Filesystem").length());

    5) tileReader was null in some casses during displaying the number of not yet loaded tiles. It caused errors. I changed the antecedent condition in paint() method of Trace class to:

    if (tileReader != null && tileReader.getRequestQueueSize() != 0) {
    

    6) Field description "Seconds the examined route path gets delayed at traffic signals during calculation" is a bit misleading. The entered value is in fact multiplied by 10.

    7) I use diferrent colors of priorRouteLine in Osm2GpsMid/resources/colors.inc. The original one is very similar to forest color and the passed route becomes invisible. I use

        <color of="priorRouteLine" is="00008080"/>
        <color of="priorRouteLine_border" is="0042A8A8"/>
    

    8) I had a problem with sound instructions. It's an Android 2.x.x(?) MediaPlayer issue. End of each sound is cut off. Has anyone of you encountered similar problem? I found a (ugly) solution to wait for some time in cleanPlayer method before new sound instruction is played.

    private synchronized void cleanPlayer() {
        if (sPlayer != null) {
            try {
                Thread.sleep(200);
            } catch (InterruptedException e) {
                // TODO Auto-generated catch block
                e.printStackTrace();
            }
            sPlayer.release();
        }
        sPlayer = null;
    }
    

    9) Just a notice - not compressed mp3 sounds bundled into map-zip(jar) work. I use separate GpsMid.apk and separate map-zip(jar) with bundled mp3s created by Osm2GpsMid

    10) I would like to attach some files (Czech sound instructions package, messages_cs.txt, syntax.cfg and Osm2GpsMid Translations_cs.properties), but how can I achieve this? Where can I post these files?

     
  • sk750
    sk750
    2012-08-14

    Probably many good points, just 6) is probably wrong as IIRC this value will be used as addition to the connection durations which are stored in 1/10 (or is it 1/5) seconds.

    I think 3), 4), 5), 8) should go into the release.

    1) if there's a good solution should go to the release.
    Below the GPS status other statuses like recorded track points might conflict however.

    2) sounds like an error with sizeChanged() and/or determining whether it's portrait or landscape layout.

    7) did not check the color but IMHO a too late change for the release
    as there might be other color conflicts. Would be same as changing color of track points
    now, which are hardly visible when on the water.

    9) mp3 should be added to dontCompress by default for the release.

    10) post them at patches section

     
  • karel
    karel
    2012-08-14

    1) > Below the GPS status other statuses like recorded track points might conflict however.
    Oh, you are right. I'havent realised it.

    2) I'll try to look into it deeper.

    6) OK. The default value '5' confused me a little bit. It seems to me very low. Then I noticed the code

    int trafficSignalCalcDelayTSecs = Configuration.getTrafficSignalCalcDelay() * 10;
    

    in Routing class.

    7) It's a little bit darker color than the original route color.

    8) I would be careful with applying this patch. I was rather asking, wheather anyone of you has encountered the same problem.

    10) OK, I'll try tomorrow.

     
  • sk750
    sk750
    2012-08-14

    8) Don't own an Android device but I've tested some and all played the instructions much too fast. Might be too fast on Android because the sounds include no pause at the end end thus play to fast on Android.

    If things sound better with 8) either we should have a pause.wav/amr/mp3 with silence or some other solution to get the pause between the words on Android. But I agree the sleep() in the player event is probably no good idea and if used at least should be used only for Android as on J2ME there are rather too long pauses between sounds.

     
  • Jyrki Kuoppala
    Jyrki Kuoppala
    2012-08-14

    Thanks, this is a good list to go through.

    "8) I had a problem with sound instructions. It's an Android 2.x.x(?) MediaPlayer issue. End of each sound is cut off. Has anyone of you encountered similar problem? I found a (ugly) solution to wait for some time in cleanPlayer method before new sound instruction is played."

    Yes, I've seen this, and I think there was also a tracker about this. I thought it was cured, but maybe not, could be it doesn't appear to me as I use recorded sounds which probably have some empty space at end. I think however I tried it with stock Finnish sounds too and didn't have the issue.

    At the time I looked closely at the code and couldn't find anything wrong.

    Retesting now with Finnish stock sounds on Galaxy Note with ICS. No problem with sounds. Tested also with stock English & German sounds, don't hear a problem. I use .wav sounds, maybe this depends on sound format? Then again, I think I've used wav sounds always on Android.

    So, maybe it's related to Android version. Would be good to find a way to know which version(s), and check at run-time, so an unnecessarily delay won't be there for devices which don't need it.

     
  • Jyrki Kuoppala
    Jyrki Kuoppala
    2012-08-14

    1,2) I have an Android device with this resolution which I can use for testing, I'll look on the issues with it

    3) done

    9) done, is now in dontCompress

     
  • Jyrki Kuoppala
    Jyrki Kuoppala
    2012-08-14

    5) done

     
  • sk750
    sk750
    2012-08-14

    > 7) probably the route line has no border under Android?

     
  • Jyrki Kuoppala
    Jyrki Kuoppala
    2012-08-14

    4) done

     
  • Jyrki Kuoppala
    Jyrki Kuoppala
    2012-08-14

    "8) Don't own an Android device but I've tested some and all played the instructions much too fast. Might be too fast on Android because the sounds include no pause at the end end thus play to fast on Android."

    I don't have this experience, rather I've sometimes wanted to have faster instructions. But then, I use festival-generated and recorded sounds where the tempo is much lower than with the synth used for English and German. Those sound bring Kraftwerk to my mind. Might be also that the English and German sounds are cut much tighter than the Finnish festival-produced sounds, IIRC at one time ends were cut from English & German sounds but not Finnish, though not too sure about this.

    Found the old ticket for end of sounds cut, it's https://sourceforge.net/tracker/?func=detail&aid=3158454&group_id=192084&atid=939974

    it says: "I haven't noticed this since J2MEPolish 2.3 (on Samsung Galaxy Note
    w/Android 2.3.6)"

    However it's possible the above note is based on using recorded sounds with probably more silence at end than in the English & German sounds.

     
  • sk750
    sk750
    2012-08-14

    8) Probably. eSpeak sounds are explicitely produced without pause at the end of the output.

     
  • Jyrki Kuoppala
    Jyrki Kuoppala
    2012-08-14

    "> 7) probably the route line has no border under Android?"

    No borders is the default on Android, but I haven't paid attention if this applies to the route line. Looking at the code in Way.java, looks like route line always has borders, even if no street borders setting is on. On the other hand, looking at the map, I don't see borders in the route line even with borders turned on at setup. Same with microemulator.

     
  • Jyrki Kuoppala
    Jyrki Kuoppala
    2012-08-14

    "1) Big on-left-corner navigation icons on map screen are partly covered by gui buttons on 320x480 display. Is it possible to change their position to right-top corner under GPS-related info? May be the position could be optional."

    I can't repeat this with the Samsung Galaxy Mini's display in portrait or landscape mode, not even highlighed. Except in portrait mode, highlighed left-hand controls are a slight bit over the second arrow's text. On landscape mode 480x320, the left-corner arrows are relatively small, tough.

    "2) Left map screen gui buttons are off-screen in landscape mode on 480x320 display. I remember that the layout of this buttons changed from 4x1 to 2x2 and vice versa during screen rotations. But it does not anymore. Or am I wrong? Status bar is off-screen too. For me it is not important, I use portrait mode most of time."

    I think it still changes to 2x2 in some situations, but can't say when. On the Galaxy Mini, it's 4 x 1 in both modes, and does show on the screen.

    Checking also with full-screen mode - OK, with portrait there's slight overlap (a few pixels) which makes the second arrow's text hard to read occasionally. With single tap pressed, a control mostly overlaps the second arrow.

    In non-full-screen mode, the arrows are moved to right of the leftmost column, which mostly avoids overlap, but not completely when highlighted. In full screen mode, the arrows are very near the left border.

    On microemulator with 320 * 480 resultion, in landscape mode the control grid is 2*2, and arrows are next to each other, not on top of each other. A few pixels overlap when highlighted, not otherwise. In portrait mode, the arrows are near the left border, overlap of half the second arrow when highlighted, not otherwise.

     
  • Jyrki Kuoppala
    Jyrki Kuoppala
    2012-08-14

    So, to summarize, I couldn't repeat your issues, and while changes are needed it's a bit difficult now to know how to progress. One option is to base decisions e.g. for on screen size, but fact that font size varies also has to be taken into account. Maybe decide the 2x2 constellation based on screensize.

     
  • sk750
    sk750
    2012-08-14

    > "Status bar is off-screen too."

    Wonder what this means. Maybe sizeChanged() is not handled at all now? Did we have changes recently there?

     
  • karel
    karel
    2012-08-15

    1) I'm very sorry, it's my fault. I used a patched TraceLayout with bigOnScreenButtons set always true, because standard layout seemed too tiny to me. It behaved the same as standard highlighted (after single tap on screen) layout. Once again, I apologise.

    2) I't might be the combination of my phone, J2ME Polish, Android SDK Emulator… Anyway, screen rotations do not work correctly for me even from current git. I use fullscreen mode. After start of GpsMid, everything is absolutely OK. Even after start in landscape mode, the onscreen buttons layout is 2x2. But after screen rotation, the layout breaks. It seems like sizeChanged() is not called or something like that. It's like GpsMid does not know the new screen height. Width seems OK, but it might be due to overscanning(?).

    If I start GpsMid in portrait mode and then change to landscape mode, onscreen buttons stay still on the same y-axis position (from landscape top left corner) in 4x1 layout and status bar is off the screen (too low "under" the screen bottom).

    If I start GpsMid in landscape mode, everything is OK, onscreen buttons layout is 2x2. If I change the orientation to portrait, onscreen buttons layout changes to 4x1, but the map height remains still the same as in landscape mode. Status bar is located in 2/3 of the screen and bottom part (about 1/3 of the screen) is black.

    Android SDK Emulator behaves even more weird, only first orientation change is detected and after that any other orientation change leaves the screen intact. This is the output from ddms (Android debug tool):

    Step 1. After start (in portrait mode):
    log: Size of Canvas changed to 320|480 (! but I don't change orientation here manually !)
    log: Painting map took 611 ms 396/594

    Step 2. Orientation changed (to landscape mode)
    log: Size of Canvas changed to 480|320
    log: Painting map took 589 ms 594/594 (! weird size !)

    Step 3. Orientation changed (back to portrait mode)
    nothing interresting in log

    If you don't have this issue, never mind, I can live with that since I do not change the orientation frequently.

    7) Route line "in front of me" has a border (but the first element of the line loose the border sometimes). Even if street borders are turned off in settings. It looks good to me. The route line with a border is more highlighted than without the border. But route line "behind me" (passed) has no (visible) border. And it has almost the same color as forests have. That makes the passed route line invisible in forests.

    8) I'll try different sounds (with some silence at the end) and report results.

    10) I'll post the files to patches section.

     
  • Jyrki Kuoppala
    Jyrki Kuoppala
    2012-08-15

    "1) Big on-left-corner navigation icons on map screen are partly covered by gui buttons on 320x480 display. Is it possible to change their position to right-top corner under GPS-related info? May be the position could be optional."

    Can you provide a screenshot for this? It would help crafting a fix.

    As for 2), probably something related to not recognizing portrait/landscape switch properly like sk750 said. If you go to icon menu and select Tracks, you should see 4 rows and 3 columns in portrait mode. When turning to landscape mode, does this switch to 4 columns and 3 rows for you properly?

     
  • karel
    karel
    2012-08-15

    Please do not spend your time on 1), it was my fault, I used patched TraceLayout. I apologise a lot for that.

     
  • Jyrki Kuoppala
    Jyrki Kuoppala
    2012-08-15

    As for 2), I think I may have found it and if so it's my bad. Refactoring TraceLayout to separate layoutIsPortrait() didn't go quite as intended:

    public TraceLayout(int minX, int minY, int maxX, int maxY) {


    createLayout(layoutIsPortrait());

    validate();
    }

    public boolean layoutIsPortrait() {
    return ( maxX - minX < (maxY - minY) * 3 / 2 );
    }

    .. if I get this right, this leads to maxX & co. coming from LayoutManager instead of from the constructor. Though the super() call should set those in LayoutManager and this should work as before, hmm. Maybe worth trying the old form (below) anyway.

    -               if ( maxX - minX < (maxY - minY) * 3 / 2 ) {
    -                       // portrait layout
    -                       createLayout(true);
    -               } else {
    -                       // landscape layout
    -                       createLayout(false);
    -               }

     
  • Jyrki Kuoppala
    Jyrki Kuoppala
    2012-08-15

    1) OK, no problem; there are minor issues with the layout still, but perhaps then we won't try to tweak it right before release.

     
  • Jyrki Kuoppala
    Jyrki Kuoppala
    2012-08-15

    .. though probably it's not the TraceLayout issue, as the map size reported by ImageCollector is also wrong and thus the issue doesn't reduce to tracelayout.

     
  • Jyrki Kuoppala
    Jyrki Kuoppala
    2012-08-15

    Hmm, looks like the imagecollector should have some changes for split screen; in Trace, startImageCollector:

    imageCollector = new ImageCollector(tiles, this.getWidth(), this.getHeight(), this, images);

    would be better to use the split-screen measures if split screen on.

    Maybe relevant also

    pc.xSize = this.getWidth();
    pc.ySize = this.getHeight();

    So maybe you can try using maxX - minX / maxY - minY for starting imagecollector instead of getWidth() & getHeight() which seem to give incorrect information (the sizeChanged() info seems correct.

    You might also have to remove
    setDisplayCoords(getWidth(), getHeight());

    from recreateTraceLayout() and see if there are any other calls to getWidth() / getHeight() which cause trouble.

     
  • Jyrki Kuoppala
    Jyrki Kuoppala
    2012-08-15

    .. and by split-screen measures I mean minX, minY etc. - so if you modify to use this and that helps your case, same can be used to improve split-screen mode.

     
1 2 > >> (Page 1 of 2)