My story of an (unsuccessful) OSX workaround

[Paul K]

Hi All,

 

Just want to share my short story to see maybe someone can propose a solution and to vent a bit about the challenges.

 

I have a cross-platform wxwidgets application that includes a tree control (wxTreeCtrl) that allows editing of its elements tied to F2. This is implemented based on KEY_DOWN event connected to wxTreeCtrl. This tree control is inserted into a notebook that is one of several managed by wxAuiManager. The application is quite complex, but works well on Windows, OSX, and Linux, with exception of several things, one of each is described below.

 

1. I recently added F2 as a menu shortcut and ran across the first issue. The global shortcut is called first on Windows and OSX, so KEY_DOWN event doesn't get any chance to be checked. It still works on Linux, because of the changes that are discussed at length in this topic: http://wxwidgets.10942.n7.nabble.com/Menu-shortcuts-inconsistentcy-issue-td85065.html. I was one of the participants and have to say that I didn't like Linux behavior as it seemed inconsistent to me at that time (and cause issues with wxSTC behavior on Linux that forced me to put a workaround in place). I may now reconsider my position, but in any case, the behavior is different between Linux and Windows/OSX.

 

2. I thought I would just make a simple fix using CHAR_HOOK connected to the tree control to handle characters before they get to the accelerator handling. Works on Windows, but not on OSX.

 

3. I then thought that I could attach wxAcceleratorTable to wxTreelCtrl to handle F2 when the tree control has focus. Works well on Windows, but not on OSX as it always activates the "local" shortcut (F2 that edits a tree item) even when a focus is on some other element.

 

4. I then thought that I could set the accelerator table on SET_FOCUS event connected to wxTreeCtrl and remove it on KILL_FOCUS event. Works on Windows, but doesn't work on OSX as the KILL_FOCUS event never comes; probably related to #14269 and #14142.

 

At this point I ran out of solid ideas. Instead of each workaround I could have tried to find what was wrong, but I'm completely unfamiliar with OSX programming and even though I'm getting more comfortable with reading wxwidgets code, I'm not in position to change much there (at least not on OSX). I'm not about to admit defeat and still want to try setting WANTS_CHAR style and see if I can track SET_FOCUS event on other components (and sent/emulate KILL_FOCUS for wxTreeCtrl), but this all looks like much more work than should be.

 

I suspect there is a workable solution/workaround for this issue, but I just can't see it (and would appreciate suggestions/ideas to explore).

 

I'd also like to talk briefly about the state of some of these issues. Two of the tickets related to missing KILL_FOCUS event had been opened two years ago and last updated more than a year ago. I understand Vadim's position to avoid raizing priority on those tickets that don't have people that can work on them, but setting high priority can be useful in two ways: when we do get people working on them, they can focus on those issues and if we don't have resources, maybe we can get some external help when we can point to specific high priority issues that need fixes. In fact, I'd consider chiming in with some bounty money and although it's a slippery slope if we start paying for tickets, I'm not against it and had a bounty for my own project for a particularly tricky problem (although it wasn't claimed).

 

Paul.

[Dan Gudmundsson]

First I must say that keyboard handling have become so much better since 2.8, but there is still work to do.

I have also stumbled on this issue, my idea was to disable wxWidgets automagic keyboard shortcut to menu event,

and let me handle all the keyboard events myself. 

But that's not doable since CHAR_HOOK on OSX is not sent for keys that is a menu shortcut.

Also CHAR_HOOK events are not always sent on Windows, if I remember correctly when mouse is grabbed keyboard

events for keys in menu shortcut does not get triggered. 

In the end my workaround to get my app to work on every platform with both 3.0 and 2.8, was to catch 

COMMAND_MENU_SELECTED and if it have a keyboard shortcut, translate it to the keyboard event.

But it is a major gripe that the keyboard events still does not behave the same on different OS's. 

/Dan

--
To unsubscribe, send email to wx-dev+un...@googlegroups.com
or visit http://groups.google.com/group/wx-dev

[Paul K]

Hi Dan,

 

> In the end my workaround to get my app to work on every platform with both 3.0 and 2.8, was to catch

> COMMAND_MENU_SELECTED and if it have a keyboard shortcut, translate it to the keyboard event.

 

This was a very helpful suggestion; thank you. I ended up capturing wxEVT_COMMAND_MENU_SELECTED for wxID_ANY and then generating events I need if the focus is on those elements that expect those events. Not ideal, but not as bad as it could be.

 

Paul.

 

[Vadim Zeitlin]

On Thu, 15 May 2014 22:35:04 -0700 (PDT) Paul K wrote:

PK> 1. I recently added F2 as a menu shortcut and ran across the first
PK> issue. The global shortcut is called first on Windows and OSX, so KEY_DOWN
PK> event doesn't get any chance to be checked. It still works on Linux,
PK> because of the changes that are discussed at length in this topic:
PK> http://wxwidgets.10942.n7.nabble.com/Menu-shortcuts-inconsistentcy-issue-td85065.html.
PK> I was one of the participants and have to say that I didn't like Linux
PK> behavior as it seemed inconsistent to me at that time (and cause issues
PK> with wxSTC behavior on Linux that forced me to put a workaround in place).
PK> I may now reconsider my position, but in any case, the behavior is
PK> different between Linux and Windows/OSX.

It seems that we don't have a Trac ticket for this, but we really ought
to. Could you please create one and attach some code reproducing the
problem? Ideal would be to have a unit test using wxUIActionSimulator
checking for this.

PK> 2. I thought I would just make a simple fix using CHAR_HOOK connected to
PK> the tree control to handle characters before they get to the accelerator
PK> handling. Works on Windows, but not on OSX.

I'm not even sure how should CHAR_HOOK and accelerators combine... But
they clearly should do it in the same way under all platforms.

PK> 3. I then thought that I could attach wxAcceleratorTable to wxTreelCtrl to
PK> handle F2 when the tree control has focus. Works well on Windows, but not
PK> on OSX as it always activates the "local" shortcut (F2 that edits a tree
PK> item) even when a focus is on some other element.

I have no idea how can this happen to be honest. But in any case,
accelerators should really be only used for TLWs and such workarounds
shouldn't be necessary in the first place.

PK> 4. I then thought that I could set the accelerator table on SET_FOCUS event
PK> connected to wxTreeCtrl and remove it on KILL_FOCUS event. Works on
PK> Windows, but doesn't work on OSX as the KILL_FOCUS event never comes;
PK> probably related to #14269 and #14142.
...
PK> I'd also like to talk briefly about the state of some of these issues. Two
PK> of the tickets related to missing KILL_FOCUS event had been opened two
PK> years ago and last updated more than a year ago. I understand Vadim's
PK> position to avoid raizing priority on those tickets that don't have people
PK> that can work on them, but setting high priority can be useful in two ways:
PK> when we do get people working on them, they can focus on those issues and
PK> if we don't have resources, maybe we can get some external help when we can
PK> point to specific high priority issues that need fixes. In fact, I'd
PK> consider chiming in with some bounty money and although it's a slippery
PK> slope if we start paying for tickets, I'm not against it and had a bounty
PK> for my own project for a particularly tricky problem (although it wasn't
PK> claimed).

I agree that those are important bugs, so I did increase #14269 priority
(but closes #14142 as it seems to be the exact duplicate). I still can't
fix this myself though.

Regards,
VZ

[Paul K]

PK> 1. I recently added F2 as a menu shortcut and ran across the first
PK> issue. The global shortcut is called first on Windows and OSX, so KEY_DOWN
PK> event doesn't get any chance to be checked. It still works on Linux,
PK> because of the changes that are discussed at length in this topic:
PK> http://wxwidgets.10942.n7.nabble.com/Menu-shortcuts-inconsistentcy-issue-td85065.html.
PK> I was one of the participants and have to say that I didn't like Linux
PK> behavior as it seemed inconsistent to me at that time (and cause issues
PK> with wxSTC behavior on Linux that forced me to put a workaround in place).
PK> I may now reconsider my position, but in any case, the behavior is
PK> different between Linux and Windows/OSX.

VZ> It seems that we don't have a Trac ticket for this, but we really ought
VZ> to. Could you please create one and attach some code reproducing the
VZ> problem?

 

Yes, I'll see if I can patch one of the examples to demonstrate the issue.

 

I was thinking that adding something similar to what we have in CHAR_HOOK (IsNextEventAllowed) may work for shortcuts events as well (if you don't want to handle this particular one and want KEY_DOWN to be handled), but this doesn't help when the shortcut is disabled (by an UPDATE_UI event).

 

While we are on the subject of OSX workarounds, I have another issue that I tried several workarounds with and none of them work. Essentially, Ctrl-Tab doesn't work correctly on OSX, but I can't find a way to intercept it to apply my one logic and can't find where the flawed logic is implemented. Any idea what methods/files are responsible for handling Ctrl-Tab that jumps between tabs in (wxAui)Notebooks? And no, neither CHAR_HOOK, nor wxAuiTabCtrl::OnChar, nor EVT_NAVIGATION_KEY work in this case; details are here: https://groups.google.com/d/msg/wx-users/4dPguF-qitA/EA0cXHJle3wJ. Thank you.

 

Paul.

 

[Vadim Zeitlin]

On Sat, 17 May 2014 22:23:10 -0700 (PDT) Paul K wrote:

PK> PK> 1. I recently added F2 as a menu shortcut and ran across the first
PK> PK> issue. The global shortcut is called first on Windows and OSX, so
PK> KEY_DOWN
PK> PK> event doesn't get any chance to be checked. It still works on Linux,
PK> PK> because of the changes that are discussed at length in this topic:
PK> PK>
PK> *http://wxwidgets.10942.n7.nabble.com/Menu-shortcuts-inconsistentcy-issue-td85065.html*<http://wxwidgets.10942.n7.nabble.com/Menu-shortcuts-inconsistentcy-issue-td85065.html>.
PK>
PK> PK> I was one of the participants and have to say that I didn't like Linux
PK> PK> behavior as it seemed inconsistent to me at that time (and cause issues
PK> PK> with wxSTC behavior on Linux that forced me to put a workaround in
PK> place).
PK> PK> I may now reconsider my position, but in any case, the behavior is
PK> PK> different between Linux and Windows/OSX.
PK>
PK> VZ> It seems that we don't have a Trac ticket for this, but we really ought
PK> VZ> to. Could you please create one and attach some code reproducing the
PK> VZ> problem?
PK>
PK> Yes, I'll see if I can patch one of the examples to demonstrate the issue.

I'd still be interested in this as I'd really like to deal with this issue
once and for all. Or at the very least determine what exactly do we need to
do, i.e. what is the expected behaviour. Or at the even leaster least just
understand what the hell is going on here...


PK> While we are on the subject of OSX workarounds, I have another issue that I
PK> tried several workarounds with and none of them work. Essentially, Ctrl-Tab
PK> doesn't work correctly on OSX, but I can't find a way to intercept it to
PK> apply my one logic and can't find where the flawed logic is implemented.
PK> Any idea what methods/files are responsible for handling Ctrl-Tab that
PK> jumps between tabs in (wxAui)Notebooks? And no, neither CHAR_HOOK, nor wxAuiTabCtrl::OnChar,
PK> nor EVT_NAVIGATION_KEY work in this case; details are here:
PK> https://groups.google.com/d/msg/wx-users/4dPguF-qitA/EA0cXHJle3wJ. Thank
PK> you.

Sorry, I don't know wxAUI code at all but according to Apple documentation
(http://support.apple.com/kb/ht1343), Ctrl-Tab is a system shortcut key, so
maybe it is getting intercepted earlier? And is this even the right key
combination for switching tabs under OS X? Unfortunately I don't see
anything explicitly about this in the above article, does anybody know how
to switch tabs in e.g. Safari?

Regards,
VZ

[Paul K]

Vadim:

> I'd still be interested in this as I'd really like to deal with this issue 
> once and for all. Or at the very least determine what exactly do we need to 
> do, i.e. what is the expected behaviour. Or at the even leaster least just 
> understand what the hell is going on here... 

I ended up with quite elaborate workaround, but at least, there is a workaround for this issue.

> Sorry, I don't know wxAUI code at all but according to Apple documentation 
> (http://support.apple.com/kb/ht1343), Ctrl-Tab is a system shortcut key, so 
> maybe it is getting intercepted earlier? And is this even the right key 
> combination for switching tabs under OS X? Unfortunately I don't see 
> anything explicitly about this in the above article, does anybody know how 
> to switch tabs in e.g. Safari? 

It's not specific to Safari, but what it does there is moving focus to the next tab, which is the same thing I'd expect for wxAuiNotebook. You can run auidemo application and see that the control goes all over the place instead of correctly going between tabs and back to the first tab when it reaches the last one.

I don't see any logic in the focus jumping between different controls and it's utterly confusing to the users, which makes this function useless. I also couldn't find any workaround as I can't capture Ctrl-Tab combination (as I described earlier). You can see that something strange is going on by attaching CHAR_HOOK event. It will be called for Ctrl and Shift buttons, but not the Tab button. I can dig deeper to see what's going on, but would need some guidance as to where to look for that Ctrl-(Shift-)Tab logic. This is one of the last few issues that stops me from upgrading.

Paul.

[MER]

Do you know if this event works on Linux ?

I use it on Windows and there is no problem but on Linux, when an wxSTC has
the focus, the shortcuts of scintilla take over my shortcuts...

Thanks

[Paul K]

Melodie,

> Do you know if this event works on Linux ? 
> I use it on Windows and there is no problem but on Linux, when an wxSTC has 
> the focus, the shortcuts of scintilla take over my shortcuts... 

yes, I got it working on Linux as well, but with a different workaround. I go through the list of all keymaps and check for those that may conflict with Scintilla shortcuts (I just check for Ctrl-<something> to simplify this logic). I then map them to the actual events they are associated with and in KEY_DOWN event in the editor I do the following (this is Lua code, but the logic is simple):

      if mod == wx.wxMOD_CONTROL and editor.ctrlcache[keycode] then

        ide.frame:AddPendingEvent(wx.wxCommandEvent(

          wx.wxEVT_COMMAND_MENU_SELECTED, editor.ctrlcache[keycode]))

Basically, I check for those conflicting combinations in KEY_DOWN event and generate proper event. Not ideal, but it works for me.

Paul.