OpenCPN Version 5.1.511 Beta Test

[Dsanduril]

Also no grid on Linux, did work on .428.

[cagney]

Dave

Suggestion:
Options->Charts->Vector Charts Display->User Standard Objects
should be grayed out unless Display Category "User Standard" is selected.

Why?
During the last week I have seen 2 users quickly diving into OpenCPN, and misunderstanding how "Options->Charts->Vector Charts Display->User Standard Objects" works. Next step for them is asking on this forum.

Thomas

[did-g]

Originally Posted by Ptizef

Oups you are Right!
The problem is here.
Both automatic calculation:

W10 version shows 222
Linux version shows 361 (curiously the same value as my 15' device, same OS)

Linux graphic stack is a POS.
For various brain dead reasons it's often forcing screen at 96 dpi, screwing actual size.


You can look at /var/log/Xorg.0.log, if it's still there.
Search for EDID
46.050] (II) modeset(0): EDID for output eDP-1
[ 46.050] (II)

modeset(0): Manufacturer: CMN Model: 1132 Serial#: 0
[ 46.050] (II) modeset(0): Year: 2013 Week: 19
[ 46.050] (II) modeset(0): EDID Version: 1.4
[ 46.050] (II) modeset(0): Digital Display Input
[ 46.050] (II) modeset(0): 6 bits per channel
[ 46.050] (II) modeset(0): Digital interface is DisplayPort
[ 46.050] (II) modeset(0): Max Image Size [cm]: horiz.: 26 vert.: 14
[ 46.050] (II) modeset(0): Gamma: 2.20
[ 46.050] (II) modeset(0): No DPMS capabilities specified
[ 46.050] (II) modeset(0): Supported color encodings: RGB 4:4:4
[ 46.050] (II) modeset(0): First detailed timing is preferred mode
[ 46.050] (II) modeset(0): Preferred mode is native pixel format and refresh rate
[ 46.050] (II) modeset(0): redX: 0.570 redY: 0.333 greenX: 0.325 greenY: 0.582
[ 46.050] (II) modeset(0): blueX: 0.160 blueY: 0.144 whiteX: 0.313 whiteY: 0.329
[ 46.050] (II) modeset(0): Manufacturer's mask: 0
[ 46.050] (II) modeset(0): Supported detailed timing:
[ 46.050] (II) modeset(0): clock: 76.4 MHz Image Size: 256 x 144 mm

Great right values but modeset later:
[ 46.060] (II) modeset(0): Using exact sizes for initial modes
[ 46.060] (II) modeset(0): Output eDP-1 using initial mode 1366x768 +0+0
[ 46.060] (==) modeset(0): Using gamma correction (1.0, 1.0, 1.0)
[ 46.060] (==) modeset(0): DPI set to (96, 96)
[ 46.060] (II) Loading sub module "fb"
yeah 96 dpi, WTF.

You can force the right dpi with xrand and some voodoo but because most if not all developers use wrong dpi it's likely to make your desktop unusable.

[juancho38]

Just for information :
The "Show Grid" checkbox feature under Chart Panel Options (lower right hamburger) DO WORK in OpenCPN 5.1.511 Beta Test on my Windows 10 pro system (virtualbox guest).

The depth font size is also suitable for me.

if it can help ...

[Moo]

Help,

I think somebody else commented on the help window up thread a bit. I find it very awkward at the moment. When I click through to help via the ? icon it opens is a more or less full screen window that can't be resized, or more importantly minimised. ALT+TAB doesn't work to switch back to the main OCPN window either.

This means that if you are trying to refer to help and try things in OCPN you have to keep closing help, trying stuff, clicking through to help again etc. etc.. All this agro would be solved if the window could be minimised.

Windows 10

[P_Dub]

I also noted that the Parallel and Meridian are not showing on vector charts.
Sorry, if I had not noticed it before.
Regards.

[hoolie]

I've now had O 5.1.511 crash completely. I changed the ship icon size to -4 or so as it didn't seem to be working, re-started O and ended up with a blank screen. Just the same after a restart and select "safe mode".

BTW I had the same thing happen with 5.1.428 as well though nothing to do with ship icon size.

[hoolie]

Further to my post above I have restored my .ini file to a back-up that works. Here are the .ini files, one that works and the other crashes

I can't see any major differences between them that would crash O

W10 1909 Pro and Intel 965 graphics

I confirm that changing the ship scale factor on my system has no effect

[hackswitch]

Hi all, Testing OCPN 5.1.51
Kubuntu 20.04

Plugins that load
oeRNC, oeSENC, VDR

Getting Errors on all other plugins

Branch = Master
Do I need to download diff plugin versions for this build or how do you build the deb pkgs for this version? Can someone point me in the right direction please and thank you.

Looking forward to getting RTL-SDR working as well a few other faves!
https://ibb.co/d53TbKL

[bdbcat]

hackswitch...


For the present, you will probably need to build locally the "legacy" plugins desired for Ubuntu 20.04. The PPA build of all legacy plugins for Ubuntu 20.04 is on the TODO list....


There will be ongoing additions to the managed plugin catalog as resources allow.


"Getting Errors on all other plugins"
What errors, please?


Thanks
Dave

[Ptizef]

Originally Posted by did-g

Linux graphic stack is a POS.For various brain dead reasons it's often forcing screen at 96 dpi, screwing actual size.

Yes ... Ok
So set to manual and enter the right value is the only solution.


xrandr return the right value ... but I do not know what to do of that.


JP

[Patg]

Personally I think soundings are important, so it's probably not so bad to display them a bit more 'prominent'. But somehow there is something wrong with the rendering, at least on MACOS.
It looks like the lower part of the digit is clipped by a few pixels. Can someone reproduce this ? I must admit that I use a home-built version of OCPN and not the current beta distribution, but it's more or less on the same git-commit.

[bcn]

Here on macOS no clipping...

[Rasbats]

I am trying to prepare for migration to the catalog mode of plugin distribution. This involves using 'GetPluginDataDir' instead of 'GetpSharedDataLocation()'. Worked with two plugins so far where 'GetPluginDataDir' displays icons correctly with 'OpenCPN 5.1.428' and 'OpenCPN 5.1.511' but not with 'OpenCPN 5.0.1' on Apple and 'OpenCPN 5.0.0' on Windows (Standard distribution, not own compilations).

Is this related:

The incorrect behavior where string literals can be implicitly converted to char* was allowed, but deprecated, in the C++98 (and C99) standards, but removed in the C++11 and C11 standards.

Is there a way of passing a string to 'const char*' which will keep 'OpenCPN 5.0.0 and 5.0.1' happy? I would like the compilations to use 'GetPluginDataDir' and work correctly with both '5.0.0/5.0.1' and '5.2' releases.

Mike

[hreuver]

Originally Posted by bdbcat

Are you saying that oeSENC_PI, v 4.0.10, for ARM64, available from the Release PPA, does not work for you using system fingerprint method?

I did not include the regular opencpn/opencpn in my PPA sources. Fixed for now.

I removed the .opencpn directory and installed oesenc-pi-4.0.10. After activating the plugin, the dialag greys out. To get a responce again I pressed Crtl-C (killing OpenCPN in the process).

If I install a chart using a working plugin and replace the plugin with 4.0.10 OpenCPN starts, but never shows a toolbar. If you guessed why I removed .opencpn ...

If I remember correctly I got the same behaviour with my self-compiled plugin before the ARM64 PR was applied.