OpenCPN Version 2.1.0 Beta

[bdbcat]

Folks...

CVS Build 331 is checked in.

I'm off to sea for a few days. Destination: Beaufort, NC.

Good Luck
Dave

[Gilletarom]

OpenCPN 2.1 Build 331.

Hello

In the French version file "opencpn_fr_FR.po" , this affects all versions, there is : "I&mport".

I think it should be "&Import" ?

Best regards

Gilletarom

----------------
The same in french language :

OpenCPN 2.1 build 331.

Bonjour,

Dans le fichier opencpn_fr_FR.po de la version française, cela concerne toutes les versions, il y a "I&mport".

Je pense que cela devrait être "&Import" ?

Cordialement

Gilletarom

[cagney]

Originally Posted by bdbcat

Team....
Changelog:
38, Correct crash on Track Delete with Track Properties dialog open.

Build 331, this bug still present.If I use the Track Properties Dialog to delete the current track, the crash comes when the Track button is pressed. After the track deletion this button is still active, so the crash comes when trying to switch it off.

As already reported, the arrow down key now zooms in.

Thomas

[idpnd]

Originally Posted by PjotrC

I just propose to call things as they should be called.

Thanks for your elaborate info on this. Grey ball?

Originally Posted by Gilletarom

In the French version file "opencpn_fr_FR.po" , this affects all versions, there is : "I&mport".

I think it should be "&Import" ?

Hello, the & just determines where the hotkey for manipulating the dialogue is - feel free to modify as per your wishes & upload to the i18n thread on this subforum.

[Gilletarom]

Hello,

I have join on OpenCPN Internationalization (i18n) a file for french language for 2.1.331.

Best regards.

Gilletarom

[cagney]

Dave

In build 331, SENC creation now works correctly with quilting on.
Did you just forget to mention it, or ... was it just by chance ?

Thomas

[idpnd]

install -p -m 644 ././po/opencpn_cs_CZ.mo /usr/share/locale/sv/LC_MESSAGES
install: cannot stat `././po/opencpn_cs_CZ.mo': No such file or directory
make[1]: *** [install-data-local] Error 1
make[1]: Leaving directory `/home/user/opencpn'
make: *** [install-am] Error 2

Looks like the Czech mo has gone awol..

Edit: Same for Russian - I worked around it by duplicating the German mo file

[PjotrC]

This is almost a bug (mine), so I post this here.
A principle I believe should be kept in ECDIS is that the display should be immediately understandable. For this reason I would vote neither for "suppress anchored/moored" nor "suppress stationary or slow moving". I accept this exists in many programs, but the danger is that looking at clean screen one does not realize at once what targets have been filtered away. To find this out, it is necessary to go into tools->AIS...
If I filter out <all> AIS, I can see this immediately from the icon in toolbar. This keeps the Principle.
Having said that, the bug is:

- if I select <AIS INPUT=NONE>, the ShowAIS icon should not be visible anymore

[idpnd]

Originally Posted by PjotrC

Having said that, the bug is:

- if I select <AIS INPUT=NONE>, the ShowAIS icon should not be visible anymore

Perhaps the icon could even have a third state to reflect the "filtering" bit

[Viking Sailor]

PjotrC,

I can not disagree with you more. The reason to filter out stationary AIS reporting targets is to clear the display so that targets that are a real threat can be more easily seen. Since AIS should never be used as the sole method for detecting transitory hazards to navigation it is alright to enable or disable the selection of targets to be displayed.

[HamishB]

Originally Posted by Viking Sailor

The reason to filter out stationary AIS reporting targets is to clear the display so that targets that are a real threat can be more easily seen.

a compromise where important information is not lost in the clutter but data is not suppressed is to grey-out or set the alpha-channel/transparency of the < 1kt vessels so they are there as ghosts, while active targets are in bright primary colors.


regards,
Hamish

[cagney]

It all depends on where you are or what kind of navigation you are into!

If we are talking about large commercial harbours or restricted waterway with a lot of traffic, then I'm with Viking all the way.
But, on the other hand, if I'm on a passage, say from San Fransisco to Hawaii, then I need to see every vessel, regardless if it is moving >0.3 kts or not, also the time out for "Mark targets as lost" will need to be increased.
Then there are all the cases in between.....approaching a big commercial harbour etc, where you can find vessels in a holding pattern, waiting for a pilot, for example, with very little SOG, where you don't expect it.

So in my view, all the switches in the Toolbox are alright, with the exception of renaming anchored/moored (Pjotr), and make the AIS button dependent on that you actually use AIS ( a switch similar to Grib/Track) (Pjotr).

But, ...there is definitely a need for a visual reminder of your settings in case some targets are suppressed. Hamish's suggestion and/or a different colour AIS button should work.

Thomas

[nohal]

Hi guys,
first of all thanks a lot for this perfect tool. Just returned from a regatta where I changed to the beta before the last 150 mile leg and it worked like a charm. I observed a crash shortly after upgrading from 1.3.6 but since then absolutely no problems with stability.
I totally love this quilting thingie and it works like a charm on my nav station "powered" by Atom and WinXP.

I also gave a bit of a try to the new RouteManager while updating the translation, but it looks like needing a bit more polishing before getting usefull. Following are my observations with it so far:

1. I'm not sure why, but on my dev machine (Win2k8 server) at home the sizing of the dialog is wrong and the buttons overlap (see screenshot with font size set to 96DPI - it gets much worse with larger 120 DPI fonts, when the bottom anchored OK button is totally hidden under the top anchored ones). On my XP nav netbook it's totally ok though.

2. Single clicking the route causes toggling it's visibility, which by itself looks a bit weird to me. Even worse it's impossible to turn it on again in any other way than clicking another one (causing it to disappear) and clicking back on the previously selected route. I also think thatn when I select the route, the buttons should be enabled. Now the behavior I observe is that I have to do something I call "very fast multiclicking" to get the buttons enabled after a while. This behavior is common for both the XP and 2k8 machines.

Will have to revive my C programming skills a little bit to provide fixes in addition to complaints

Cheers and thanks a lot again

Pavel

[nohal]

And one more: After using the Route properties dialog from the RouteManager, the route visibility toggles as well - looks like the event handler needs to check more carefully why and whether the selected item changed.

Pavel

[Netsurfer]

Originally Posted by nohal

1. I'm not sure why, but on my dev machine (Win2k8 server) at home the sizing of the dialog is wrong and the buttons overlap (see screenshot with font size set to 96DPI - it gets much worse with larger 120 DPI fonts, when the bottom anchored OK button is totally hidden under the top anchored ones).

2. Single clicking the route causes toggling it's visibility, which by itself looks a bit weird to me. Even worse it's impossible to turn it on again in any other way than clicking another one (causing it to disappear) and clicking back on the previously selected route.

I can confirm this additionally to the other bugs I reported already.

Another point to look at is that there are two different methods to import GPX data at the moment. One is the routemanager and the other is the GPX Import button. Same for the export function, which is actually not working in routemanager. Also it seems that there is no differentiation between routes and tracks.

But before trying to fix all aspects of the routemanager there should be the general handling of GPX data in OCPN being discussed. Because AFAIK you couldn't really import any GPX data (made by other applications) due to the <extensions> used in OCPN. So as long as there is no automatic conversion for this on import you always have to do this manually.
And AFAIK OCPN uses its very own types of symbols for waypoints, trackpoints and and routepoints - even though it does not exist a standard for this.

Next thing I have to complain about is putting again everthing in one thread (which already consists of 90 posts). So all different aspects like the routemanager, installation problems on different OS (Windows, Linux and their different versions), other bugs of the new version are all mixed up. In my opinion that's not ideal to discuss a certain aspect in-depth. Or would you like to search 8 or more pages, each with 15 posts and pick out the 10 belonging to the specific matter?

So I would welcome it very much if you could decide to open a separate thread for each of this topics!

Happy Easter,
Gunther