Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - joeloc

#316
Declined / Re: place dialog more compact
January 02, 2012, 18:19:50
Hmm. I stand corrected. The Galaxy note spoiled me. Sorry :)
#317
I cant really debug nicely on the road. Catlog is some adb tool? No luck then :)

Doesnt it scroll slowly for you too when the map is completely off screen? It seems to me that locus does some onscreen offscreen check every second then and this check takes a long time. Maybe it iterates through all rmap tiles? Just guessing...
#318
Declined / Re: place dialog more compact
January 02, 2012, 12:53:13
Scrolling is even worse than sub menus, i totally agree.

But on the other hand, if you need two clicks instead of one to reach a function, the error possibilty (misplaced click) is increased by 100%. And misplacing clicks is not that uncommon on a moving vehicle :).

Ill draw up something later. Its a bit hard on the mobile phone.

The single item submenu was some "hide" under a settings-like icon when you click on an existing pointon the map.
#319
Declined / Re: place dialog more compact
January 02, 2012, 12:25:52
Ok... 22 buttons would be to much. Ill think of something later. But the grouping is really unfortunate anyway. Some icons do immediate action, some open a submenu, one opens a sub menu with just a single item?! That is simply weird.
#320
Declined / Re: place dialog more compact
January 02, 2012, 12:23:27
I must disagree. You have the whole screen available... so use it wisely! Right now, you waste 50% with a greyed out  map area that is completely irrelevant to the dialog. Then you waste 50% inside the window itself with whitespace and labels.

There would be plenty plenty plenty room for all your options immediately, even on the smallest phone.

Why not spare users from additional popups and additional clicks when you can? It might seem irrelevant on your development couch. But i can assure you that every extra click is a nuisance when you sit on a bike and wear sunglasses.
#321
Declined / place dialog more compact
January 02, 2012, 10:46:40
The place dialog (see below) is a bit unfortunate. Some of the icons cause immediate action, some open a sub menu, its not really clear to me which image does what.

With a bit of rearranging, it would be possible to kill the sub menus completely and offer each option directly on a single click. Sub menus are necessary sometimes, but here its just bad usability. There is plenty of space and each extra click is bad when you sit on a bike.


[attachment=0:1stir2kn]SC20120102-093431.jpg[/attachment:1stir2kn]
#322
Sure. But as a computer geek, i just like every file in my file browser to be associated with something useful. Non-clickable items irritate me :).
#323
You rock! Greetings from Lanzarote btw... Locus finds all the trails easily :)

#324
no change with 1.15.4.3 (ie locus still freezes for a split second when rmaps are completely off screen and i try to scroll).
also no change for the 3gb map.
#325
I just thought it would be convenient while I played around with file explorers and rmaps. No clue how file types work on android though, so if it's too complex, forget it. As long as you can open gpx, everything is fine :).
#326
uploading 3GB is beyond my capabilities :-( and smaller maps work nicely.

maybe some fseek() or whatever this is called in java beyond the 2GB boundary fails. you have to read data from the end i guess? a bit more debug whenever rmaps fail might be helpful.

it might even be helpful in general as an error message for the normal (nondebug) user.
#327
CompeGPS MAP File
<Header>
Version=2
VerCompeGPS=6.72
Projection=3,Transversal Mercator, 9, 0, 0, 500000,1
Coordinates=1
Datum=WGS 84
</Header>
<Map>
Bitmap=KMP-Alpen-DE-AUT-CH-IT-SLO.rmap
BitsPerPixel=0
BitmapWidth=141049
BitmapHeight=55905
</Map>
<Calibration>
P1= 0, 0,, 5.87168899997482, 47.8668659999137
P2= 70524.5, 0,, 10.5878400006239, 47.8985209060187
P3= 141049, 0,, 15.2873839956531, 47.7369799944763
P4= 0, 27952.5,, 5.94481549987443, 46.6110613118524
P5= 70524.5, 27952.5,, 10.5506702027813, 46.6413627298758
P6= 141049, 27952.5,, 15.1412682455545, 46.4867141048772
P7= 0, 55905,, 6.01320499997158, 45.3548969999388
P8= 70524.5, 55905,, 10.5159115985245, 45.3839056874145
P9= 141049, 55905,, 15.0045629983003, 45.2358419960646
</Calibration>
#328
probably not, but i just wanted to find out more. it's on fat32 microsd. movies up to 4GB apparently work with certain video players.
#329
Maps for arabic countries (like egypt) are rendered with arabic fonts. That might be cool for some usage cases, but I suppose 99% of your users would prefer latin spelling. Is that maybe an option that you can change in mapsforge rendering in Locus? Or is it done at map creation time already?
#330
Speaking about huge maps: I am just trying a 3GB RMAP file again. Locus doesnt even show it in the map manager. I tried to query "adb logcat | grep locus" for some information, but it only contains rubbish as far as i can see :-). Could you maybe make it a bit more verbose with useful debug information? I'd like to know why certain RMAP files are refused.

Maybe it would be better to not ever deny a map file, even if it's broken/mangled/wrong projection or has other errors. They should still show up in map manager. When the user selects it, you can write a specific error text into the rendered tiles, eg "projection xyz not supported" or "file read error at position 4123412421". Then people know what's going on immediately.