Feature Requests

[Mr. S]

Originally Posted by nohal

As far as I can tell, the fact that we use wxQt in the Android port did not bring us any closer to replacing wxWidgets with Qt, the task is still enormous. Do you want to undertake this adventure?

I can't do it completely alone. I'll need some help but I would give it a try.

Originally Posted by nohal

There was such an effort once, probably ready to be picked up and completed from https://github.com/ktec/osm_pi

Cool, ! I'll have a look on it and compile it for 4.1.x.

[CarCode]

Originally Posted by Mr. S

I can't do it completely alone. I'll need some help but I would give it a try.

You are not the first one who has tried this and given up...

Gerhard

[seandepagnier]

Originally Posted by Mr. S

I can't do it completely alone. I'll need some help but I would give it a try.

I worked on the wxQt port to make opencpn usable with it (enabling android) as this was the shortest path for now.

Long term, I see a different path. If we can discard all of the non-opengl drawing (and ensure opencpn works well enough with a packaged software opengl rendering layer which requires a little bit of work, and possibly some hacks) then we would save a lot of time in development and testing as we have two rendering backends instead of one right now, and already they are diverging (many things are impossible without opengl)

Once opengl is the only rendering required, we have only to port the ui dialogs (mostly options settings etc) and some things with networks sockets to discard wxwidgets completely. The rest is more or less trivial.

But if we simply go to Qt with the same interface, it really seems like a pointless effort to me because we will gain nothing. Also, while it may seem that most applications are Qt these days, I think there is an advantage to avoid it if we have the chance.

Or at least built opencpn into a basic program without any dialogs or gui. Still completely usable but requiring editing the config file to operate. This would be a lean version with minimal dependencies and little ram or cpu usage and quick startup time.

Then provide the settings dialog via a plugin which loads a gui toolkit to provide it. Already we are seeing android specific settings etc... so eventually this type of approach offers more flexibility.

So I see a different path where, maybe we make it possible for plugins to choose and use a toolkit either wxwidgets qt or whatever they want to use. They can easily be written also in any programming language. Maybe they don't need any toolkit, or several etc...

[bdbcat]

All...

I cannot see any compelling reason to move to Qt. But I can be trained.

Anyone have a short list of reasons why Qt will ( or should ) be better than wx for OpenCPN?

Dave

[CarCode]

I only can speak for Mac OS X. Qt is well developed for OS X however wx is still in an early beta state for OS X.

Gerhard

[Mr. S]

Qt is more flexible than wx. You can use it on more platforms (https://en.wikipedia.org/wiki/List_o...upported_by_Qt) than wx. For example KDE is based on Qt, so Qt applications are running verry fast on KDE (I use Arch Linux with KDE). It is a great chance to port the application to more platforms. It would be nice to have it on a tablet (iPad) on board during a trip. Also, Qt has a lot of classes about maps and routing (Qt Location 5.5). On top Qt is designed with a plugin structure for applications (How to Create Qt Plugins | Qt 5.5) which proviedes a simple development process for plugins.

@boat_alexandra
I like the idea to simplify the program to an OpenGL render application without GUI. This would looks great on fullsceen at a tablet computer.

[CarCode]

Furthermore wxWidgets seems to be so bad documentated that even programmers using wx for a long time don't know how to use it correct,
e.g. as thumb rules for sizer flags:
- don't use horizontal alignment flags together with wxEXPAND
- don't use vertical alignment flags together with wxEXPAND
- don't use horizontal alignment flags for horizontal sizers
- don't use vertical alignment flags for vertical sizers

There are other examples as well.

Gerhard

[rgleason]

I am sure programmers will howl at me, but wouldn't it be easier to fix what is wrong with wxwigets and document it?

[CarCode]

About 2 month ago we have send a fix for the Mac port to the wxWidgets people but it is still not in trunk. So what?

Gerhard

[bdbcat]

Gerhard, Mr S., et al...

I see one thing here that Qt might bring us, and that is iOS support quicker than we might otherwise get it. However, please keep in mind that we will never be able to distribute OCPN on the Apple Store, free or otherwise, due to Apple's policies regarding code copyright ownership.

Otherwise, arguments regarding how nice and flexible Qt is are not compelling to me when I consider the user experience. Further, Qt is certainly not bug free, with frequent regression problems since they release more often than wx. Some of the more useful classes are just flat broken, as I discovered in the Android work. Ever tried to work the Qt style sheet architecture?

Of course, for developers, Qt may be an interesting exercise. Nothing wrong with that. If it brings more developers to the OCPN team, that is a good thing.

But I ask again, in all sincerity...

a. What wx Bugs affect OCPN users today?
b. What improvements would Qt bring to OCPN users?

Dave

[nohal]

Mr. S...
I have nothing against Qt, I actually like it a lot for cross platform development of *mobile* applications which also run on desktop as a bonus - it is modern, it is fast developing, it has a few nice features otherwise "hard" to get well in a cross-platform way.
Would I chose it for a *new* cross platform project? Very likely.
But is it really going to bring us something that justifies investing the enormous effort it will take to dump WX and port OpenCPN to it (all the way to converting the last wxString to QString)? I simply don't think so and so far don't see any real technical arguments for the time/effort investment of this size from anybody.

Originally Posted by Mr. S

Qt is more flexible than wx. You can use it on more platforms (https://en.wikipedia.org/wiki/List_o...upported_by_Qt) than wx. For example KDE is based on Qt, so Qt applications are running verry fast on KDE (I use Arch Linux with KDE). It is a great chance to port the application to more platforms.

Which new platforms are we interested in and can't get using Qt just as a wxWidgets backend as we already do on Android?
Is Qt really faster than native widgets on all the platforms? Do we have any numbers? I don't use that many apps based on it, basically just zyGrib and qtVLM. Are both of them bad examples or is their GUI and performance what is considered good by you and others? Is QtCreator an app I should refer to as a good example of the advantages of a toolkit that does not use native widgets of the OS? Any other application you consider looking at to fall in love with the concept?

It would be nice to have it on a tablet (iPad) on board during a trip.

The problem of not being able to have OpenCPN (Or any other GPL licensed software) on an iPAD is the Apple Store license, nothing technical, as far as I can tell.

Also, Qt has a lot of classes about maps and routing (Qt Location 5.5).

What exactly do you think it would bring us - the last time I looked at it there was more or less nothing interesting for an application like OpenCPN, needing flexible offline chart handling.

On top Qt is designed with a plugin structure for applications (How to Create Qt Plugins | Qt 5.5) which proviedes a simple development process for plugins.

We already have a plugin system, what exactly would be Qt's advantages here?

@boat_alexandra
I like the idea to simplify the program to an OpenGL render application without GUI. This would looks great on fullsceen at a tablet computer.

Yes, this makes more sense to me. Isolate the GUI from the rest of the application. Make the non-GUI components toolkit agnostic (= not depend on Qt, wxWidgets, GTK or whatever else, just stdlib and the like)
Taking this approach will also not make the codebase unusable for anybody but the few people working on the toolkit switch during the whole process.

Pavel

[P_Dub]

Date Format in OpenCPN.
Is there a possibility to change the date format and where can we do it?
Bye

[nohal]

Originally Posted by CarCode

About 2 month ago we have send a fix for the Mac port to the wxWidgets people but it is still not in trunk. So what?

Gerhard

Gerhard...
We package the libraries with the application, so there is no problem to include the fix in our version. Or do I miss something here?

Pavel

[Mr. S]

Originally Posted by nohal

Yes, this makes more sense to me. Isolate the GUI from the rest of the application. Make the non-GUI components toolkit agnostic (= not depend on Qt, wxWidgets, GTK or whatever else, just stdlib and the like)
Taking this approach will also not make the codebase unusable for anybody but the few people working on the toolkit switch during the whole process.

Ok, forget the Qt idea. This is a better solution. An application based on OpenGL and stdlib can be ported to most platforms.

[muttnik]

Originally Posted by CarCode

Furthermore wxWidgets seems to be so bad documentated that even programmers using wx for a long time don't know how to use it correct

Just to second that (although the topic may be dropped now). It's been a while since I contributed any code (sorry) and latest WX may have changed but I found the networking classes rather limited and restrictive and not very well documented. Can't remember what it was but there was some fairly basic stuff that seemed to be missing. A post on the wx forum turned up the fact that it was there, just undocumented (err...sorry...that's a bit anecdotal isn't it? It was more than a year ago). The version we were using last year didn't seem to support IPv6 which I was thinking of having a bash at, the latest does seem to.

No experience of Qt but a quick glance over the networking classes seems to be a bit more developed than WX, although I honestly haven't studied it in detail.