search

pkulchenko / ZeroBraneStudio

Lightweight Lua-based IDE for Lua with code completion, syntax highlighting, live coding, remote debugger, and code analyzer; supports Lua 5.1, 5.2, 5.3, 5.4, LuaJIT and other Lua interpreters on Windows, macOS, and Linux
http://studio.zerobrane.com/
Other
2.62k stars 518 forks source link

Editor window loses focus when switching between tasks on OSX #997

Closed dexmar closed 4 years ago

dexmar commented 5 years ago

Pretty much identical to this: https://github.com/pkulchenko/ZeroBraneStudio/issues/327

Only the currently selected tab is impacted, all others maintain cursor position.

Problem is on a MacBook Pro running 10.14.5 and ZeroBrane 1.7.0 and 1.8.0.

pkulchenko commented 5 years ago

@dexmar, thank you for the report! I don't get this effect on my MacBook running 10.10.5, so I'll have to find some more recent version to test on. Does it happen when you switch to any other app (like Cmd-Tab and Cmd-Tab back)?

dexmar commented 5 years ago

@pkulchenko thanks for the quick response! Interestingly, Cmd-Tab maintains the cursor focus. 3 finger swipe up or F3 to launch Mission Control and switch between ZB and another program cause cursor focus to be lost. In addition, if I offset ZB with another program and then switch by clicking on the exposed portion of the hidden program and then back to ZB by clicking on the exposed portion of ZB, focus is also lost.

pkulchenko commented 5 years ago

That's indeed interesting...

3 finger swipe up or F3 to launch Mission Control and switch between ZB and another program cause cursor focus to be lost.

How are you switching back to ZBS? Clicking on some part of it outside the editor? I presume if you click on the exposed part of the editor, it will get the focus, rigth?

In addition, if I offset ZB with another program and then switch by clicking on the exposed portion of the hidden program and then back to ZB by clicking on the exposed portion of ZB, focus is also lost.

Which part of ZBS is exposed? If you click somewhere outside of the editor (on the toolbar area for example), then it may be expected not to have focus on the editor.

Just to confirm, when you say focus is lost, you mean that the application is active, but the current editor tab doesn't show a blinking cursor and the current line (where the cursor is supposed to be) is not highlighted, right?

dexmar commented 5 years ago

Typically I switch using Mission Control. I have tried switching by clicking on exposed parts as that is sometimes easier. I've considered focus was removed because of where I was clicking on ZB but the behavior is the same regardless where I have clicked (for reference, the screenshot shows the locations where I typically click).

Yes, focus is lost as you described: no blinking cursor and the line is not highlighted, but only on the active tab. If I click on another tab I find that the other tabs have retained focus.

Curious, no?

Thanks for taking the time to look at this!

Screen Shot 2019-06-20 at 4 55 25 PM
dexmar commented 5 years ago

A quick update... I have found that the upper location (of the 2 shown in the photo) does remove focus if clicked while ZBS is the active program. The lower location does not, but when clicking on the lower location while ZBS is not the active program does cause the current editor window to lose cursor focus as described above.

pkulchenko commented 5 years ago

@dexmar, I did some experiments and can confirm the effect. It seems like there are three types of locations that can be clicked on: (1) normal locations that get focus (like editor windows), which work both when the IDE is active and not (meaning that the editor gets proper focus when clicked on), (2) locations that can be clicked on and take away the focus from the editor when the IDE is active or not (like the editor tab background), and (3) locations that can be clicked on when the app is inactive (and take away the focus), but doesn't do that when the app is active (like the status bar or the toolbar background). I think the behavior of the last group is a bug, but I don't see the source of this behavior, as it seems to be happening somewhere inside wxwidgets.

I've been working on wxwidgets upgrade and checked the behavior on the new branch and it doesn't seem to be happening there (meaning that when the IDE is inactive and I click on the status bar or the toolbar background, the IDE gets focus and the editor tab is active with a proper focus); clicking on the tab background still takes the focus away, but I think it's by design (as it does accept clicks and double clicks). You can try this behavior yourself after checkout from the upgrade branch and let me know if it does indeed address the issue.

dexmar commented 5 years ago

@pkulchenko tested with the upgrade branch and the problem is resolved! Thank you very much for looking into this. This bug isn't a showstopper but certainly qualifies as a minor annoyance.

pkulchenko commented 5 years ago

@dexmar, good; thank you for checking. I'll close this when the changes in the upgrade branch are merged (cc #999).

pkulchenko commented 4 years ago

This has been implemented as part of the changes in #999 that have been merged.