Messages

yeah... but do you spend 14 hours with locus while sweating on a moving mountain bike, wearing sunglasses in bright sunshine? or is it 14 hours in the comfort of your living room, where a few extra clicks here and there do not matter...

btw, your map selection things do not work well "in real life". it is all backwards and not very helpful. oruxmaps has that figured better, at least with different maps in different scales. but thats a different topic, lets not get into that here.

anyway, i think we are having an english language barrier here. i never said anything about tracks and points in the same window?! what good would that do?

what i said was mainly that there should be ONE track detail view to do everything from. not a dozen different places for different things like it is now. and that an email program with its folders, subject lists and mail view is just the same as track categories, track list and track detail view. i thought android had an API for exactly that kind of thing because it is very common. and if you use this api, it will magically work "just right", from 1.6 up to ics. meaning you get the actions on the hardware menu button below 3.x and the new action bars or whatever on ics, all without any sort of extra work. much simpler than keeping your "custom stuff" up to date.

but maybe i think too much of android apis and it doesnt really work that easy.

A track is a track is a track. Oh... and it is also... A TRACK!

Why can I export a track from the track list but not from a track detail view?

Why can I not export a track when I see and click it on the map?

Why can I fill in altitude data from the track list but not from the map?

Why can I not fill in altidute data when I am viewing the altitude chart?

Why can I not enable "guiding" along a track when I see its detail view?

These are just a few examples of dozens of incosistencies with the current UI. You can not fix this by adding more and more points to more and more popup menus in more and more places. Locus has many nice functions but theyre all stowed away in different parts of the program, even though they work on the exact same thing: a track!

I spend ten hours per day with Locus, every single day of my life. I know what I am talking about . Your programs usability could benefit greatly from a simplified approach.

A track is a track is a track. It deserves ONE view with ONE set of menus.  Not a bunch of things accessible from the map and another bunch accesible from the track list and another bunch accessible from the detail view and another bunch accessible from the edit window. It probably seems somehow "logical" to you because thats the way Locus has "grown". But it is not. It is quite a mess in reality.

Just my opinion .

I still think its a good idea . Theres no difference from a users point of view between handling email and handling locus tracks. Why have two completely different UIs for this?

Ignoreme

The track user interface mess and a possible solution

Firstly, sorry for not using getsatisfaction. It has been a 404 since day one on vodafone spain, simply doesnt work. Now for the real topic:

The user interface for tracks has become quite a big mess over time. We have at least five different places now where you can "do" things with tracks: a popup menu on the map, a popup menu over a track in the track list, some onscreen buttons in the tracklist, then we have the track information window with additional buttons, depening on which tab is selected. wtf...

this is seriously BAD
 
Now let me introduce my idea. A track list and tracks are very much the same stuff as email, user interface wise. The track list equals your list of emails, a single track detail view equals a single email view.

This kind of stuff is very common on android and google offers wonderful APIs for that. Just look at GoogleMail and how beautifully it adapts between horizontal and vertical displays, how it uses side-by-side view on tablets, how you can use swiping gestures, etcpp.

Shouldnt Locus use the exact same API for its tracks? You would get all those features for free and everything would fall into place just beautifully. Users know what to expect, users know how to handle things, no learning required at all, everything works as expected. This is would be much preferable to any kind of "custom ui", even if you now think you can do things "better". In the end, it is always nicer and easier to follow standards.

Now for the track detail view (similar to an email view): Do not use tabs(for altitude chart or whatever), use one long scrolling view instead! Scrolling comes absolutely natural on a phone/tablet and everybody uses it all the time. Why mess this up and try to fit stuff into a "custom made window"? Tracks can have so many different attributes, this can never work properly. Think about <desc> and <cmt> fields for instance. They can be any length, they can be html, they can be whatever. Plus they are quite important to display nicely, many track portals put a route description in there.

I would suggest to format the track detail view internally as HTML and use some HTML class for display. No custom stuff made up from custom UI elements. Using html has the benefit of being able to display html cmt and desc tags easily. Also, users would be able to cut & paste relevant information. It always irritates me to see text on a screen that i can not mark and copy.

Also: Now we have a separate window for editing track details. More unneccessary mess. Why can I not simply edit the data I see in a tracks view right away? There is no need for yet another window with yet another formatting of some parts of a tracks data. This could probably also be easily implemented via FORMs if a tracks detail view was in HTML.

An most importantly: EVERYTHING you can possibly do to a track should be available from this new track detail view. And only there! No other popup menus, not five different places with different actions everywhere. Whenever I click on a track in Locus, regardless if its in the track list or on a track on the map or on a track name box (!) on the map, Locus must take me to the track detail view immediately and let me continue on from there. There must be no difference between clicking on a track in the map or on a track in the list. Its all the same, logically.

I know this is kind of a big change... but in the end, everything will become simple and easy and beautiful. New user will immediately know whats going on.

Obviously, the same paradigm (list & detail view) would then be used for waypoints as well. And your "categories" are exactly the same as mail folders in gmail and could also be displayed and handled alike.

Think about it. Easy, simple, beautiful, powerful, and a lot less messy than the current state of things.

Greetings from the middle of the atlantic ocean... on a ferry from tenerife to cadiz.
Joe.

Still doest work for me... in fact in never worked from spanish vodafone. Oh well, no satisfaction for me then . Its a shame... we had such a nice forum here and now its more or less dead. Two places for bug reports and discussions simply do not work.

Getsatisfaction never worked in the last week. Website not reachable, at least not via spanish vodafone. Besides... isnt it very cumbersome to use compared to tapatalk etc? Forums rule . Your choice of course, but a mobile app should support easy bug reporting from mobile devices imho.

Aha... track name labels depend track icon settings now. I have track icons set to No symbols and that kills my name labels as well.

Hm... Where did my track name labes go? They disappeared with latest beta

How's the OpenGL learning moving along? :-)

oops... forum messup indeed. anyway, problem only shows with larger maps it seems. the smaller the map, the less wandering around. could be some kind of floating point / int rounding error for the waypoint positions when maps are scrolled. it adds up over time and is reset when i change zoom levels.

anyway, i'll upload a testmap. check your email for the link in 3 hours .

that worked. thanks!

my advice is to wait for menion to give us proper error messages when scanning the map folders :-).

none of my mapsforge vector maps shows up anymore since weeks and i still dont know why.

Locus behaves quite strange with a rmap I just created. It displays OK at first, waypoints and tracks are correctly placed. However, as soon as I start moving the map, the waypoints & tracks sort of "travel across". They do not stay where they belong but instead "move downward" on the map a little. The more I scroll, the more they are misplaced.

When I switch zoomlevels, all positions are fine again. But as soon as I start scrolling, waypoints travel off.

I suspect Locus might have problems with
a) maps close to the equator or
b) maps spanning the 0 degree lattitude boundary

CompeGPS MAP File
<Header>
Version=2
VerCompeGPS=6.72
Projection=3,Transversal Mercator, 0, 0, 0, 0,1
Coordinates=1
Datum=WGS 84
</Header>
<Map>
Bitmap=IGN200-MarokkoV3.rmap
BitsPerPixel=8
BitmapWidth=69495
BitmapHeight=125408
</Map>
<Calibration>
P1= 0, 0,,-20.8917514449311, 35.8416007924836
P2= 34747.5, 0,,-9.66523653676011, 37.3208713889446
P3= 69495, 0,, 2.09372000000695, 37.699649999995
P4= 0, 62704,,-17.908056963101, 19.8165689844945
P5= 34747.5, 62704,,-8.2044940572334, 20.5516666364999
P6= 69495, 62704,, 1.77274330043972, 20.7382028189627
P7= 0, 125408,,-16.8548160584998, 3.58237771924974
P8= 34747.5, 125408,,-7.69836579292717, 3.71000228861514
P9= 69495, 125408,, 1.66206799999545, 3.74229699999995
</Calibration>

Try tools/configure in GlobalMapper, go to Projection tab. Set to Transverse Mercator and WGS84 Datum. Export again. Also, you might try to create the RMAP with TTQV4 demo instead of CompeLand. Might be more compatible with Locus.