Building and installing plugins on OS X

[Mollymawk]

Pavel,

Inspired by noticing that difference in framework versions, I tried the plugin in the newer beta. It works fine.

That said, presumably it is supposed to work in older versions of OCPN too?

~ Caesar

[nohal]

Caesar...

No, as you can see, we are changing the version of wxWidgets used, which means no backward compatibility is possible.
There won't be any "official" plugin builds targeting versions older than recent 3.3 betas and the upcoming stable release on Mac. Doing otherwise would be too messy.
The only way is forward, fixing those OpenGL problems you reported...

Pavel

[Mollymawk]

Originally Posted by nohal

Caesar...

No, as you can see, we are changing the version of wxWidgets used, which means no backward compatibility is possible.
There won't be any "official" plugin builds targeting versions older than recent 3.3 betas and the upcoming stable release on Mac. Doing otherwise would be too messy.
The only way is forward, fixing those OpenGL problems you reported...

Pavel

Ah, right. So I confused the issue by trying the plugin in an older beta, my mistake, sorry.
For now I will just use the newest beta with OpenGL disabled. (Works fine, thought it's hard to read small chart text since it's not antialiased.)

Forgive my ignorance, but is it really necessary for the plugins to so tightly integrated with the core app that they have to be linked against the same version of wxWidgets? Couldn't they be made more portable?

In a similar vein, is it necessary that the plugins be installed within the app bundle? Couldn't they be installed, say, in ~/Application Support/? That would save reinstalling them when updating OpenCPN.

[nohal]

Originally Posted by Mollymawk

Forgive my ignorance, but is it really necessary for the plugins to so tightly integrated with the core app that they have to be linked against the same version of wxWidgets? Couldn't they be made more portable?

Yes, it is necessary. As they run inside the same process, it is not technically possible for them to use different version of a library with the same symbols. Hard problem to resolve, look at the web browsers - even with their development resources it took them years to isolate the plugins...
And we change the wxWidgets version used just once in several years, so for a normal user this is virtually invisible.

In a similar vein, is it necessary that the plugins be installed within the app bundle? Couldn't they be installed, say, in ~/Application Support/? That would save reinstalling them when updating OpenCPN.

No it is not really necessary and actually I'm working on it already (for all the platforms, not just OS X). To be honest, I have no idea what "~/Application Support" is good for - my virtual Mac is still too new to me, but some place in the user's home it will be.

Pavel

[Mollymawk]

Originally Posted by nohal

No it is not really necessary and actually I'm working on it already (for all the platforms, not just OS X). To be honest, I have no idea what "~/Application Support" is good for - my virtual Mac is still too new to me, but some place in the user's home it will be.

I'm sorry, I meant to say "~/Library/Application Support/".

~/Library/ is the subfolder of the user's home dir that contains preferences, application resources, system extensions etc which are specific to that user. It is divided into subdirectories, so for example preferences go in ~/Library/Preferences/ - as you probably know, since OCPN's preferences file is correctly saved there. (But it is incorrectly named, for what it's worth, since preferences files should be named in reverse dns format - ie org.opencpn.ini rather than just opencpn.ini. Also, normally the preferences file is a plist, but there's nothing wrong with using another format - although it's very odd to see the Windows .ini extension on a Mac; I would be more comfortable with the .conf extension as used on Linux for the same file.)

~/Library/Application Support/, then, is the directory where (per-user) application resources such as plugins should go - in a subdirectory named after the app. OpenCPN already keeps its chartlist there, at ~/Library/Application Support/OpenCPN/Chartlist.dat. Plugins could go in ~/Library/Application Support/OpenCPN/plugins/, to keep it tidy.

Note, though: if plugins are considered to be system-wide, rather than per-user - as they are at the moment by default, since they're inside the app bundle - you would need to put them in /Library/Application Support/, instead. I'd argue this might make more sense.

Incidentally, there's a slight inconsistency in that on Windows, the preferences and chartlist are system-wide, whereas on Mac they are per-user. I can't recall where they are on Linux. I don't know which is the "right" way...

[CarCode]

Caesar,
there are guidelines available from Apple but because no one of the developers has a Mac nobody ever read them. Also the frameworks of a bundle should not reside in the bundle folder "MacOS" but in the "Frameworks" bundle folder. This works somehow but is not state of the art. Moreover several plugins do have supplementairy files and these files are spread anywhere on the system.
Another playground is wxWidgets. I have pointed out years ago that version 2.8.12 does not work with 64-bit Mac OS X. OK, at that time no stable release of a newer wxWidgets version was available especially for Mac OS X which is still in development. Even the latest wxWidgets version 3.1.0 has still some issues on the Mac OS X port.
So this all said OpenCPN for Mac OS X is rather poor despite the fact that it is the second most used OS after Windows on desktops.
Mac OS X 6.4%
Linux 1.6%
Windows 92%

Gerhard

[CarCode]

Caesar,
please see my comment in your flyspray commit.
Gerhard

[Mollymawk]

Originally Posted by CarCode

Caesar,
there are guidelines available from Apple but because no one of the developers has a Mac nobody ever read them. Also the frameworks of a bundle should not reside in the bundle folder "MacOS" but in the "Frameworks" bundle folder. This works somehow but is not state of the art. Moreover several plugins do have supplementairy files and these files are spread anywhere on the system.
Another playground is wxWidgets. I have pointed out years ago that version 2.8.12 does not work with 64-bit Mac OS X. OK, at that time no stable release of a newer wxWidgets version was available especially for Mac OS X which is still in development. Even the latest wxWidgets version 3.1.0 has still some issues on the Mac OS X port.
So this all said OpenCPN for Mac OS X is rather poor despite the fact that it is the second most used OS after Windows on desktops.
Mac OS X 6.4%
Linux 1.6%
Windows 92%

Gerhard

Any app which uses frameworks like wxWidgets instead of the native UI frameworks will always be a second class citizen on OS X.

That said, fortunately OCPN's functionality works well on OS X (well, until the latest beta) which is more important than appearances.

I'm surprised by those statistics, those are about the market share stats of each OS but I thought Linux would be much higher in the marine navigation computer area.

I have responded to your comment on FlySpray.

[seandepagnier]

Originally Posted by Mollymawk

Any app which uses frameworks like wxWidgets instead of the native UI frameworks will always be a second class citizen on OS X.

wxwidgets uses native controls when possible which should make the application behave as a native one, as opposed to something like qt which does it's own rendering.

That said, fortunately OCPN's functionality works well on OS X (well, until the latest beta) which is more important than appearances.

I'm surprised by those statistics, those are about the market share stats of each OS but I thought Linux would be much higher in the marine navigation computer area.

For opencpn based on download statistics, it is about 75% windows and osx and linux split the remaining 25%

Maybe you can try this patch and comment out the following test to apply the logic to all cards on osx, not only intel. Maybe it fixes some of the opengl problems?? Does opengl work with vector charts like cm93?

diff --git a/src/glChartCanvas.cpp b/src/glChartCanvas.cpp
index c8e8987..fd53f5c 100644
--- a/src/glChartCanvas.cpp
+++ b/src/glChartCanvas.cpp
@@ -1046,7 +1046,7 @@ void glChartCanvas::SetupOpenGL()
 
     s_b_UploadFullCompressedMipmaps = false;
 #ifdef __WXOSX__    
-    if( GetRendererString().Find( _T("Intel GMA 950") ) != wxNOT_FOUND )
+//    if( GetRendererString().Find( _T("Intel GMA 950") ) != wxNOT_FOUND )
         s_b_UploadFullCompressedMipmaps = true;
 #endif

[seandepagnier]

Originally Posted by nohal

Caesar...

No, as you can see, we are changing the version of wxWidgets used, which means no backward compatibility is possible.

Pavel

I noticed that opencpn crashes if the plugin is compiled with a different wxwidgets version, at least on linux when opencpn is using wx-3.1, and a plugin uses wx-2.8 for example. Maybe we can put a helper function in the plugin to allow opencpn to detect the toolkit version to avoid this problem and also to be able to inform the user?

As far as different toolkits (wxgtk vs wxqt on the same system) there is no problem, and no crashes, it simply doesn't load the plugin.

[nohal]

Originally Posted by boat_alexandra

I noticed that opencpn crashes if the plugin is compiled with a different wxwidgets version, at least on linux when opencpn is using wx-3.1, and a plugin uses wx-2.8 for example. Maybe we can put a helper function in the plugin to allow opencpn to detect the toolkit version to avoid this problem and also to be able to inform the user?

As far as different toolkits (wxgtk vs wxqt on the same system) there is no problem, and no crashes, it simply doesn't load the plugin.

Sean...
I have actually never tried this scenario. But the checks already there seem to work fine in the opposite case when you try to load a plugin built against a newer version into the core built against the old one...

Pavel

[Mollymawk]

Originally Posted by boat_alexandra

wxwidgets uses native controls when possible which should make the application behave as a native one, as opposed to something like qt which does it's own rendering.

Well... all I can say is I guess it's not 'possible' very often! Yes, it uses system widgets for buttons, textfields, etc, and system save/open dialogues. Yes, it's far better than qt. No, it's not close to looking or behaving like a native app...

Originally Posted by boat_alexandra

Maybe you can try this patch and comment out the following test to apply the logic to all cards on osx, not only intel. Maybe it fixes some of the opengl problems??

I haven't managed to build OpenCPN yet, but when (if) I do I'll try that.
(Or if you would like to create a build containing that code I will be happy to try it out.)

Originally Posted by boat_alexandra

Does opengl work with vector charts like cm93?

Yes, it works ok. The problem is only with raster charts (BSB format).

[Mollymawk]

I discovered some new 'symptoms' of the OpenGL bug (reported on flyspray).

This bug does not happen when zoomed in to a scale factor of about 1.5x or more on each chart. (As measured in non-quilting mode, with the scale indicator in the status bar.)

It always happens when the scale is 1.4x or less.
At 1.5x and 1.6x it is usually ok but not in all areas/on all charts.
I have never seen a problem at 1.7x or more

Is there different code for handling higher zoom levels?

[seandepagnier]

I'm fairly sure it is mipmap related, so yes, the zoom level matters. The problem is apparently many opengl drivers on osx do not follow the opengl spec (as you can see from the source dave already encountered this with his intel graphics), and as a result the workaround uses much more video memory and also makes the program run much slower unfortunately. The same is true on opengles, but that actually is part of the spec.

There _is_ a better solution, one which I intend to implement (manual mipmapping) which actually improves speed and memory use even on compliant drivers, as well as will work on all the drivers, but the software is a little bit complicated to do in the best possible way, so it will probably have to wait until after the next stable release (I also fear fallout)

The patch I posted before should fix the problem at least, once you build from source.

[Mollymawk]

Originally Posted by boat_alexandra

Maybe you can try this patch and comment out the following test to apply the logic to all cards on osx, not only intel. Maybe it fixes some of the opengl problems?? Does opengl work with vector charts like cm93?

diff --git a/src/glChartCanvas.cpp b/src/glChartCanvas.cpp
index c8e8987..fd53f5c 100644
--- a/src/glChartCanvas.cpp
+++ b/src/glChartCanvas.cpp
@@ -1046,7 +1046,7 @@ void glChartCanvas::SetupOpenGL()
 
     s_b_UploadFullCompressedMipmaps = false;
 #ifdef __WXOSX__    
-    if( GetRendererString().Find( _T("Intel GMA 950") ) != wxNOT_FOUND )
+//    if( GetRendererString().Find( _T("Intel GMA 950") ) != wxNOT_FOUND )
         s_b_UploadFullCompressedMipmaps = true;
 #endif

Commenting out that line does solve the problem - IF, and ONLY IF, I also enable "Texture Compression with Caching" in the options.

Obviously that's not the default setting so not a full fix to the problem, but hopefully it helps to find a real fix.

(Also, enabling "texture compression with caching" causes other, more minor rendering issues - slightly pink-tinted areas of chart. See attached screenshot.)