Building on Mac El Capitan

[AuroraGH]

Originally Posted by CarCode

First the documentation at Compiling - Mac OS X | Official OpenCPN Homepage
should be deleted. It is several years old, e.g., a Xcode version 4.6.3 is not available anymore. Actually it is Xcode version 7.3.1.

Furthermore I pointed out here already years ago that the wxWidgets port for Mac is still under development even until today. WxWidgets might work well for Windows and Linux but not for Mac OSX....

Gerhard

That did it.

I agree with you on wxWidgets - it sux on the Mac and it is missing from ios devices. Sadly it is so tightly coupled to the code that the functionality is all mixed up in the presentation.

I would be willing to contribute effort to a branch that refactored OpenCPN to remove wx dependencies from core code (switch to std::string from wxString, stl collections, etc) and isolate the UI from the core as a set of services, if we could get some volunteers. With that done, other front ends could be put on it - including web services so you could do a front end in the browser using leafletjs and WebGL (which is crazy powerful these days), build a proper native UI, or even use the code in Xamarin (which is looking better than wx although you have to build UI in C#).

Point being to separate the UI from the application services and eliminate dependencies on wx in the services.

[CarCode]

Originally Posted by AuroraGH

That did it.

I agree with you on wxWidgets - it sux on the Mac and it is missing from ios devices. Sadly it is so tightly coupled to the code that the functionality is all mixed up in the presentation.

I would be willing to contribute effort to a branch that refactored OpenCPN to remove wx dependencies from core code (switch to std::string from wxString, stl collections, etc) and isolate the UI from the core as a set of services, if we could get some volunteers. With that done, other front ends could be put on it - including web services so you could do a front end in the browser using leafletjs and WebGL (which is crazy powerful these days), build a proper native UI, or even use the code in Xamarin (which is looking better than wx although you have to build UI in C#).

Point being to separate the UI from the application services and eliminate dependencies on wx in the services.

Correct.
Years ago there have been several people which tried to do so without success. There have been one who tries to rewrite to Objective-C, another one tries Qt. They all gave up because it is too time consuming.
The actual code is gathered together from several open sources in C or C+ and often based on outdated C-compiler versions. So where to begin?

Gerhard

[dwoodall]

Originally Posted by rgleason

This is getting pretty complicated, I guess we need a rewrite. Has the whole Mac world moved onto El Capitan? Does the OS version matter to compiling OpenCPN? It appears so, from reading.

Who can rewrite this?

Originally Posted by AuroraGH

That did it.

I agree with you on wxWidgets - it sux on the Mac and it is missing from ios devices. Sadly it is so tightly coupled to the code that the functionality is all mixed up in the presentation.

I would be willing to contribute effort to a branch that refactored OpenCPN to remove wx dependencies from core code (switch to std::string from wxString, stl collections, etc) and isolate the UI from the core as a set of services, if we could get some volunteers. With that done, other front ends could be put on it - including web services so you could do a front end in the browser using leafletjs and WebGL (which is crazy powerful these days), build a proper native UI, or even use the code in Xamarin (which is looking better than wx although you have to build UI in C#).

Point being to separate the UI from the application services and eliminate dependencies on wx in the services.

I guess to put that in my perspective at least, you have three options if you want to write compiled cross platform code, wxWidgets, QT, or Xamarin. Their may be more, those are the ones I am familiar with. None of them are panacea's. It's rather like the saying goes about picking your poison. Xamarin is probably the most polished, but also definitely not free. Dev seats are something like $1K a year as I recall. QT AND wX are free. QT may have a larger user base since it is so prolific as an Android tool, but my very limited experience with it wasn't that great.

Since there are a lot folks here apparently fluid in WX, then I think it would be rather silly to try and move to something else.

Of course the other option is to write in something like Java. With the latest release it's speed seems OK and JavaFX is actually a decent graphics system (good enough that some game producers are moving to it). With all that said, I am not at all suggesting to re-write anything. I have looked a the guts of the OpenCPN code and it would be a monumental undertaking.

All I am suggesting is get on the current release of things as much as possible including wXWidgets and similarly move to v140 windows run-time because sooner are later v120 is going way just like win XP, 7, 8, and 8.1.
I would also suggest getting on Visual Studio 2015. It is a MUCH better tool and works fine with OpenCPN as well as everything else I have compiled with it and that is a fair amount of code covering all sorts fo things. I have uninstalled all my 2013 tools since on my older laptops I don't have the extra space for both. Also a huge plus if you want to support ARM 7 and 8, which 2015 does.

On the other hand, since I can rebuild everything to these, I really don't much care if they stay where they are. I do think that from a long term perspective, most projects are better off trying to stay up to date. So just take this as my $.02 worth from some one that that has written or managed more code than any person ought to have.

Regards,
Doug

[bdbcat]

AuroraGH....

I generally support the idea of further abstraction of OCPN core interfaces so that alternative UI models can be implemented. We have started down this path in baby steps by implementing the OCPNPlatform class, trying to isolate platform differences where critical.

I worry that the essential blocker to this effort will be performance. The chart class methods for display are closely tied to the UI model employed. Abstraction of that interface will really slow things down. You may recall (shows my age) that the original IBM PC had BIOS methods for abstracted graphics that no-one used, because they were too slow. Popular apps went directly to the graphics hardware. And no matter how fast processors get, we always want direct access to the graphics hardware.

OpenGL helps this situation a lot, but not all platforms that we need to support can run OpenGL. Some users just don't like it, and some chipsets (e.g. intel) just don't work well enough to use OpenGL.

Further, take a look at some average OCPN code. Probably one line in 10 refers to some native wxWidget class or interface. Many, perhaps most, of these references will directly translate to std and stl equivalents. But many won't, so we would either need to select another widget set with all the cross platform compatibility issues implied there, or roll a lot of our own code.
For example, lots of cool stuff is widely supported on linux platforms. But many things we need (e.g. SVG graphics, high performance XML parsing, etc.) do not exist as widely available interfaces or dlls on Windows, our top priority market. So we have had to leverage the broader wxWidgets community to get this stuff done, sometimes rolling our own.

So ultimately, I see your idea as a large, but not impossibly large, effort. With enough contributors and time, it could be done.

Having said all that, I would indeed like to see a fork of OCPN that heads off in this direction. Sometimes a giant step is really called for....

Regards
Dave

[CarCode]

Dave,
you are talking here about Linux and Windows. But the subject here is Mac OSX in particular its version El Capitan.
Other as operating systems like Windows or Linux the Mac people use the latest OSX version because they are for free. This is true even for iOS other than for Android where the manufacturers have problems to provide OS updates.

This said the better way would be to abandon the goal to have one code for all OS. Your Android adventure have shown you already the limitations. Its time to learn from your faults...

Gerhard

[AuroraGH]

I would stick to portable C/C++ for the core. That can be built and run on everything. With the core capability (and by core I mean anything that doesn't handle user events or draw to the screen directly) in C/C++. Anyone interested could build a Xamarin version(C# UI on Mac, Windows, iOS, and Android), a Mac version (Objective C++), an iOS version, or a web server version. The web server version I find kind of intriguing - it is what FreeBoard is doing with leafletjs.

WebGL is amazing. For a peek try poking around three.js - Javascript 3D library to see what can be done.

I don't care what specific UI used. If you read the Xamarin docs (and it is free these days for a certain level of support) - they punted on the UI and you write a separate UI for each platform but share core app code. All UI's are done in C# wrappers of native widgets. Not a huge fan of C# but someone might want to pick it up.

Regardless - I would focus on splitting display code from core code. As to the deep intertwining of utility classes - maybe we carve out some base wx classes and fork those and keep them. wxString, wxPoint, etc....utility classes that are truly platform independent.

For a name - I would maybe call it "Trident" (Neptune's big fork).

[rgleason]

Compiling - Mac OS X | Official OpenCPN Homepage

[CarCode]

A very simple example why I'm not satisfied the way OCPN does support Mac OSX in no way is this screenshot from the just released OCPN version 4.4.0. And there are a lot more...

It is time to establish a version for Mac OSX (now called macOS).

Gerhard

[AuroraGH]

I've created a fork at http://github.com/OpenTrident/OpenCPN

If folks want to contribute I will be taking pull requests and we can file issues on that repo. Any nice generic changes such as refactoring UI from core code, we can make pull requests back to OpenCPN and hopefully they will take them.

I think the first thing I would like to do is start working through the library targets like NMEA0183, SYMBOLS, S57ENC, determine their wx dependencies and make certain they do not rely on wxWidgets UI elements.

I would also start a wxCompat library for all the stuff I intend to carve out of wxWidgets that are too hard to eliminate from the code. For better or worse, I think we are stuck with wxString, the wx geometries (point, rect, etc...), some of the wx image manipulation stuff (which is coupled to wxUI elements so we might as well rip it into our compat lib or write compiler compatible replacements).

While I would love to replace that stuff, it is a LOT of work for a little gain and I think we just rip whatever code from wx out into our own library to make that stuff work.

So that's my game plan so far. Still pondering the best way to organize the code so we have separate build targets for various platform targets (wxWidgets, OSX, iOS, etc)

[dwoodall]

Originally Posted by AuroraGH

I would stick to portable C/C++ for the core. That can be built and run on everything. With the core capability (and by core I mean anything that doesn't handle user events or draw to the screen directly) in C/C++. Anyone interested could build a Xamarin version(C# UI on Mac, Windows, iOS, and Android), a Mac version (Objective C++), an iOS version, or a web server version. The web server version I find kind of intriguing - it is what FreeBoard is doing with leafletjs.

WebGL is amazing. For a peek try poking around three.js - Javascript 3D library to see what can be done.

I don't care what specific UI used. If you read the Xamarin docs (and it is free these days for a certain level of support) - they punted on the UI and you write a separate UI for each platform but share core app code. All UI's are done in C# wrappers of native widgets. Not a huge fan of C# but someone might want to pick it up.

Regardless - I would focus on splitting display code from core code. As to the deep intertwining of utility classes - maybe we carve out some base wx classes and fork those and keep them. wxString, wxPoint, etc....utility classes that are truly platform independent.

For a name - I would maybe call it "Trident" (Neptune's big fork).

I guess everyone has a different take on the C# vs C vs C++. My preference is C# for two reasons. First, I think it is a much better language than C++. There are a lot of reasons I think this but the top few on my list are no more .h or .hpp files, stronger typing and more apparent over rides. I find the language much more concise and far easier to read. The second reason is that msoft only supports desktop apps on C# now and that is where most of my work is. There are good C# compilers for every platform so I don't buy that C/C++ is more universal. Industry is rapidly shifting to C# and the amount of decent open source tools is astounding. Yes, there are a lot of open source tools for C/C++ but many have been abandoned so I wouldn't use them in a new project.

The latest version of .net includes many things that the current OpenCPN project uses third party software for.

As to cross platform, I think it would be worthwhile to take another look at Xamarin. I will admit it has been a few years since I last looked at it.

One idea that has always intrigued me is to write a Windows specific version of OpenCPN, get that working then migrate that to other platforms. I have no idea what the majority of OpenCPN users use in terms of OS, but my guess is the majority are windows users, but I could be way off on that. So, what I find intriguing about your idea of separating the functionality of the core from the UI is that it would be a great start on platform specific versions without using a "universal" UI.

At any rate good look with trying to separate wx from the core functionality. I think it will be a huge task. If I had time, I would help and will try when I do have time, but my schedule is really full these days.

Regards,
Doug

[CarCode]

Originally Posted by dwoodall

So, what I find intriguing about your idea of separating the functionality of the core from the UI is that it would be a great start on platform specific versions without using a "universal" UI.

I second a platform specific version e.g. for macOS. macOS comes already with Curl and sqlite. So wxcurl and wxsqlite are not needed at all.

Gerhard

[merrimac]

Speaking for myself, just out of a rewrite of the br24 radar plugin. most of the struggles are with wxwidgets. I just spent the day finding this out, again. But I don't see an alternative. C# doesn't work on macOS. Even if wxWidgets is bad on OSX it is better than nothing.

Decoupling from the UI means writing 40% of the code three times, I think the same will apply to OpenCPN core. Not really feasible.

Moving to another portability library is the only (but still bad) alternative imo.



Sent from my iPad using Cruisers Sailing Forum

[rgleason]

qtvlm uses qt. Nobody has mentioned that.

If you are going to rewrite for MAC, I hope the goal would be to have the core + Mac UI, so that others could use the core + win UI and core + Linux UI>

I hope opentrident thrives.

[dwoodall]

Originally Posted by merrimac

. C# doesn't work on macOS.

You might want to take a look at the MonoDevelop tool. It allows C#/.NET programs to be built and ran on MAC's. It is open source.

Regards,
Doug

[CarCode]

Proposing a language depends always on the person who did it, e.g., if he well know a language he will propose it...

Gerhard