OpenCPN Version 5.7.1 Beta Test #4

[Rasbats]

Originally Posted by Hakan

Win10
Grib; Manual area selection.
Anyone else sees the same?

Yes ... same here for a Windows build today #22da06d.
Earlier versions like #e92995d (Win10) and #71ffe26 (MacOS) work as expected.

Grib_pi has had work done recently. Has this resulted in this change.

Mike

[houlejm]

Dave
O-charts PI needs libusb-0 to work but libusb0 is not a dependency. OpenCPN depends libusb-1.0-0 (>=2:1.0.16)


Ok if I install libusb-0 manually
JM

[LeaseOnLife]

Originally Posted by Hakan

Win10
Grib; Manual area selection.
Long time since I used this but when the manual area shall be drawn one have to use the mouse pointer.
On my system the drawn area is not shown on the screen so I don't see what I'm doing. If I draw an area in "blind" I see the selected area in the properties to send.
I tested another Windows and the result was the same. No indication while drawing an area. Anyone else sees the same?

yes, same on Debian Bookworm X64

[Hakan]

Grib: Manual area selection..
Thanks... An issue is now created on GitHub

[Ptizef]

Originally Posted by Hakan

Win10
Grib; Manual area selection.
Long time since I used this but when the manual area shall be drawn one have to use the mouse pointer.
On my system the drawn area is not shown on the screen so I don't see what I'm doing. If I draw an area in "blind" I see the selected area in the properties to send.
I tested another Windows and the result was the same. No indication while drawing an area. Anyone else sees the same?

Hakan
You are right, and this is very new. A few days ago it worked perfectly, I have made a great number of requests that way. It concerns only openGL mode
It should be related to the introduction of GLSL
JP

[ZagsAtCF]

I am on a Raspberry Pi 4 running Bullseye latest OS and Beta 4. When I am using the Route and Mark Manager and I highlight a route or track and click on Properties button the properties window opens behind the Route and Mark manager window.

[rgleason]

Originally Posted by Rasbats

Yes ... same here for a Windows build today #22da06d.
Earlier versions like #e92995d (Win10) and #71ffe26 (MacOS) work as expected.

Grib_pi has had work done recently. Has this resulted in this change.

Mike

I've very much appreciated this function, have had some trouble using it because it is not terribly intuitive, have long thought that it could be simpler and more direct, but have not come up with a method that would simplify it, due to the two approaches for defining an area.

[Hakan]

Grib; Manual area selection.
This is now fixed in current master.
Many thanks.

[Moo]

Originally Posted by Hakan

What OCPN/Grib does is to ask Windows for a email client. So it's Windows to have the responsibility to serve the right answer. What you can do is to check and set Windows properties to the correct email client. If you enable [X] "Manual selection" it use to be able to select and copy the mail text in a normal way.

Yes I know. Just saying that it isn't working with Blue Mail which is configured correctly .. Just saying that's all.

But what if I want to use the whole screen as the auto selection. I still consider this a bug. I should be able to copy and paste whether manual selection is selected or not. IMO

[bdbcat]

Moo...
I'm lost in the discussion of clients and mice.

Please describe again what you consider the bug to be.
Thanks
Dave

[bdbcat]

LoL...
Remember this?
"MUI button bar randomly is several rows too wide and too long. minimizing restoring O, fixes that temporarily"


I have pushed a patch which I think will resolve this bug, but difficult to test definitively, as it is random.
Please build from current github master, and let me know if you see the fault again.
Thanks
Dave

[LeaseOnLife]

Originally Posted by bdbcat

LoL...
Remember this?
"MUI button bar randomly is several rows too wide and too long. minimizing restoring O, fixes that temporarily"


I have pushed a patch which I think will resolve this bug, but difficult to test definitively, as it is random.
Please build from current github master, and let me know if you see the fault again.
Thanks
Dave

would love to, latest commit on master is fixes from TransmitterDan, 8h old by now..

[bdbcat]

LoL...
Pushed last night, I checked, the patch is in there.


fe9a1e1dc5fe0b80f270d983af0c03e2871035ef
Improve main toolbar management on size change.



Good Luck
Dave

[LeaseOnLife]

OK! then the test is running already, I will poke it

[LeaseOnLife]

Originally Posted by bdbcat

LoL...
Remember this?
"MUI button bar randomly is several rows too wide and too long. minimizing restoring O, fixes that temporarily" ...snip...

This works now, it should have happened by now, multiple times. Also: the disappearing/transparent status bar seems fixed, maybe by O source or some updates on wxgtk 3.2.2.