OpenCPN Version 5 Beta Release 4.99.1426

[pinguino]

Originally Posted by bdbcat

pinguino...
Tell us more about sound on your rPI. What Pi do you have? What OS are you running? What are symptoms?


Thanks
Dave

I'm using a Rpi 3 B+ with openplotter 1.2.0, therefore with the latest version of raspbian updated.

The problems are:
When playing ship bells it seems to sound good. But when playing the AIS alarm the sound sounds totally distorted. Also, the button that allows to check the sound does not seem to work, sometimes a small click sounds and this happens no matter what hardware element we have previously selected.

In build 1426 this didn't happen and all the sound elements worked correctly but only if I installed my own build. If I installed the PPA build there was no sound either.

It is curious because in previous versions of opencpn the sound worked more or less well but occasionally there were some wav files that also sounded distorted.

By the way, the issue of MBTiles continues to be somewhat annoying because it is mandatory to use groups of charts else the behavior of the canvas is irregular. Sometimes it allows to use different charts in each canvas but sometimes it doesn't and I don't explain the reason. And when it seems to work well when you close opencpn and reopen it, it stops or changes the canvas from CM93 to MBTiles. Only using the Charts groups option makes the behavior as expected. That was not necessary in 1426 either. I guess it's due to the change in the way MBTiles are treated as a layer instead of a Chart. It's not a problem if you expect what happens and are warned but if not it can be very annoying.

[transmitterdan]

I think this is a synchronous vs. asynchronous problem. It may be that it is trying to play the same sound file multiple instances at the same time

[bdbcat]

pinguino...


I think you are building your own OCPN from github HEAD. Good.
What are your build configuration options in CMake?



(ENABLE_SYSTEM_CMD_SOUND and ENABLE_PORTAUDIO)


Thanks
Dave

[pinguino]

Originally Posted by bdbcat

pinguino...


I think you are building your own OCPN from github HEAD. Good.
What are your build configuration options in CMake?



(ENABLE_SYSTEM_CMD_SOUND and ENABLE_PORTAUDIO)


Thanks
Dave

just by default.

I'm not modifying anything. I only follow the usual general instructions and do not change any parameters.

cmake .. -the first time-
make


That's all.

By the way, in 1507 he behaves the same.

Wait a minute. I will try to install the 1507 from PPA and see how it behaves.

Sorry from the PPA still came 1431 named 1428 on title bar.

[bdbcat]

pinguino...


Can you post the output of the CMake config process as you build?
For example, the interesting part of mine on rPI is:

-- Found Portaudio: /usr/lib/arm-linux-gnueabihf/libportaudio.so
-- Portaudio Found
-- Checking for module 'sndfile'
--   No package 'sndfile' found
-- Could NOT find LibSndFile (missing:  LIBSNDFILE_LIBRARY LIBSNDFILE_INCLUDE_DIR) 
-- ENABLE_LIBSNDFILE is set but I cannot find libsndfile

Yours may be different.


Also, the PPA for 1507 is not built yet, mainly pending the various sound bugs still present.


Thanks
Dave

[fgd3]

With regard to the red X for hidden charts, the answer seems dead simple to me. Change the X to an H. It's a really bad idea to use a design element that is widely associated with closing a window as an indication of something completely different. Why would anyone (who hasn't been trained to do so) associate an X with a hidden file? For English speakers, at least, the H (for hidden) seems far more intuitive.


Is there more to the issue I'm not aware of?


Fabbian

[nohal]

Originally Posted by fgd3

With regard to the red X for hidden charts, the answer seems dead simple to me. Change the X to an H. It's a really bad idea to use a design element that is widely associated with closing a window as an indication of something completely different. Why would anyone (who hasn't been trained to do so) associate an X with a hidden file? For English speakers, at least, the H (for hidden) seems far more intuitive.


Is there more to the issue I'm not aware of?


Fabbian

For a non-English speaker, the H has absolutely no meaning at all (In my primary language the first word that came to mind is an excrement, but it is probably not very important). Everywhere else, even in real life a double crossed anything clearly means something that is excluded, cancelled, discarded, not available, not wanted.
Even in the rest of OpenCPN GUI, this exactly same symbol is used with exactly the same meaning (And also has exactly the same dynamic as implemented now for the MBtiles in the chart piano). Are you also confused and think that the attached will close some window if you click it again? If not, why?
My opinion stays unchanged: Double cross does have a meaning, for everybody, regardless of language. "H" does not.

As you probably see, I'm still not convinced we should change it.

Pavel

[fgd3]

I've given up on 4.99.1426. I run OpenCPN on a Windows Vista computer on the boat and a Windows 7 computer for testing. The Vista computer had problems showing some of the charts with OpenGL turned on. I turned it off and everything seemed OK but I haven't had time to experiment with it further.


OpenGL caused the Windows 7 computer to crash a couple of minutes after I selected a vector chart. I know there have been problems with the implementation of OpenGL on older Windows versions so I turned OpenGL off. That stopped the crashes but there were other problems. I had difficulty selecting a raster chart when a vector chart was displayed. When I tried to drag a raster chart down (north to south) the chart moved at a 45 degree angle (northwest to southeast).


Has anyone tested 4.99.1426 with OpenGL off? Am I the only one experiencing problems with the program's basic functions? Is no one else running these old versions of Windows?


Fabbian

[nohal]

Originally Posted by fgd3

I've given up on 4.99.1426. I run OpenCPN on a Windows Vista computer on the boat and a Windows 7 computer for testing. The Vista computer had problems showing some of the charts with OpenGL turned on. I turned it off and everything seemed OK but I haven't had time to experiment with it further.


OpenGL caused the Windows 7 computer to crash a couple of minutes after I selected a vector chart. I know there have been problems with the implementation of OpenGL on older Windows versions so I turned OpenGL off. That stopped the crashes but there were other problems. I had difficulty selecting a raster chart when a vector chart was displayed. When I tried to drag a raster chart down (north to south) the chart moved at a 45 degree angle (northwest to southeast).


Has anyone tested 4.99.1426 with OpenGL off? Am I the only one experiencing problems with the program's basic functions? Is no one else running these old versions of Windows?


Fabbian

I am testing with OpenGL off pretty often. On Linux, macOS and Windows 10. All work fine. I do not and probably never will again, have any older Windows version available.
I also see no crashes with OpenGL on on any of the platforms. I do see rare and so far not tracked down crashes while ingesting vector charts on macOS, only if the binary was built using the 10.14 SDK on Mojave, they are not present on Windows, Linux or builds created on older macOS versions.
There are many people running these old versions of Windows as far as we know. Many of them testing the same betas as you. None of them reported the same problems as you so far.

Pavel

[bdbcat]

Fabbian...


Don't know what to say. I spent 15 minutes exercising 1507 on W7 without OpenGL. It is a virtual machine, pretty fast linux host. None of my virtual test setups use OpenGL, since it is problematic on VBox guests.



Overall, no problems, reasonable performance. Charts open and drag normally. Background SENC building works without disruption. GRIB and Dashboard plugins work fine. No MBTiles, of course, without GL.



Others are successfully running 1507 on ancient XP laptops, put out to pasture on the boat, so to speak.


So I don't think we have any fundamental problems with OCPN 499 related to older hardware.

At least on the Win7 machine, I would make the effort to find and install a modern GL driver. The difference in performance is significant, and you get tiles...


Dave

[fgd3]

Originally Posted by nohal

For a non-English speaker, the H has absolutely no meaning at all (In my primary language the first word that came to mind is an excrement, but it is probably not very important). Everywhere else, even in real life a double crossed anything clearly means something that is excluded, cancelled, discarded, not available, not wanted.
Even in the rest of OpenCPN GUI, this exactly same symbol is used with exactly the same meaning (And also has exactly the same dynamic as implemented now for the MBtiles in the chart piano). Are you also confused and think that the attached will close some window if you click it again? If not, why?
My opinion stays unchanged: Double cross does have a meaning, for everybody, regardless of language. "H" does not.

As you probably see, I'm still not convinced we should change it.

Pavel

Well, that is the problem with trying to associate a letter with a meaning--the association may not make sense in another language. We certainly don't want to take what should be a simple visual cue and turn it into something that requires a translation table.



But, yes, the red X (that's what you're calling "double cross", right?) on the chart button (piano key) suggests to me that clicking on that piano key will close something. I've never dealt with hidden files before so I would never have guessed that's what the X on the chart button meant. So what happens if you click on a chart button with a red X? Does the chart become unhidden? Does it select the chart? Without this discussion I would have expected it to make that chart button go away if I clicked on it.


Windows, MacOS, Linux, and AmigaDOS are the four GUI operating systems I've used. All of them use an X in the corner of a window to close it. There's a strong expectation among GUI users that a button labelled with an X is used to dismiss the associated window, dialogue box, or other graphical element.



Where else (other than MBTiles) in OpenCPN is the red X used to indicate something hidden? I'm not aware of seeing it. I'm not trying to start an argument with you. I assume it's in a part of OpenCPN I haven't used.



"Are you also confused and think that the attached will close some window if you click it again? If not, why?" I didn't understand this question, so I wouldn't be surprised if my response failed to answer it.


Fabbian

[bdbcat]

Fabbian...


The red X on hidden chart piano keys has been there for at least 5 years. Never before have we heard any comments about it, and I'm reasonably sure that it is being used in the wild.



If there is more than one piano key showing, right click on any piano key and select "Hide chart". The chart is hidden, but stays in the piano with the red X to indicate that it is still available for the quilt, if you desire.

For MBTiles, we simply make a single left-click a shortcut for "right-click-select-Hide chart-left-click"


Seems intuitive to at least some users.


Dave

[nohal]

Originally Posted by fgd3

Well, that is the problem with trying to associate a letter with a meaning--the association may not make sense in another language. We certainly don't want to take what should be a simple visual cue and turn it into something that requires a translation table.



But, yes, the red X (that's what you're calling "double cross", right?) on the chart button (piano key) suggests to me that clicking on that piano key will close something. I've never dealt with hidden files before so I would never have guessed that's what the X on the chart button meant. So what happens if you click on a chart button with a red X? Does the chart become unhidden? Does it select the chart? Without this discussion I would have expected it to make that chart button go away if I clicked on it.


Windows, MacOS, Linux, and AmigaDOS are the four GUI operating systems I've used. All of them use an X in the corner of a window to close it. There's a strong expectation among GUI users that a button labelled with an X is used to dismiss the associated window, dialogue box, or other graphical element.



Where else (other than MBTiles) in OpenCPN is the red X used to indicate something hidden? I'm not aware of seeing it. I'm not trying to start an argument with you. I assume it's in a part of OpenCPN I haven't used.



"Are you also confused and think that the attached will close some window if you click it again? If not, why?" I didn't understand this question, so I wouldn't be surprised if my response failed to answer it.


Fabbian

There is a picture attached to that post. From the route and waypoint manager. Which is using exactly the same symbol to mark exactly the same thing and having exactly the same dynamic behavior. This symbol and behavior is, I would say, very common in software and very intuitive.
And you said it yourself: "All of them use an X in the corner of a window to close it", that is not what we are looking at here, the context that associates the "X", or double cross, or cross, or however you want to call this to closing a window is clearly missing as the symbol is not in the upper left or right corner, where it "must be" to close a window. It is a simple pictogram meaning "disabled", "not shown", as it does all the time, all over your life.

[fgd3]

Dave, Pavel,

Thanks for your replies. I am happy to hear that others are successfully running the beta versions on older versions of Windows. If the problems I've encountered are unique to my computers then they are not significant.


Pavel, I quite understand you not having older versions of Windows. I have them because I demoted some older computers from active use to boat service.


Dave, I use OpenCPN almost exclusively with raster charts. I don't see any difference in performance with or without OpenGL. Raster charts display so fast they don't need OpenGL. My computers are rather underpowered so on those occasions when I select a vector chart performance is quite poor with or without OpenGL. I've never seen much difference either way except with OpenGL on the soundings remain readable when I'm zoomed out enough that they begin to be unreadable with OpenGL off. Where should I be seeing improved performance?



Fabbian

[bdbcat]

Fabbian....


The biggest visible improvement comes with:


a. Zoom on raster charts (uses very fast, cached GL mipmaps).
b. Panning on vector charts.



As I say, worth the effort to try and find a GL driver. What computer brand/model are you using for W7?


Dave