OpenCPN Version 4.0 Released

[Wrong]

Originally Posted by bcn

Wrong,

what does your "Physical Screen Width" (under Display/Advanced) say?
What happens if you play with that value?

Hubert

In the Display, Advanced settings module under Chart Display none are checked.
'Chart Zoom/Scale Weighting = 0 Changed the level to 2 with no effect.
'Physical Screen Width = Auto
'OpenGL = Off

Thanks.

[bcn]

Wrong,

in the log the width discovered by "auto" will appear. Does this value make sense?
And if you choose "manual" and enter the actual size (landscape)?

Hubert

[Wrong]

The central question is:

Why do waypoints, marks and ownship appear when OpenGL is enabled, but do not in 'normal' mode?

And, why has this problem been progressive with each version of OpenCPN?

From my perspective, it can only be explained by changes to OpenCPN that affects the 'normal' mode.

Linux is linux, whether run in a chroot environment or not. The only difference, which exists between different desktop and laptop computers is the cpu; and linux written to operate on an arm device is really no different in this respect to how linux works.

Until recently, OpenCPN has been demonstrated to run normally on arm devices in a chroot environment without these problems. It has been demonstrated that OpenCPN can use internal and external usb gps using android applications. I expect this is most likely true with AIS and other external devices provided they can connect through usb, wireless or bluethooth.

So, aside from the need to employ android applications to bridge the API divide between linux and hardware, OpenCPN should run no differently now than it did before.

I suspect this has something to do with tablet oriented additions/changes to OpenCPN...

[RhythmDoctor]

As already requested, check the log file and tell us what it reports for "Detected display size." Compare this with your measured width in mm. If it does not match up, go into Options and manually enter the correct value. Also, do some experiments with different incorrect values.

The optional manual entry of display size was added to improve performance on tablets, but it is also used for (and useful for) correcting other problems resulting from erroneous display sizes that are reported by the OS. Since you are running an OS that was not designed for the hardware, you need to consider that such an error may be happening.

I was able to duplicate some of the issues that you described by manually entering a display size that was much smaller than my correct size.

[Wrong]

Originally Posted by RhythmDoctor

As already requested, check the log file and tell us what it reports for "Detected display size." Compare this with your measured width in mm. If it does not match up, go into Options and manually enter the correct value. Also, do some experiments with different incorrect values.

The optional manual entry of display size was added to improve performance on tablets, but it is also used for (and useful for) correcting other problems resulting from erroneous display sizes that are reported by the OS. Since you are running an OS that was not designed for the hardware, you need to consider that such an error may be happening.

I was able to duplicate some of the issues that you described by manually entering a display size that was much smaller than my correct size.

Nothing to do with the O.S. and hardware. Otherwise why were there no problems for nearly three years? This isn't my first rodeo.

actual screen width is1280 px = 339 mm vs. 433 mm detected
opencpn.conf reflects the manual setting @ 339 mm but the log continues to report a detected size of 433 mm.
No change...

The other thing you need to consider is the vnc application is set to 1280X800 which actually determines the 'fit'. This may be the source of the problem, introducing a feature into OpenCPN that controls display size when it ain't compatible with linux running in a chroot environment and the desktop displayed via the vnc. Has no effect but to screw up using recent versions of OpenCPN in a chrooted linux.

Also, considering the only other tablet platform is windows, just how transferrable are changes being made going to be with a linux chroot installation? You and others may not see it this way, but development of OpenCPN has taken a Windows centric turn for the worst. Funny that OpenCPN first ran on an android tablet per my effort - spanning a period of at least 2.5 years - before a Windows tablet was even available. Just doesn't seem right. But, as usual, I'm probably Wrong...

[RhythmDoctor]

The detected display size will always be the same, no matter what override value you manually input.

...Has no effect but to screw up using recent versions of OpenCPN in a chrooted linux...

If you read over the beta threads, it will be clear why the new code was inserted to detect the size of the screen. "Has no effect but to screw up..." is a gross misrepresentation. The change improved a number of things, including reporting the correct scale of the charts. You can now measure distances on the screen with a ruler if you choose. These things were not specific to Windows, Linux, or Mac - they improved all three platforms. Going forward, as pixel density gets higher and higher in retina displays (and Apple's competitors on the Windows/Linux side), the OpenCPN is going to need to continue determining pixel density and adjusting the size of objects accordingly. This will also be true in the Android world, where pixel density is also increasing.

I don't see any conspiracy to intentionally break your configuration. But adding VNC as another virtual hardware layer does add an element of complexity that could potentially lead to problems as the program changes. It's up to the development team whether to support fixes as those problems come up. But these changes initially cause unintended problems on ALL platforms, and they can only get fixed if there are people who are willing to report them in a way that makes the developers feel like their work is appreciated.

[Wrong]

Originally Posted by RhythmDoctor

The detected display size will always be the same, no matter what override value you manually input.
If you read over the beta threads, it will be clear why the new code was inserted to detect the size of the screen. "Has no effect but to screw up..." is a gross misrepresentation. The change improved a number of things, including reporting the correct scale of the charts. You can now measure distances on the screen with a ruler if you choose. These things were not specific to Windows, Linux, or Mac - they improved all three platforms. Going forward, as pixel density gets higher and higher in retina displays (and Apple's competitors on the Windows/Linux side), the OpenCPN is going to need to continue determining pixel density and adjusting the size of objects accordingly. This will also be true in the Android world, where pixel density is also increasing.

I don't see any conspiracy to intentionally break your configuration. But adding VNC as another virtual hardware layer does add an element of complexity that could potentially lead to problems as the program changes. It's up to the development team whether to support fixes as those problems come up. But these changes initially cause unintended problems on ALL platforms, and they can only get fixed if there are people who are willing to report them in a way that makes the developers feel like their work is appreciated.

The way you make it sound, I must be the only user of OpenCPN, regardless of platform who've never had issues with screen settings.

I think it's a bit disengenuous to suggest these changes primarily, originally have anything to do with correcting displays across the board. It has been driven due to problems displaying OpenCPN on Windows tablets. Ironically, my 'too difficult for the average joe installation' of linux and OpenCPN on androids has none of the problems these changes are supposed to resolve. The changes are however making it impossible to use OpenCPN updates on androids...

You've got a Windows version of OpenCPN, so why not restrict these experiments in using Windows tablets to it? Why apply it accross the board?

I hardly believe having a ruler to measure with would have required anything more than a plugin.

Finally, I think trying to get ahead of the game where anticipated hardware development is concerned is a fool's errand. Focusing on more dense pixel displays - anticipated to arrive in the future - is hardly relevant in trying to keep OpenCPN useable for everyone as an aid to navigation.

[seandepagnier]

I think it's time to update the plugin download page. The plugins that required latest beta can finally be moved to the top for version 4.0

[bdbcat]

Wrong...

Well, I guess I am an average Joe, because Linux Deploy did not work for me. Nicely rooted Android 4.x tablet, otherwise works fine. Linux Deploy refused to download and configure any linux image, no logfile, no help screens, no nuthin. Just "Updating configuration...done..." Over and over...

I have another tablet that runs debian natively, using a custom boot image and sdcard. LXDE desktop. No OpenGL capability. I built O4 on this tablet using the current github master and native GNU tools. Ownship displays just fine. No problems observed in quick test.

So, I'm stumped.

Any hints?

Thanks
Dave

[Gilletarom]

Hello Dave, Hello Anyone,

Windows 7 starter.

I use a VDR file for a simulated navigation.

During this voyage, I place a MOB. (With Ctrl Space)

THEN:

The route announced by the wiki is created,
The route is activated
It deactivates immediately.

Idem with OpenGL ON or OFF

Am I alone in this?

Thank by advance. Gilletarom.

[wdkester]

Unwanted route point names

1. Create a 2 point route (the "Show name" box will not be checked)
2. Export the route
3. Delete the route
4. Import the same route. The Show name box will be checked for the two points and the points will be shown as "1" and "2".

Several possibilities here:
1. Some setting causes this to happen. If so what is it?
2. Some command can undo it. If so what is it?
3. I'm doing something incorrectly.
4. It shouldn't be happening.

The issue is that, in crowded situations, unwanted route point names can hide important information e.g. soundings, buoy numbers, obstructions, etc. After loading a 150 point route (Hudson River from Troy to NYC) checking for problems is not fun.

[bdbcat]

wdkester...

This behaviour is by design. The idea is that import and export of routes is not a frequent thing, generally. And we want to see all the info from "foreign" routes coming into OCPN. There really is not much reason to export and then re-import a route into O. If it is not wanted on the screen, just hide it in the RouteManager.

We could have some config option to change this behaviour. We don't have that now, since this change in import policy happened after the GUI feature freeze for O4.

Please add to the Flyspray tracker for the next version.

Thanks
Dave

[nohal]

Dave...
It already exists in FS#1667 : Waypoints visibility attributes not exported
I think I have an idea for this, will elaborate in that task.

Pavel

[houlejm]

Originally Posted by bdbcat

wdkester...

And we want to see all the info from "foreign" routes coming into OCPN.

Thanks
Dave

Dave

We are not talking about a "foreign" route. That route was exported from O with OpenCPN extensions. I cannot see what important info can be hidden in a waypoint name.

Thanks
Jean-marie

[Wrong]

Originally Posted by bdbcat

Wrong...

Well, I guess I am an average Joe, because Linux Deploy did not work for me. Nicely rooted Android 4.x tablet, otherwise works fine. Linux Deploy refused to download and configure any linux image, no logfile, no help screens, no nuthin. Just "Updating configuration...done..." Over and over...

I have another tablet that runs debian natively, using a custom boot image and sdcard. LXDE desktop. No OpenGL capability. I built O4 on this tablet using the current github master and native GNU tools. Ownship displays just fine. No problems observed in quick test.

So, I'm stumped.

Any hints?

Thanks
Dave

First Dave, I'm honoured by you giving it a go.

Which tablet and android version of 4.* are you using?

I don't delve much into the rooting process in my instructions because they differ considerably. I assume the developers are pretty thorough when explaining SuperSu settings. But, maybe not.

Depending on your version of android, SuperSu is either installed seperately from the ROM, or as in the case of Cyanogenmod included in their custom ROMs along with a 'Privacy Guard'.

Access by applications to system files is controlled by SuperSu. The Privacy Guard is used to prohibit applications from accessing your 'private data'. Both are user controlled.

If the rooting process you used required you install SuperSu seperately there will be a SuperSu icon on the android desktop where all applications reside, not your customized desktop where you've placed frequently used applications.

Tapping on the icon opens the SuperSu app. Go to the settings. Scroll Waaaay down toward the bottom until you see something akin to 'enable SuperSu Pro'. Enable this option. Right, you don't need to buy the Pro version because while the developers appreciate people who do, they also realize the indespensible need by owners of rooted devices to use the app.

In Cyanogenmod's Custom ROMs, the SuperSu and Privacy Guard options are accessed through 'System Settings', typically opened by tapping on a gear type icon...

If Privacy Guard is enabled for Linux Deploy, it may not work. And of course, SuperSu must be installed with the 'Pro' version enabled.

Whenever an app requiring access to system files is opened the first time, SuperSu will appear asking you what to do. Grant or Deny access to the app? Permanently, or for some pre-determined amount of time? If this did not happen when you first opened, or tried to do something with Linux Deploy that required access to system files, it's most likely related to my discussion above.

Which tablet is running linux natively?

If this doesn't resolve your problem come back and I'll help to get it going for you...