Using this space, also talking about defaults and something that is to me badly missing (maybe already on the roadmap?) is a scale for distances... any scale really. maybe just saying in the bottom part the distance of the width of current view would be enough for a start..?
On earlier versions of mepo such as 0.2 this feature was present but was removed with the bottom bar rework in 0.3
Logic for calculating onscreen distance is already present.
Need to determine visually how this should work, possibly make tiles numbers in bottom bar less verbose thus allowing some room for distance. Eventually would be nice to have a fully customizable bottom bar via format string or similar but that may be overkill at this point.
As a first "easy" rendition, it could be a very thin bar, on top of the bottom bar announcing its own width at scale? ie. at highest zoom level, it would say "20m" or such... and at widest "30.000km" or so? not very "orthodox" but prob easy to implement for now?
OR, even more readable, a thin bar above the bottom bar, aligned to the right, that would only be as wide as a "round" unit at current scale, and display its own size inside/above. "10m" at closest zoom, then "20m", "50m", "100m" ,"1km" etc. would force a custom-size bar instead of a lazy take-all-the-width bar...?
I realize that writing about these things is not really easy... so here is a mockup of what i meant: proposal 1 aka "lazy": https://wtf.roflcopter.fr/pics/IF46IgAA/73UrxZs4.png proposal 2: https://wtf.roflcopter.fr/pics/yx9y5hrA/LLw9iyJ0.png
Ah thanks for the idea & images - the other issue is that actually on mepo's latest version / head, you'll see UI buttons were added in the bottom right so that'd overlap unfortunately. And bottom left space is reserved for debug messages (for shellpipe exitcodes & similar)
So think currently i'm probably leaning toward integrating it into the bottom bar directly somehow, to limit the 'number' of functionalities present.
Well... one option would be to have this "barlet" always coming on top of whatever is at the bottom. ie. if there is debug messages it is displayed above it, or above the UI buttons even?
Or yes, maybe somehow fitting it inside the bottom bar, stuck to the top, to the expense of reducing maybe a bit the text size on the right?
something like this: https://wtf.roflcopter.fr/pics/rqbA2jJM/RmYrCXkt.png (sorry quick and dirty... the high-contrast text (black with white outline) protrudes as an experiment of thought: maybe having it on top of the rest could help read it despite the UI existing underneat... a bit messy but readable?)
Another proposal, still in the "compact" style... https://wtf.roflcopter.fr/pics/Y1wCMm2b/xWFhKtp6.png
assuming that text at the bottom can be reduced and remain legible, then 2 rows of small text can coexist somewhere, for such a good cause ;)
Ah interesting - thanks for the sketches ~baroque0.
So in the old version (in 0.2) what was done was that the scale of the entire viewport (width/height km/mi) was reported (without any graphical representation). I like that model probably better then drawing an arbitrarily sized small rectangle and reporting that size?
Many map applications do the same thing with a small rectangle to show distance; my question is from a UI perspective is.. how does that even make sense? If you can't drag/rotate the ruler what's the point? Isn't showing the whole viewport with/height in km/mi better?
well i wouldnt mind any of the two as long as we have one ;)
but to be fair the "small rectangle" seems more usable for me because 1/ it's as you noticed a standard, so it's easier to remark 2/ i personally often "pick" its size by spreading two fingers over it, and use the aforementioned two fingers to vaguely measure stuff on the map. this is much easier to do than to divide the whole width of the screen mentally to some "finger-space" to then move over the map?
This is now the ONLY feature i can think of that is missing in my day-to-day usecase with 0.5. as i don't use GPS nor calculate itineraries algorithmically, i always just "look at the map" and the estimation of distance in those cases is really essential.