OpenCPN Version 2.6 Beta Build 1723

[JesperWe]

Originally Posted by cagney

Dave
Torres Strait, Ebb Stream And Flood Stream running in opposite directions, but uses the same, unrelated, icon.

Really hard to do anything about. I tried a lot before I gave up.
The arrow itself is drawn as a line on the chart. It is NOT a symbol.
On the same pos as the arrow there is a general CTNARE with the current values as text in an INFORM attr. There is nothing linking the two. And no ATTR to distinguish this CTNARE from others, thus not possible to write a rule and get a better symbol.
/j

[JesperWe]

Originally Posted by cagney

Route with non mandatory to way traffic. Double arrows with some ?:s and !:s. Can we do better than this?

I'm afraid not. The question marks are there because the TWRTPT is missing the TRAFIC attribute, so we can't tell which way the arrows should really go.
The "!" are from the various caution areas defined here, they should be there.

Nothing new here really.
/j

[JesperWe]

Originally Posted by cagney

Route with non mandatory to way traffic. Double arrows with some ?:s and !:s. Can we do better than this?
Thomas

By the way, if the questionmarks are hurting your eye, you can always go to chartsymbols.xml line 2466 and change TWRDEF51 to TWRTPT52...

(But risking in this case to label one-way non-mandatory routes as two-way...)

/j

[CarinaPDX]

Dave and Freddie_

You seem to be rehashing some stuff I posted on another thread (http://www.cruisersforum.com/forums/...tml#post949618). The problem with the dylibs not showing up in the app bundle is the result of a change in behavior of cmake between 2.8.2 and 2.8.3. Cmake no longer automatically copies the plugin dylibs to the application bundle; that must be specifically called for now. And I have no idea how to do it...

On 10.6.x Snow Leopard the system libraries are "universal" in the sense that they are both 32 and 64 bits. This is quite different than the old meaning of "universal" which meant ppc and i386. When compiling on Snow Leopard the default is 64 bit IIRC. And the same goes for MacPorts. With Snow Leopard/Intel simply add the switch " +universal" to the install command and the build will be 32/64 Intel. (And yes, the +universal switch means something different on older OSes - thanks Apple for the confusion!)

Greg

[bdbcat]

CarinaPDX/greg...

OK, I'm reading the referenced thread. It seems like you did finally get a functioning base build (without plugins) on 10,6

Leave aside the PlugIn bundle for now. Its a distraction.

In the mainline: We seen to be building, loading, and linking to the system wxW dylibs ok. But we are crashing in the application, during a simple call to wxFont ctor.

Any idea what could be wrong? I suspect wrong wxWidgets libs.

You say:

"When compiling on Snow Leopard the default is 64 bit IIRC. And the same goes for MacPorts. With Snow Leopard/Intel simply add the switch " +universal" to the install command and the build will be 32/64 Intel."

Could you amplify, please? What "install" command do you mean? macports of wxWidgets?

It would be nice to nail this once and for all for wx2.8 and carbon, and document it in the Wiki, so that Mac developers can play with the existing OCPN code base.

Thanks
Dave

[CarinaPDX]

Sorry for the incomplete statement. Using Macports, installing wxWidgets is done from Terminal with a command line: sudo port install wxWidgets +universal (assuming not logged in as root). This will result in a file with both the 32-bit and 64-bit binaries, on Snow Leopard (10.6.x). Without the universal flag it will default to 64-bit only. I think this is a default in the compilers Apple provides in Xcode for 10.6. As noted above, the same command on an earlier version of OS X will result in a file with both 32-bit ppc and i386 binaries. Ridiculously confusing...

I am suspicious that if some dependencies exist in 64-bit only in MacPorts (the default) that the universal switch won't necessarily correctly rebuild the dependencies as universal. I only got things working by deleting the whole MacPorts directory and starting over using the universal switch for all ports that I installed. BTW it is easy to learn if an executable has i386 and/or 86_64: at the command line, use "file " followed by the filename and the results will include the architecture(s):

Pancho:A greg$ file Carbon
Carbon: Mach-O universal binary with 3 architectures
Carbon (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64
Carbon (for architecture i386): Mach-O dynamically linked shared library i386
Carbon (for architecture ppc7400): Mach-O dynamically linked shared library ppc

The current stable version of wxWidgets on MacPorts is 2.8.12_0. (The devel version is the 2.9.x fork.)

I am not having a problem with cmake and make; the make install has the noted plugin dylibs issue, plus a couple of install_name_tool errors, but is only failing as a result of fixup_bundle not finding the plugin dylibs if I understand correctly. The resulting app executes just fine, at least with a cursory check.

I hope this helps. I'll keep watching...

Greg

[JesperWe]

Originally Posted by P_Dub

On my S57 Charts have the current arrows of CHS pointing Northward and not in the direction that should be. Any idea what to do?

Yes. Fix it.

I missed two symbols that need vector drawing. I have forwarded the patch for inclusion in 3.0RC but if you want to test it:

diff --git a/data/s57data/chartsymbols.xml b/data/s57data/chartsymbols.xml
index a962a23..59570b6 100644
--- a/data/s57data/chartsymbols.xml
+++ b/data/s57data/chartsymbols.xml
@@ -33780,6 +33780,7 @@
                 <HPGL>SPA;SW1;PU685,1257;PD785,1058;PD884,1257;SPA;SW1;PU685,1073;PD785,874;PD884,1073;SPA;SW1;PU785,362;PD785,1270;SPA;SW1;PU684,611;PD786,364;PD886,611;</HPGL>
             </vector>
             <definition>V</definition>
+            <prefer-bitmap>no</prefer-bitmap>
         </symbol>
 
         <symbol RCID="1328">
@@ -34450,6 +34451,7 @@
                 <HPGL>SPA;SW1;PU785,362;PD785,1277;SPA;SW1;PU684,611;PD786,364;PD886,611;SPA;SW1;PU787,894;PD886,1099;SPA;SW1;PU787,1079;PD886,1277;SPA;SW1;PU785,1103;PD785,1161;</HPGL>
             </vector>
             <definition>V</definition>
+            <prefer-bitmap>no</prefer-bitmap>
         </symbol>
 
         <symbol RCID="1337">

[fgd3]

Originally Posted by bdbcat

fgd3....

OpenGL on Vista is not great. The problem relates to MS implementation of Aero compositor, and nobody is (or was) happy about it.

Try turning screen compositing effects off, and maybe OpenGL will work. If not, then legacy DC mode may be your best option.

Dave

What is "legacy DC mode"?

Fabbian

[JesperWe]

Originally Posted by fgd3

What is "legacy DC mode"?
Fabbian

What you get when you turn OpenGL off in the settings dialog.
/j

[fgd3]

Originally Posted by JesperWe

What you get when you turn OpenGL off in the settings dialog.
/j

OK. Thanks.

Fabbian

[fgd3]

Originally Posted by bdbcat

fgd3....

OpenGL on Vista is not great. The problem relates to MS implementation of Aero compositor, and nobody is (or was) happy about it.

Try turning screen compositing effects off, and maybe OpenGL will work. If not, then legacy DC mode may be your best option.

Dave

What do you mean by screen compositing effects? I tried turning off chart quilting. It had no effect. What other effects should I try disabling?

Fabbian

[CarCode]

Originally Posted by CarinaPDX

The current stable version of wxWidgets on MacPorts is 2.8.12_0. (The devel version is the 2.9.x fork.)
Greg

If you want to compile a 64bit OCPN version use wxWidgets 2.9.4 (not 2.9.3) which has some bug fixes for Mac OS X Cocoa.
Otherwise use wxWidgets 2.8.x for Mac OS X Carbon.

Always get the wxWidgets sources from wxWidgets.org
Installing MacPorts often results in unwanted side effects not foreseen by the average user.

Gerhard

[JesperWe]

Originally Posted by fgd3

What do you mean by screen compositing effects? I tried turning off chart quilting. It had no effect. What other effects should I try disabling?

Not in OpenCPN! Turn off the effects in Vista.

See for example here: http://www.sevenforums.com/tutorials...e-disable.html

[fgd3]

Originally Posted by JesperWe

Not in OpenCPN! Turn off the effects in Vista.

See for example here: Desktop Composition - Enable or Disable - Windows 7 Forums

Thanks again. I'll try it, but I'm satisfied that the fundamental answer it "It's a Vista problem."

Fabbian

[sbfreddie]

Originally Posted by bdbcat

CarinaPDX/greg...

OK, I'm reading the referenced thread. It seems like you did finally get a functioning base build (without plugins) on 10,6

Leave aside the PlugIn bundle for now. Its a distraction.

In the mainline: We seen to be building, loading, and linking to the system wxW dylibs ok. But we are crashing in the application, during a simple call to wxFont ctor.

Any idea what could be wrong? I suspect wrong wxWidgets libs.

You say:

"When compiling on Snow Leopard the default is 64 bit IIRC. And the same goes for MacPorts. With Snow Leopard/Intel simply add the switch " +universal" to the install command and the build will be 32/64 Intel."

Could you amplify, please? What "install" command do you mean? macports of wxWidgets?

It would be nice to nail this once and for all for wx2.8 and carbon, and document it in the Wiki, so that Mac developers can play with the existing OCPN code base.

Thanks
Dave

Dave:
Freddie here.
I've been working on this weird problem for days, and I though I would let you know what I have discovered.

1. I could not get O to work not matter what I did when using the built in WxWidgets libaries, it seems there are many that come with OS 10.6.8. (They are in usr/lib, Developer/SDK's, if you have fink there are also in sw/lib, and if you have macports it is in opt/lib) Needless to say that can be confusing. Also it seems that when I was compiling O the make log indicated that it was finding frameworks and not dylibs. This is a big problem for cmake, as it does not deal with frameworks on the Mac very well. If your interested in the details here are a few links to peruse:
CMake - OS X, SDL, Frameworks and Libraries
0012034: BundleUtilities can not fixup standalone executable on OS X - MantisBT
[CMake] Problem with QtTest Bundle Utility Example?
[CMake] OS X, SDL, Frameworks and Libraries
[CMake] BundleUtilities and super-build
[CMake] BundleUtilities (was RPATH on Mac)
[CMake] fixup_bundle, shared libs and Plugins
If think you get the gist of the problems.

2. So I bit the bullet and took the advice of CarCode, and CarinaPDX and created a build script to built WxWidgets (Both i386 from 2.8.12 and x86_86 from 2.9.4) from sources. And then pointed O to this build (i386) and it compiles and works. The plugins are still missing from the dmg build. The plugins are installed in the O that is in the build folder, but not in the O that is located in the build products folder or the dmg.
Yes there are three O's present in the build, the first is in the build folder, the second is in the build products folder, and then the dmg.

Here is the shell script to build WxWidgets from source if you would like to use or abuse it, have fun.Install_wxWidgets_2.8.12_Snow_Leopard.pdf
You'll have to convert it to txt and rename it with .sh in order to run the script. Put it in a folder and run with sudo like this:

sudo sh Install_wxWidgets_2.8.12_Snow_Leopard.sh.

It will download everything it needs (except wget) and build two versions of WxWidgets, an i386 version and a x86_64 version. You may reference the newly make wxwidgets on the command line to cmake as CarinaPDX suggested like this:

env PATH=/Users/xxx/xxx/wxwidgets_2.8.12/built_products/i386products/bin/:$PATH cmake

Maybe I'll continue building the script to build O with WxWidgets all at once, what do you think?

Thanks,
Freddie