search

OpenCPN / OpenCPN

A concise ChartPlotter/Navigator. A cross-platform ship-borne GUI application supporting * GPS/GPDS Postition Input * BSB Raster Chart Display * S57 Vector ENChart Display * AIS Input Decoding * Waypoint Autopilot Navigation
https://opencpn.org/
GNU General Public License v2.0
1.04k stars 495 forks source link

OpenCPN too monolithic to meet its own main objective #2354

Closed mgrouch closed 2 years ago

mgrouch commented 3 years ago

As OpenCPN objective says:

a. Opencpn was built with the following objectives in mind.

i.   Intended use as primary navigation interface for vessels
     with full-time HELM-VISIBLE navigational suites.

Modern helm chartplotters are mostly touchscreens. (Android like Raymarine Lighthouse, etc)

OpenCPN in its current architecture is a one process which should have been split into separate well defined executables. Currently it combines in itself:

It's very difficult to build a user friendly cockpit touch system (which was the primary objective) with current monolithic implementation.

This is based on my own experience of using OpenCPN as primary means to navigate in a sailboat cockpit and after comparing it with user friendliness on commercial products (Ex: Raymarine Lighthouse OS).

Thanks, -MG

nohal commented 3 years ago

Again? Really?

rgleason commented 3 years ago

Are you offering to help in some way? I have read that the most successful software is created by continual work in improvement which is the path that OpenCPN has taken.

If you really believe what you have writen, Is there some part of this big problem that you have presented that you can take on and fix? Really, what exactly is it that bothers you about the structure? Why is it a problem? Maybe you can fix that? This kind of discussion can burn many hours.

I think you are frustrated about something. So its time to spill the beans.. Dave has tried very hard to make the plugins work for secondary services, keeping just essential stuff in the main program, a program that started very simply. Looking back does not help, how to move forward is more useful and you've been helpful in that respect, but there are not enough programmer to do what you suggest and have a reasonable release schedule.

BTW Pavel programmed chartdownloader as a plugin, and at the last minute he wrapped it, so you are speaking to the choir here.

It sounds like you really like the Lighthouse interface.

mgrouch commented 3 years ago

Let’s say I’d like to build something user friendly for touchscreen as Raymarine Lighthouse.

I think OpenCPN is very advanced but not customizable enough.

All menus and control buttons for that need to be outside of OpenCPN.

I think it’s solvable with some additions. What if opencpn could be started with option something like —canvas-only.

And in this mode it would provide some kind of (well defined) tcp listener for all actions user can perform using UI. So that this UI can be written outside of OpenCPN in the way it is specific to the whole system.

Example. (Just basic one) MOB button. I want to have only one MOB button which will drop a marker in any chartplotter in the system AvNav, OpenCPN, Freeboard-SK.

Why would I have to have MOB buttons in each?

thanks

CarCode commented 3 years ago

Example. (Just basic one) MOB button. I want to have only one MOB button which will drop a marker in any chartplotter in the system AvNav, OpenCPN, Freeboard-SK.

Why would I have to have MOB buttons in each?

Why do you need to run three different programs?

nohal commented 3 years ago

@mgrouch I'm afraid you are attacking your problem from an angle that is somewhat unfortunate, demanding us to completely redesign the application without actually suggesting any solution to your, or anybody else's, problems.

You would probably meet less of a refusal if you, instead of demamanding specific substantial technological changes without even providing use cases for them, came with feature requests to implement those well defined protocols covering some well defined use cases. And perhaps, to give your stuff any chance of wider acceptance (as I understand the use case you provided here, you will have to demand the same type of changes in every single bit of software you decide to use), you might consider to first start incorporating support for your requirements in some widely accepted comunication and interoperability frameworks where they primarily belong, like SignalK.

balp commented 2 years ago

I kinda agree with all of you. Yes OpenCPN have grown a bit big. There always been a bit of an issue with the data model being a bit to spread out in the code. Running OpenCPN on multiple displays, is a hard issue to solve at the moment. It's related to this issue that the design is as it is. It's how all navigations software was designed when it was started. No one then hade multiple display's in there boats. Displays used to much electric power for it to be useable with many. Many of the parts to make a more free standing design is today close to be possible. But to put the effort into making this decoupling into work i think the idea needs to be discussed first. Starting work in this direction without having the current developers understanding the goal and liking they way it's going would be a bad idea. Then it's a fork and that is something we don't need. There are some good idea's in the OpenPlotter project, a tighter integration of signal-k might be a good way to archive some of the possibilities to split the installation more. OpenCPN is much easier to install and handle then OpenPlotter, and more versatile as it can run on any hardware. Imho OpenPlotter probably is better with out the UI and OpenCPN on the same hardware. As i changed boat this summer my old setup (OpenCPN on laptop, on the table to my port as overview, before taking off pushing the routes to my Garmin plotter straight in front of me at the helm, zoomed to details) doesn't work any more (was a 7m cabinboat. Now with a 31" sailboat. I have the navigation station down below. With a tiller in the cockpit, I have no real natural place to fit a screen and as the cockpit now it outside, the laptop well it's to way it needs to stay inside. At the moment a iPad, sadly not supported by OpenCPN. An OpenPlotter connected to the old Nexus-hub and Garmin GPS (not plotter) inside. Mostly this signal-k network been able to give boating app nav-info. What i have learned so far, 7" OpenPlotter/OpenCPN touch screen, not fully useable, needs the mouse/keyboard. The screen is kind of to small for planning, and impossible to see while sailing. Track planning syncing from laptop to an other instance of OpenCPN is to much manual work.

What is my design feelings then? First it be nice is there was a way to share routes, waypoints and the planning information as simple and clean as signal-k. Using signal-k as input splits away many of the original posters items into separate programs. Openplotter is the closest thing to be a simple install of the system. There are limitations in signal-k, such as multiple positions sources are not really seamless, it isn't for handling waypoints, and planning. I like the idea that one doesn't save stuff, it's just updated and spread in real time to all viewing instances, this boils down to the internal data-storage model. Maybe the plugin interface can be used to make the synchronization.

As some of the steps might need a bigger rework, having the other developers and especially Dave in on the idea and the goal is a must. If the goal isn't shared the work will end up in two projects and one will die, both suffering during the time. For the this to happen clean and relevant usecased for the new design is needed. Some parts are already there with signal-k some are still not easy. Marine environments and vendor lock in, is a hard opponent for making open solutions work on the boat. Just building a weatherproof 10"+ display for the cockpit is a major task in it self.

mgrouch commented 2 years ago

What i have learned so far, 7" OpenPlotter/OpenCPN touch screen, not fully useable, needs the mouse/keyboard. The screen is kind of to small for planning, and impossible to see while sailing.

@balp Instead of installing Openplotter you could try installing this BBN OS. https://bareboat-necessities.github.io/my-bareboat/bareboat-os.html

It doesn't have usability issues with touchscreen like Openplotter. It installs much faster and easier and has more software than opencpn. Two finger zoom works in OpenCPN. Long touch works as right click. Two finger touch also works as right click with first touched finger being point on right click (for entering waypoints). The screen layout is more optimized for touch. There are desktop icons to launch programs like on iPhone, or Android.

OpenCPN, SignalK, AvNav, Pypilot come pre-configured to talk to each other. You would only need to add connection for your NMEA network into Signalk and all programs will start displaying data from it right away.

It's more modern design than Openplotter.

Thanks, --MG

rgleason commented 2 years ago

@bdbcat As Alec says "This is not actionable" so it does not belong in Issues. Perhaps it could be a discussion, but not here. Can this be moved to Discussion ? I can't do that.

mgrouch commented 2 years ago

Users opinion matters. It looks like they are willing to pay for a commercial software/hardware for user GUI experience and use SignalK for multiplexing and data collection and a cheap raspberry pi server to get the feed from all sensors.

mgrouch commented 2 years ago

There is got to be some wow factor. Lets say show 3D flyby entrance into a marina. There are depth sounding in the chart. It can be done with OpenGL

mgrouch commented 2 years ago

It's hard to compete with a system written in C++ where code refactoring is difficult. C++ should provide the high performance core of drawing the canvas, and might be the gauges. And it should provide an open protocol how to control what is displayed and what actions user can take. This protocol should be open and easy to use. Then there is going to be a lot of other projects built on top of that, With much better user UI and experience. I do not think it requires rewrite of OpenCPN. It requires an addon (open protocol and an option to just draw a canvas where user/client software asks for it) and open protocol how to send all user or data events commands to the canvas. Might be SignalK like.

balp commented 2 years ago

I’m pretty sure the commercial plotters use C, C++ from there recruitment adds. There are good tools and refactoring of C++ isn’t that hard. Doing a major architecture change of an application like OpenCPN is, especially so with the distributed loosely connected team as this.

The main difference I see is the number of skilled UX and graphics people. The UX in OpenCPN isn’t terrible. But could improve, same with the general looks it’s ok but could be polished and these experts tend not to work on Open source projects. On 5 Oct 2021, 05:38 +0200, Mikhail Grushinskiy @.***>, wrote:

It's hard to compete with a system written in C++ where code refactoring is difficult. C++ should provide the high performance core of drawing the canvas, and might be the gauges. And it should provide an open protocol how to control what is displayed and what actions user can take. This protocol should be open and easy to use. Then there is going to be a lot of other projects built on top of that, With much better user UI and experience. I do not think it requires rewrite of OpenCPN. It requires an addon (open protocol and an option to just draw a canvas where user/client software asks for it) and open protocol how to send all user or data events commands to the canvas. Might be SignalK like. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

rgleason commented 2 years ago

I still believe this "Issue" should be moved into the "Discussion" basket, under "General". Would someone who has those permissions please make that move?

rgleason commented 2 years ago

Found this https://docs.github.com/en/discussions/managing-discussions-for-your-community/moderating-discussions#converting-an-issue-to-a-discussion

rgleason commented 2 years ago

Copied M. Grouch post to "Discussions" here https://github.com/OpenCPN/OpenCPN/discussions/2449 and have a link back to this Issue.

Can we please close this now and use the Discussions topic?

mgrouch commented 2 years ago

Yes we can

Sent from my iPhone

On Oct 21, 2021, at 9:38 PM, Rick Gleason @.***> wrote:

 Copied M. Grouch post to "Discussions" and have a link back to this Issue.

Can we please close this now and use the Discussions topic?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.