LiveCode Forums.

Hi folks,
It seems that on OSX, the Alt and ⌘/Command modifier keys do not behave as expected (together with left/right arrows or the Backspace key), when editing text in either the LiveCode IDE or stand alone applications.

From my experiments, it would appear that LiveCode on OSX ignores the Alt key, whilst the Command key modifies behaviour in a way normally associated with the Alt key.

Specific examples are:
• Alt+Right/Left Arrow: Alt key is ignored, instead of cursor movement granularity being switched from character-level to word-level;
• Cmd+Right/Left Arrow: switches granularity from character-level to word-level (so it behaves the way that the standard Alt=Arrow should function)
• Fn+Alt+Backspace: Alt key influence is ignored - deletes next character
• Fn+Cmd+Backspace: switches granularity to delete next word (as expected from the Alt key)

Before I raise a bug report to address these issues, are my findings correct and are there other anomalies that need to be trapped for OSX, Windows or Linux?

Clark,

Your observations match my own on OSX. I also see that on Windows the standard behavior seems to be that Cntl + right/left arrow changes granularity to word-level. LiveCode behavior on Windows matches this behavior.
My preference would be that the modifier + arrow key behavior match the host OS.

Regards,

Devin

Hi Devin,
Thanks for the response - and the insight that LiveCode's Ctrl key behaviour on the Windows platform is more orthodox, in that it reflects the host operating system's default behaviour.
Best,
Keith..

Besides custom coding selection changes by rawkeydown trapping, no.

The existing behaviour is a weird middle ground between how windows and mac os do things, with one or two unix conventions added for flavour. Somewhen, someone decided it should be this way, most likely based on personal preference.

Bjoernke,
Thanks for responding - can you be more specific on the incorrect behaviours on the Windows platform?
I'd prefer to raise a very clear bug report with obvious as-is and to-be states. If the report comes across as a vague rant, it may be ignored - and if the dev team have to do the research, it will take longer to resolve.
Thanks,
Keith..

Hehe, actually I like how rev does it, but then I might prefer the mac way to be used on windows... I don't care much for that platforms idea about rules...

sorry, can't help

Rechecking the QA site before posting a bug report, I discover that for the OSX platform, what I consider to be a major platform-level, compliance and usability bug, has been languishing as a mere text field enhancement request for over two years http://quality.runrev.com/qacenter/show_bug.cgi?id=5869

I think this has been poorly categorised - but I don't know the protocol for overriding the original listing.

Maybe nobody is using the IDE on OSX? Maybe no one is deploying of OSX stand alone products in sufficient quantities to make their customer's complaints warrant shouting about this basic issue?

Clark,

I do consider this a bug, not just an enhancement. You should post your comments to this report, then ask Trevor if he'd upgrade it to a bug rather than an enhancement request. It also wouldn't hurt to update the LiveCode version to the latest, as it might get the attention of the Dev team sooner. You could also add some votes to it in the QA Center. I'd be happy to do so as well. Finally, if you are on the Developer list you could post there. It would help get feedback from other developers and possibly the LC Dev team.

Devin

I also agree that this is something that should be changed. I think the proper procedure here is probably to add a new bug report to the QCC and reference bz#5869 in it. There's something to be said for consistency in the IDE among the various platforms, but I think it's more important for the platform-specific conventions to be followed, since that carries over from other applications.

Thanks for the advice, Mark. New bug report raised http://quality.runrev.com/qacenter/show_bug.cgi?id=9394

Thanks for tackling this, Clark. I've added some votes to your report.

Devin

Hmm, the dev team immediately closed this bug report as a duplicate of the previous feature request 5869, without suitably updating the original.

So, I've reopened the report, suggested that 5869 is a small subset of this larger issue and if a bug is to be dropped, it would be well to leave the big one that may help prevent OSX applications falling foul of Apple HIG (and maybe App Store compliance rules), not the small one that has been ignored for two years already.

Actually, Clark, it looks like Mark W. did change the original report from an enhancement request to a bug. (Severity field changed from 'enhancement' to 'normal'.) The version is also updated to 4.6.0 DP5. My hunch is they're taking a look at it now.

Yes, I noticed those changes but the scope was still limited to text fields, not OSX deployments or the IDE script editor, etc.

Still, here's hoping!

I just read your comment to this effect on your bug report. It's an important point; why not add the same comment to the other report, just to make sure it doesn't get overlooked?