OpenCPN Beta Version 3.3.2316 Released

[bcn]

Rick,

think that the perceived rendering will be different depending on the screens used.
This is the rendering of a screenshot of Inkscape from one PC, .png and uploaded.

If I look at it at the PC used for the browser the color impression is slightly different.
But the "distance" between the three colors appears to be the same.
Disclaimer: I did not check at the sources if the actual colors are "plain green" and "plain yellow".

[bcn]

From the latest Git:

[cagney]

Looking closer at the menu bar I find some inconsistent wording:
Navigate->Record Track
This option toggles tracking on/off. Recording is what the VDR does.

Tools->Route & Mark Manager...
Activates what is normally called "The Route Manager. This is not quite correct.
Correctly it should be called "The Route, Tracks, Waypoints and Layers Manager". This is of course a mouthful, so we normally just say the "Route Manager. Why change this?

----------
AIS-> Show Target tracks. Un-ticking still shows tracks .

Linux Amd64

/Thomas

[stensmo]

The font size in settings seem much smaller, making the text hard to read. Tested on a Mac Book Retina. I also tested on version 3.3.1117, and the font size in the older version is bigger.

[Mollymawk]

Originally Posted by stensmo

The font size in settings seem much smaller, making the text hard to read. Tested on a Mac Book Retina. I also tested on version 3.3.1117, and the font size in the older version is bigger.

That's strange, on my (non-retina) Mac the text used to be too small and now is much bigger.

The text is now supposed to default to the system UI font size. The same size as, say, the text in the OS X system preferences.
Is this not the case for you?

[Mollymawk]

Originally Posted by cagney

Looking closer at the menu bar I find some inconsistent wording:
Navigate->Record Track
This option toggles tracking on/off. Recording is what the VDR does.

This is a difficult one. Of course it *is* recording the track, but perhaps that is not the best word.
"Toggle Tracking" doesn't work because the enabled/disabled state is marked with a tick.
Maybe "Enable Tracking".

Tools->Route & Mark Manager...
Activates what is normally called "The Route Manager. This is not quite correct.
Correctly it should be called "The Route, Tracks, Waypoints and Layers Manager". This is of course a mouthful, so we normally just say the "Route Manager. Why change this?

Of course, I should have used the existing label, and then separately raise the issue that I do not think that label is appropriate. Sorry. For consistency this must obviously be the same everywhere.

But now we are talking about it... I do not think "Route Manager" is adequate. It implies *only* having routes there. I remember when I first used OCPN it was a long time before I found out that marks/waypoints were there too. I think calling it "Route & Mark Manager" makes it clearer.
Of course there are other things there, but once you see that there is a dialog with both routes and marks in it, I think it is more obvious that tracks etc might be there than if it is only labeled as having routes in it.

Perhaps there is a different way to label this that would be clearer; any ideas?

----------
AIS-> Show Target tracks. Un-ticking still shows tracks .

Linux Amd64

/Thomas

I will have a look at this when I get a chance. I think it correctly toggles the setting in the Options dialog, but maybe that is not getting applied correctly.

[Mollymawk]

Originally Posted by cagney

Looking closer at the menu bar I find some inconsistent wording:
Navigate->Record Track
This option toggles tracking on/off. Recording is what the VDR does.

This is a difficult one. Of course it *is* recording the track, but perhaps that is not the best word.
"Toggle Tracking" doesn't work because the enabled/disabled state is marked with a tick.
Maybe "Enable Tracking".

Tools->Route & Mark Manager...
Activates what is normally called "The Route Manager. This is not quite correct.
Correctly it should be called "The Route, Tracks, Waypoints and Layers Manager". This is of course a mouthful, so we normally just say the "Route Manager. Why change this?

Of course, I should have used the existing label, and then separately raise the issue that I do not think that label is appropriate. Sorry. For consistency this must obviously be the same everywhere.

But now we are talking about it... I do not think "Route Manager" is adequate. It implies *only* having routes there. I remember when I first used OCPN it was a long time before I found out that marks/waypoints were there too. I think calling it "Route & Mark Manager" makes it clearer.
Of course there are other things there, but once you see that there is a dialog with both routes and marks in it, I think it is more obvious that tracks etc might be there than if it is only labeled as having routes in it.

Perhaps there is a different way to label this that would be clearer; any ideas?

----------
AIS-> Show Target tracks. Un-ticking still shows tracks .

Linux Amd64

/Thomas

I will have a look at this when I get a chance. I think it correctly toggles the setting in the Options dialog, but maybe that is not getting applied correctly.

Caesar

[P_Dub]

The settings in the `OPTIONS¨ is too small, it seems to me to be font size 4 or 6 and would probably be difficult to reed, except on 21 inch scrren.
For the rest it seems OK. Also, the request for gribs from saildocs does not work on my laptop. Windows 7 Ultimate and Outlook for email.
Regards.

[bcn]

Originally Posted by P_Dub

The settings in the `OPTIONS¨ is too small, it seems to me to be font size 4 or 6 and would probably be difficult to reed, except on 21 inch screen.
Regards.

Don't get it - that has not changed in our W7 (14") and W8.1 since a long time.
Screen shot perhaps to understand this issue? As this is not the first time you are mentioning it....

[P_Dub]

Here is the screen shot.

[bcn]

In comparison (W7 system)...
Font size in Menu and Body is the same.

So now the question - what is different in the settings - from where the font size in the option body is triggered?

[Hakan]

A bad performance and invisible lights report.
OCPN beta: Pulled today. Win XP, OpenGl = on. No connections are active.
This is not a good debug report since I can't say like: "if you do this the problem occurs" but it's more a general feeling and one obvious problem.
First.
The lights, lighthouse/buoys, are sometimes not visible independence if they are switches on or on/off. Sometimes, it may be when I left lights option to "On" when stopping the program, that after a upstart the lights can be visible and can then be switched on and off. This problem has started since a week or two.
Second.
Zooming in and and out is slower for vector charts and are dramatically slower for raster charts.
I've no time comparison but used memory has increased. I can't say when this started but rather recently.

Memory used:
From start on CM93, without lights: 65 MB
Turn lights on, although they are not visible: 95 MB
Switch to raster charts: 340 MB
Zooming in raster charts: temp. 520 MB

Processor use is not high, normally ~5% but temporarily when zooming raster 90%.

My log and config -files are attached. (Discard .pdf)

Are there any verification test i can do? Please advice.
Håkan

[P_Dub]

Originally Posted by bcn

In comparison (W7 system)...
Font size in Menu and Body is the same.

So now the question - what is different in the settings - from where the font size in the option body is triggered?

Where can we change that is the question or what was change inadvertantly?
Bye

[nohal]

Hakan...
Pulled means git pull and local build or download of the 3.3.2316 package? To what are you comparing? 3.3.2316? Some earlier version?

Thanks

Pavel

[bdbcat]

Hubert...

P_Dub is using original 2316, not latest git sandbox build. So, no comparisons with current github build are meaningful.

P_Dub...
Please be patient for the next Beta.

Thanks
Dave