OpenCPN Beta Version 3.1.802 Released

[sinbad7]

Dave..

I don´t want to take the credit for the ´red herring´ contained in Jespers earlier explanation:

3.0 did not use those features of wx. 2.8.12 is the official stable wxWidgets release and that is what the next version of O will require.

I perhaps mistakenly understood that, whilst v.3.0.0 did not use certain features of wx. 2.8.12, later versions DID! And hence,the problems...

Of course,any new version with new features can have new problems,and that was just what I wanted to point out as a tester.

Having resolved tweeks to make GE2KAP compatible with v.3.1.802,I have since discovered other problems which has made me revert to v. 3.0.2

Thanks for all the hard work! Much appreciated..

Tore

[JesperWe]

Originally Posted by sinbad7

I don´t want to take the credit for the ´red herring´ contained in Jespers earlier explanation:

That was in reply to dpons who had a problem with cursor icons showing as rectangles in Debian 6.

[JesperWe]

OK, now trying to sort out the actual issues reported from Tore's testing:

As you know,there has been several other changes caused after v. 3.02, the tidal displays,the mini chart is no longer shown in the Chart toolbar,the ´Display best chart´in the right mouse click has disappeared,the Show ENC text in the toolbar no longer functions,the text in the Charts toolbar is too small to be readable etc.

Tidal displays: Fixed since last week as discussed extensively earlier in this thread.

Too small default fonts: Caused by some systems reporting incorrect physical screen sizes. Fixed by not accepting resolution values lower than 72 DPI. People running O on Plasma movie screens will have to live with that, it's only a default after all...

Chart thumbnails not visible: Caused by window ownership bug. Fixed, and I also made the thumbnails scale anti-aliased, so they will have more readable graphics. Also made them appear next to the toolbar instead of underneath it, if it is positioned in the default top left corner.

Display Best Chart: I guess this is the command actually called "Max Detail Here", which is working as it was before, and only available in non-quilted mode.

Show ENC button: Can't reproduce this one, seems to be working fine. More info needed, what are the settings in the Vector Charts tab?

The Charts toolbar buttons are displayed in three different ways,blue with a pink box somewhere and minimal chart info,in pale blue with all info and finally as a grey framed button with minimal chart info. The number of dark blue boxes also changes while you pan. And finally the brown button representing CM93 with minimal info.

This describes the normal function of the chart buttons. The various display styles indicate the current loading or display status of each chart. Nothing has changed here since before. What is the problem?

The third problem is the new way the Chart selection bar is now displayed,making it impossible to hide in the chart conversions.

The motivation for the change was gaining more vertical space for displaying the charts. The status bar would typically steal 22 pixels of screen space for no good, especially when using CM93. Now GE2KAP uses some very non-standard ways of integrating with O, but anyway, providing a hot-key for turning the chart bar off is really simple and does not disturb any other functionality, so I have done that. It will be Ctrl-B.

(As a side note, how about using the Plugin API, sounds easier to me than OCR-ing the status window text...)

[phiggins]

Now GE2KAP uses some very non-standard ways of integrating with O, but anyway, providing a hot-key for turning the chart bar off is really simple and does not disturb any other functionality, so I have done that. It will be Ctrl-B.

Thanks for making this change for GE2KAP.

[sinbad7]

Jesper..

Thanks for the explanation..

I do not use the chart quilting facility very often and I had overlooked the fact that ´Max detail here´ as well as the miniature charts do not display in this mode.

Probably not the fault of OpenCPN,but I wonder why some chart information boxes contain all the required info whilst others have a bare minimum?

Tore

[cagney]

Originally Posted by sinbad7

...
Probably not the fault of OpenCPN,but I wonder why some chart information boxes contain all the required info whilst others have a bare minimum?

Tore

Tore
Click on the button for a chart that displays "a bare minimum", so that O actually displays the chart. Go back and check the info box now.
Do you see the difference?
Thomas

[sinbad7]

Thomas..

Thanks for the tip but I am presently back on v. 3.0.2
I will check this out later.

Tore

[bdbcat]

Info:

The reason that some chart info boxes contain bare minimum information is that either the chart has not actually been read from disk yet, or has been purged to free memory. The bare minimum info is that which is stored in the chart database only.

Dave

[JesperWe]

Originally Posted by sinbad7

Probably not the fault of OpenCPN,but I wonder why some chart information boxes contain all the required info whilst others have a bare minimum?

I posted previously (#87) in this thread about this, because fgd3 also brought up the same issue (BTW, not a bug, it has always been like this)

Anyway: The full chart info is available for ALL charts when running in non-quilted mode, but only for currently rendering charts when in quilted.

This is because in quilted mode only the rendered charts are in the chart cache, but in non-quilted mode all charts are in the cache, and for reasons that I don't understand.

So over to Mr Quilting (Dave) on that one...

[dpons]

Originally Posted by JesperWe

3.0 did not use those features of wx. 2.8.12 is the official stable wxWidgets release and that is what the next version of O will require.

BTW there are some things in 3.0 too, most notably the Object Query window, which does not work well with 2.8.10.

Jesper:

<rant>
You are one of the most enthusiastic developers here, and very prolific too.
Yet, I won't drink the koolaid. In 30 years as a professional developer, both in systems programming as in apps, and mostly (99%) using unix/linux, I learned that is quite possible to maintain backwards compatibility with new features. #ifdef's don't byte. I can accept the fact that some features may not be activated in some configurations, but just saying that

There are apparently a few distributions of Linux that are lagging behind

, labeling as quasi-obsolete the mother and referent of most distributions, debian, is going too far. Debian is not lagging behind, on the contrary, is has all the stuff that is proven to work well, in opposition to bleeding edge distributions that need to be patched constantly.

If OpenCPN can't produce a release that works in a given OS' released one year ago because they are considered obsolete and lagging, it's going to leave behind a good chunk of its users.

I blame mostly the use of IDE's, that force compatibility only with the package versions that they have installed.

</rant>

[JesperWe]

Originally Posted by dpons

labeling as quasi-obsolete the mother and referent of most distributions, debian, is going too far.

Saying that I labelled Debian quasi-obsolete by saying that it was lagging behind in providing stable wxW packages is maybe going too far too :-)

All I said was it was lagging in wxW, which it is.

And again, the wxW team provides an Apt repository for those distros who are not on stable, making it very easy to install. (Index of /)

Originally Posted by dpons

#ifdefs don't byte

mmm.... did you look at the code? It just happens that wxW stable is already a pretty platform dependent thingie, with lots of quirks. And rather broken 32-bit bitmap support on wxGTK. We are already working around these issues with a large number of #ifdefs. Too add a new dimension to these, not just separating MSW, GTK and OSX code, but also supporting different wxW versions on GTK, is a whole new headache.

It would also require developers to have even more separate installs for building and testing, which is already taking up a lot of energy.

Not something that I personally think is worth it, especially since there exists a solution for the users who's distro does not contain wxW stable.

It might be that Dave disagrees, he's more devoted to the #ifdef's

[bdbcat]

Jesperwe..

Yes, I like #ifdefs, and I especially like backward compatibility.

So, a general "it's too hard" to keep backward compatibility seems not quite the right position.

If we look at a list of real broken functionality on wxGTK 2.8.10, maybe we can address some of it, maybe not. But we should at least look.

I absolutely agree that we must not hobble OpenCPN to accommodate the least common denominator of library compatibility. We will use as many #ifdefs as we need.

Dave

[cagney]

dpons
Do you have sound working on your Debian?
I'm just curious if your wx packages are compiled with support for SDL.
Thomas

[dpons]

Originally Posted by cagney

dpons
Do you have sound working on your Debian?
I'm just curious if your wx packages are compiled with support for SDL.
Thomas

Thomas,

sound works well in general, but never with opencpn. Somebody mentioned a while back about an alternative configuration method by using /usr/bin/play, I don't thik it was implemented. I'll check tomorrow if I have SDL support (???) in the system where
I compiled the release.

Diego

[cagney]

Originally Posted by dpons

Thomas,

sound works well in general, but never with opencpn. Somebody mentioned a while back about an alternative configuration method by using /usr/bin/play, I don't thik it was implemented. I'll check tomorrow if I have SDL support (???) in the system where
I compiled the release.

Diego

Diego
Have a look here Known issues with the current stable release. | Official OpenCPN Homepage

It boils down to that your kernel must be compiled with support for OSS or your wxGtk package must be compiled with support for SDL. Ubuntu has neither of these options available.

Thomas