Bug in waymark/properties/description text entry

[kas_1611]

I'm running OpenCPN version 4.0.0 on a MacBook Pro with OSX10.10.3 and have found a glitch.

When you drop a mark then go to edit the properties and try to enter any text into the descriptions box you find that if you need to enter any of the letters used for the control menu items (such as T,L,S & A which are in the View menu) the character does not enter into the text box but activates the menu option. In the above examples this switches the ENC Text, Lights, Soundings or Lights.

The only method to enter descriptions I have been able to use is copy and paste from Open Office.

Cheers

Keiron

[CarCode]

That is a known bug of OpenCPN for Mac OS X but there is still no fixed version released.

Gerhard

[bdbcat]

Keiron/ Gerhard...

First I have heard of it. Maybe a Flyspray bug report would elevate the priority.

Thanks
Dave

[kas_1611]

Perhaps instead of using plain letters for keyboard shortcuts of menu items all that needs to happen is to use cmd+letter or CTRL+letter to distinguish between plain text entry and actual command entries.

Glad to know it is known about and not just me

[ptulp]

Originally Posted by bdbcat

Keiron/ Gerhard...

First I have heard of it. Maybe a Flyspray bug report would elevate the priority.

Thanks
Dave

FS#1655 is opened for this.
It says Solution Pending
The fix is committed on 13 March
Correct keyboard accelerator logic for WXOSX (FS#1698/1655)

[CarCode]

Originally Posted by bdbcat

Keiron/ Gerhard...

First I have heard of it. Maybe a Flyspray bug report would elevate the priority.

Thanks
Dave

Yes, I know, the port for Mac OS X is not cared about too much.

Gerhard

[rgleason]

Didn't Caesar Schinad have some fixes for this?

Sent from my SCH-I545 using Cruisers Sailing Forum mobile app

[CarCode]

Originally Posted by rgleason

Didn't Caesar Schinad have some fixes for this?

Sent from my SCH-I545 using Cruisers Sailing Forum mobile app

It was fixed long time ago in github but never a fixed compiled version was released.

Gerhard

[bdbcat]

Mac Users...

Sorry, my bad memory. This bug is well known, and the fix is in process.

School time...Listen up, please:

1 "Solution Pending" means (and has always meant) that the fix is in github master branch, has been functionally verified, and will be in place for all systems in the next Beta release.

2. There has been no Beta for any systems since O4.0.0 was released.

3. Ergo, no one not building from github master source will have seen this fix yet.

4. You may expect to see this fix in place when the Beta 4.1 series starts, and so it will propagate into the OCPN 4.2.0 Release.

5. This is the way we manage controlled Releases over (now) 5 platforms. There may be other ways, but this is ours.

Just so you will know, we tend to prioritize our cross-platform development efforts on overall PC market share. If you think OCPN development for the OS X platform is de-focused, you may wish to study those numbers...

Thanks
Dave

[CarCode]

There is one point missing however:
What happens when a released version is unusable for a platform?

Gerhard

[kas_1611]

Knowing a fix is "in progress" is good with me

It is not like this is a critical bug that prevents the system working, rather a minor niggle that has a work around through "copy/paste" from a text file. Doesn't spoil the experience in any way once you know that.

Keiron

[bdbcat]

Gerhard...

re:

What happens when a released version is unusable for a platform?

That is a simple indication that there has not been enough testing and Flyspray feedback for that platform. We make every effort not to release when there is an outstanding critical usability bug still open in Flyspray.

It is simply not practical for the developers to test every corner case feature on every platform at every Beta. Too many dimensions. That is why we do broad-spectrum Beta testing.

Thanks
Dave