widgets and appearance

[quantenschaum]

Thanks for merging my changes!

There are some parts you didn't merge, which I think still offer some improvements. The may also fix #522 and #506.

The changes are:

• added float formatter, display N digits but with floating decimal point
• added options to lat/lon formatter: decimal degrees, degrees dec. minutes, deg min sec, OLC (https://www.npmjs.com/package/open-location-code)
• added distance units ft, yd
• added speed units: bft and correctly named km/h, m/s
• time format with optional seconds
• added fahrenheit and display the unit correctly
• positions are get wrapped to 2 row correctly alinged with monospace font
• gps time and pos show green OK or red blinking ERROR in to right corner (where unit is)
• find tuned widget layout, spaces, font size,
  • headers with light gray background
  • centered values
• added TTG (time to go) option to ETA
• added options to depth widget: below surface, transducer, keel, auto
• extended max XTE range (for use with meters)
• added GNSS status widget showing 2/3D fix, sats used/available, hdop, SBAS
• show WP name in DST, BRG, WP pos
• formatter should handle how null values are displayed (making default value in widget obsolete) this seems more consistent
• dynamic size of time display based on with or w/o seconds
• replace --- by digit wide hyphens for consistent layout
• RTE-ETA: added TTG mode

screenshots of changed appearance

before

after

and w/o data

before

after

The gray leading zeroes are show by user css.

[wellenvogel]

Many thanks for your contribution.
But - as I already explained - it would make life a lot easier if you would separate the contributions.
At the end it's not only the code...
So it needs additions/corrections to the documentation and testing for various set ups.
As this is not part of the PR I have to do all of this additionally.
Smaller PRs make it easier to pick them up step by step.

[wellenvogel]

Ok, started some first tests.
Just a comparison with (first) and without the PR:

This just shows what I mean - the changes need testing in various set ups - and maybe others (inlcuding me) do not agree on all parts of the PR.
By having separated PRs it's much easier to pick up the ones without issues.
With the current structure I will not merge the PR. Potentially I will pick up parts step by step like for the others.

For the widget layout there is some discussion in the forum - but still without real results (i.e. feed back from users).
As I already wrote there: Readability outside is an important point. So I try to keep the important info in the widgets as prominent as possible. So the GPS indicator is really important when under way - I feel the green/red text in the unit location is hard to read.

For new decoded parameters: Misses Android completely. And for using the precision values there was an interesting discussion at the OBP60. Maybe this should be handled similar in AvNav.

[quantenschaum]

Breaking it up makes it easier, I understand that. For the Java part, you are faster porting this. :)

It's good to iterate on that. - I prefer the values to be displayed as big as possible for readability and centered

For the screenshot, the upper one looks better to me, bigger numbers (many widgets have very small numbers by default) = better readsbility, the GPS indicator, sure the green bubble might be helpful, the empty space in lower left, this can always happen depending on screen size, with the little more compact widgets you can fit more data on a small screen.

I restored the TimeStatus widget, makes sense, IMHO this does look pretty good.

I am using Roboto as font here, and a user.css with .error {color: red;} can be used to highlight problems.

[quantenschaum]

concerning feedback: the widgets around the map are actually quite good, they could just use some tuning IMHO, this is what I did here

I'll try to break it into smaller pieces.

[quantenschaum]

I reorganize the commits to make it easier for you. You can walk through the commits one by one starting with fd55a08.

[quantenschaum]

with .error{background: #f88} .nightMode .error {background: darkred;} it could look like this, making the error state pretty obvious.

[wellenvogel]

For now I would like to separate things a bit...
In general I try to keep compatibility as much as possible ( guess I already mentioned this).
I know that there are users that created their own layouts and customized the appearance a lot. So I would like to keep their layouts working.
On the other hand I agree that many widgets should get some "polishing". My approach for this:
(1) small changes that do no break existing layouts (i.e. do not change widgets dimensions or layout of items in them) can easily be incorporated
(2) I will allow to add css to layouts so we can go for new layouts that have changes in the display of widgets - as long as this can be achieved with CSS. Most probably I will add some default layouts that contain css to adapt the widget look by adding CSS classes to the widgets.
And it should be easy to publish additional layouts.
(3) There could be a couple of new widgets - or we could add additional parameters to existing widgets that will allow to restructure the widget display.

Other parts of your changes:
(1) Changes for formatters - can easily be merged as long as they do not break compatibility, just misses doc
(2) new decoded values: Android missing, doc missing - will take some time

[wellenvogel]

I just tried to merge some of the changes. BUT...
At the end the changes heavily depend on each other.
And (as you know) for me compatibility is a must.
But with the current structure and the changes you proposes I would have to go through every change and find out whether it still maintains compatibility or not - and which one can be separated or not.
And I have to reverse engineer the code to create some documentation for the user.

So for now I will not continue on that.
I would be happy to merge some changes as long as compatibility is there and you include the necessary documentation.
Maybe I will still pick up some of your proposals later.

Some detailed hints:
(1) formatters - for the position formatter the default needs to be compatible to what we have and for the parameters we need some documentation
(2) Existing widgets must not be changed. Where it really makes sense some new functionality could be added with a switch to enable it.
(3) if we try to use a monospace font like for the position this easily creates some really strange look and feel. It completely depends on the users font settings how different the position display would look like from the others. Not sure if users would really like this.

In general:
I would like to create a directory of community contributed plugins and layouts for AvNav. With the next version I will include an option to upload a zip containing a plugin to AvNav. And this will also work for Android.
So it will be easy to create some layouts or plugins to adapt the look and feel. Layouts will also have the option to include CSS or settings.
So for all ideas about layout changes I would suggest to go for a layout or plugin (just js, css and layout).
This way users can freely select the layout they would like to use.

[quantenschaum]

I can understand what you say, BUT you ask for feedback and you even contributions, so be happy, take it, modify it, use it, do not complain that much (I hope you get what I mean) 😬

• What do you mean by 'compatibility', do these changes break anything? It's a collection of small tweaks that improve overall experience.
• "heavily depend on each other" - heavily is exaggerated, but yes, this is how it works, you build something, then something else and so on
• If you spot an error, you can fix it.
• "I have to reverse engineer the code" - Yes, of course! That is what I always have to do with your code when I want to change something. Most time in developing is spent reading code. And if you want/have to review the PR you have to read and understand it anyway. The description in the PR helps to get the conceptual changes.
• "create some documentation for the user" and you know where the things are in the docs, so you are faster, if these docs even exist for the features touched. But I do not see changes here that completely change the behaviour.
• a UI should self explaining and should not need much docs, the hint under the (?) are very helpful, also see Hover text on Icons would be useful #289 (just add some tooltip texts instead of explaining why not, then improve later)
• position formatter: it's a position in lat/lon in common formats D.DDDD or D M.MMM or DMS, this is self-explaining
• "Existing widgets must not be changed" - why not? if they are improved, it's a win. you would not even fix an error then? what did I change that breaks something?
• "monospace font like for the position this easily creates some really strange look and feel" - personal taste may be, but a position in 2 rows, nicely aligned is much more legible, "depends on the users font settings" this is always the case, even w/o my changes, "Not sure if users would really like this" Yes, because it's easier to read. For the layouting of the number displaying widgets a monspaced font is actually ideal because the width is stable, just the decimal point to too wide. It is maybe a good idea to include the fonts in avnav for a consistent look.

VS
What looks better? - Come on!
How is the position displayed on a VHF?

(N/S,W/E should be in front IMHO, it just the sign, but that can be configured)

I don't want you to accept it blindly, but the changes make sense, I invested time to read the code and adapt it and it would be nice if other could use that as well. So, I would be happy if you take it, adapt it here and there. I think it is impossible to get the perfect pull request

The plugin idea is nice, but you already can put plugins into the plugin dir and there is the user.js and css. That is great.

Tweaking the look by adding user css works but is cumbersome if the base css is "ugly". This is why I changed the base, IMHO this is a better default, it's not huge layout change it just improves the existing w/o breaking it. Small custom tweaks can nicely be done by user css.

[wellenvogel]

Hmm - I'm a bit unhappy with the way you try to communicate...
I'm always interested in proposals, ideas and I like to discuss about possible improvements.
But not on a basis of "I for sure know better".

You have some ideas about changing things. Some of them I like - some of them I do not like and some of them - I would like to get feedback from others for.

At the end it's my project and you should accept that I have some ideas on the current (and further development).
What I try to do is to allow others to contribute using some interfaces that I try to keep stable. This way you (and others) should be able to contribute without interfering to much with the main part.

For the UI it's always a bit difficult as everybody seems to have own ideas on how it should look like. I know for sure that there is a lot of room for improvement - but as already mentioned several times: I would not like to break other users layouts (or other stuff). One of the reasons I came up with layouts was just to address this part (completely different ideas on the look and feel).
I don't think that it is a big challenge to keep changes compatible and to let the user choose what she/he likes most.

For the rest - I have some internal roadmap for the further development and some of the changes you propose may fit - others may not.

Not sure if you can accept what I write - but from my pov we can only work together on this basis - or not at all.

[quantenschaum]

I'm a bit unhappy with the way you try to communicate...

Yes same here, but maybe it's a misunderstanding on both sides.

At the end it's my project

Absolutely, but you share it and ask for contribution. And it's a great project and I really like it and appreciate your work. This is why I use it and want to contribute.

You have some ideas about changing things. Some of them I like - some of them I do not like and some of them - I would like to get feedback from others for.

Of course, everyone has his own ideas and taste. But this is the point, I get the impression that you want to do everything on your own and your way, which you for sure can, it's your project and you have things planned and in mind, but then contributing gets difficult. The general reaction to contributions seem to be explanations why this and that doesn't work and cannot be done or you don't want to do it. Sometimes this is fine and also justified, because it would break things, but sometimes it seems just overly complicated. I get the impression the you want people to contribute in a very specific way, by telling you what they want, not to give you code, and if they code, they should just use the interface, not touch the "core".

So, after having spent quite some time to understand the code and adjusting things, I thought it was good to share the changes. I wished to get a reaction like: 'Nice, that really looks better, I take this, but here I changed this and because...' instead I get the impression my work is complete rubbish, breaks everything, destroys user experience because I changed everything fundamentally. Really? It seems so negative.

[quantenschaum]

Lets discuss number formatting!

I was wondering about good naming and came up with:
the number 12.345 has

• 5 TOTAL digits
• 2 INTEGER digits
• 3 FRACTIONAL digits

As I can see it, it is desirable to format numbers such that the resulting string has a fixed number of chars for consistent display.
There are the following cases (and combinations thereof).

• integer numbers w/o decimal point
• signed numbers, can have minus sign

The formatter can take the parameters

• digits = number of total digits, resulting in k=digits+p+s chars with p=1 if there is a decimal point and s=1 if signed
• signed = flag indicating potentially negative numbers
• maxFrac = max allowed fractional digits, with 0 <= maxFrac <= digits-1
• leadingZeroes = flag if padding of left is done with spaces or 0s

If padding should be optional leadingZeroes could be replaced by

• padding with values none=no padding, zeroes=leading zeroes, space=spaces (or maybe any char, but is this needed?)

IMHO this information is sufficient to format any kind of number into a k char string. The only cases where the string gets longer are

• number is too big
• has unexpected sign

Maybe it is desirable to limit the string to exactly k chars, so if exceeded an error string could be used (with length k)?

I implemented this in formatFloat and you already adopted it. Thanks. digits can be negative to indicate signed numbers, maxFrac=0 formats as integer w/o decimal point.

From my user point of view I find the formatDecimal a bit unintuitive (my personal experience on using avnav as user) because the meaning of fix, fract, addSpace is pretty unclear and it lacks a description. IMHO formatFloat has more user friendly parameters and removes the restriction of fixed fractional digits, also when the number gets too big, the fractional digits are removed to maintain a fixed number of chars (as long as possible), even an unexpected sign is taken care of, limiting the number of fractional digits effectively makes it a replacement candidate for formatDecimal.

Having a fixed number of chars as output string make the widgets in their width stable but dynamic.

Since the formatter "knows" the pattern of the format, it can generate a placeholder string of right size if an invalid value like null or NaN is supplied, there is no need to code this separately.

To get a stable width of the text, a monospace font could be used, but that doesn't always look good and the chars are too wide (especially the .). But if numbers and the - have different width, the display width of the string is not stable. A solution is to use tabular numerals and a figure dash for the placeholder default values. Relacing the : with a raised colon makes time format look better.

This is what i implemented and I find the result quite pleasing. (I used Roboto in my examples.)

old

new

w/o data

Does this destroy avnav or could you give it a try?

[quantenschaum]

Just asking...

Existing widgets must not be changed.

But you added maxValue to DepthDisplay. This is a change, but it's OK.

I added the selection of the kind of depth and distance formatter settings, by setting default to DBT it would not change for the users. That is not OK?

I understand that you want to avoid surprises for the users.

You now created 3 different depth widgets with highlighting of low values, nice. Why 3 widgets instead of 1 with the selection of the kind inside? This is fine, I just like to understand why.

as user: the params digits and fillright seem not intuitive, I would prefer digits and maxFrac (not hidden).

for digits>0 there are leading zeroes, why?

for the new min/max value params: IMHO it would make sense to set the limit to 999 for 3 total digits, so the resulting string doesn't get too long. it is maybe also good to indicate the over/under flow to the user instead of just showing ---, one could use <<< and >>>? so, the user knows that this is the case, not that the sensor has died.

(for digits=0 to be replaced with 3 in formatFloat you need to check for !digits because 0==null is false. )

[quantenschaum]

remarks on #529 (comment)

I can see that this process has been frustrating for you, and honestly, it’s been discouraging for me too. From my side, your general reaction to pull requests seems to focus almost entirely on what’s wrong, compatibility concerns, missing documentation, supposedly broken details, instead of acknowledging the overall improvements and positive aspects they bring.

I don’t think the negative points you mention are insignificant, but in most cases they’re minor compared to the overall progress and enhancement the contribution provides. The positive impact outweighs the rough edges, yet the focus seems to fall on the flaws, often in an exaggerated way. Sometimes issues are even called out as flaws when the same patterns exist in your own code, which makes it feel inconsistent and discouraging.

You mentioned an “I-know-better” attitude, and I can see how it might look that way when I explain and defend my work. But it also comes across similarly when contributions are rejected and later reimplemented differently, or when feedback seems to imply there’s only one “right” way, your way. I think we’re both trying to do what we believe is best for the project, and that shared intent should be the foundation of collaboration, not a source of conflict.

I completely understand your goal of maintaining high quality and consistency. Still, I think progress often comes from small, imperfect but functional changes that can be refined and improved later. Ugly action beats unfinished perfection. Nobody’s code is perfect, and that’s fine, what matters is steady improvement.

It would really help if the review process balanced critical points with appreciation for what works. Constructive criticism explaining a problem is useful and creates a good basis for discussion, but constantly emphasizing flaws discourages contributions. Instead of rejecting everything outright, a more collaborative approach would be to merge what’s good, make small adjustments where needed, or ask for targeted fixes. That’s true teamwork, combining ideas and experience rather than setting them against each other.

Documentation
Docs are important, but they’re tedious to write, we both know that. Instead of stopping a PR because of missing docs, it would be more constructive to say something like: “Looks good, could you please update the docs at [link] as well?” That keeps things moving while keeping documentation up to date.

Compatibility
I understand the concern about breaking changes, I don’t want that as a user either. A great way to ensure stability is automated testing. With unit tests, behavior becomes objective and verifiable, rather than relying on subjective judgment. Without tests, it’s hard to say what’s truly compatible except in obvious cases like compilation errors or crashes.

Also, it’s confusing when you state that existing widgets shouldn’t be changed, but then modify one yourself, that inconsistency makes it hard to understand what the actual rules are.

Separation/Dependencies
You’ve mentioned that changes heavily depend on each other. That’s normal when introducing new functionality or refactoring. Each change builds on the previous one, that’s how development works. If every change had to be completely independent, we’d never actually integrate features.

Dependencies aren’t a problem when changes are logically grouped and reviewable. Independence, for its own sake, isn’t practical or meaningful in a growing codebase.

Code Review
You mentioned having to “go through every change and check for compatibility” and “reverse-engineer the code.” That’s the normal part of maintaining an open project, this is the core of a code review, just as contributors have to reverse-engineer existing code to contribute responsibly. It’s a two-way process, not a one-sided burden.

I’m always happy to improve docs or adjust code if you point out where and what exactly it’s needed. Clear, specific feedback is much more productive than general rejection, it helps align contributions with your expectations and keeps the process constructive.

Overall
I really want this to be a collaboration. Different styles and preferences are normal, what matters is the result. I’d love to see the review process focus more on integrating what works, rather than amplifying what doesn’t. In the end, we’re both trying to improve the same project, and a balanced approach will get us and the users there faster.

[quantenschaum]

in #529 (comment) you write

This just shows what I mean

I don't know what you mean. What exactly do you mean? The empty space bottom left? You can always find a window width where one of the flex containers in the bottom wraps and the other does not. That is also the case w/o my changes. Top alignment looks better IMHO.

[wellenvogel]

Some shorts answers.
For now I'm just working on bringing plugins to Android and allowing user plugins via zip files to be uploaded in the app.
So it will take some time until coming back to your proposals.
In general I highly appreciate your ideas and input to AvNav. You have a lot of great ideas for improvements and for changes.
And it's a lot of work that you spent here - also something that I would like to thank you for.
Not sure if I was not really clear with my concerns...
For me (as you know) compatibility is really a key point. This does not mean that we cannot change existing stuff (like existing widgets). But this should happen in a compatible manner.
I think that is not really that much of a big issue if you just "think compatibilty" from the beginning. Simple example:
If you change the position formatter and position widget - it would be really simple to keep the old behavior as a default and just add the changed stuff with parameters or css classes. This way existing layouts would keep looking as they are and current usages of the formatter would continue to work.
And to show the user the new look and feel you could provide some example layout that shows how things could look like.
Having this compatibility being available it would be much easier to just accept the PR and merge it (what I typically would like to do).
As I already wrote - I'm quite sure that different users have different preferences (I also have some from my users perspective). I would like to allow those users as much as possible to tune the display in AvNav to what they like most.
And I guess a really nice option would be, if the user could just select between different predefined layouts (and potentially slightly adapt them later).

It would really help if the review process balanced critical points with appreciation for what works. Constructive criticism explaining a problem is useful and creates a good basis for discussion, but constantly emphasizing flaws discourages contributions. Instead of rejecting everything outright, a more collaborative approach would be to merge what’s good, make small adjustments where needed, or ask for targeted fixes. That’s true teamwork, combining ideas and experience rather than setting them against each other.

I think it would typically make life a lot easier if we would discuss ideas before implementing a lot of things. I understand that it is frustrating if you (or others) write code that I'm not really willing to accept as it is (I have the same problem of course if I try to contribute somewhere else). But I think the only chance to avoid this would be to agree on some concepts before starting.

Dependencies aren’t a problem when changes are logically grouped and reviewable. Independence, for its own sake, isn’t practical or meaningful in a growing codebase.

I partly agree. What I mean: If changes are independent they could easily be merged one by one. And if one is not merged - the others are still "in". I understand that this is not always possible of course.

A great way to ensure stability is automated testing. With unit tests, behavior becomes objective and verifiable, rather than relying on subjective judgment. Without tests, it’s hard to say what’s truly compatible except in obvious cases like compilation errors or crashes.

Sure - testing would make it easier to check the influence of changes and to maintain compatibility and stability. But there are two points:

1. Testing needs effort. From my experience good testing needs at least 50% of the implementation effort. I already made a couple of attempts to integrate some testing framework - but unfortunately none of them could be integrated easily (typically it ends up in a nightmare of dependency issues and the need for restructuring the build process).
   So I had to decide whether to spent a reasonable amount of my time on introducing a good testing solution - or to continue implementing new features (and leave testing to the community).
   I would be happy if someone would come up with a nice testing framework that would easily integrate. But still there is...
2. Testing by it's own does not solve many of the problems we are just discussing here. Maybe unit testing could give you some ideas about missing compatibility - but still it does not solve this problem.
   And (at least from my experience) Unit Testing is only one part of the game - you definitely need more (integration testing,...).

I really want this to be a collaboration. Different styles and preferences are normal, what matters is the result. I’d love to see the review process focus more on integrating what works, rather than amplifying what doesn’t. In the end, we’re both trying to improve the same project, and a balanced approach will get us and the users there faster.

I would also love to see faster progress - but that's exactly what I tried to explain - it would be much easier to achieve by trying to follow some rules.