Make Focus() / Blur() reliable and let Blur() return focus to the previous app
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- cpp
- Domain
- desktop, operating-systems
Research direction
Start by locating the platform implementations of Window::Focus(), Blur(), and IsFocused(), then inspect the Windows, Linux, and macOS focus behavior described in the issue. Done means focus changes succeed reliably across those platforms and Blur() returns focus to the previously active window or app.
Written by the indexing model from the issue text.
Description
Window::Focus() and Blur() follow the platforms' simplest calls and fail in common cases:
- Windows:
Focus()isSetForegroundWindow+SetFocus, which the foreground lock refuses when the app isn't in the foreground (only the taskbar flashes). Consider theAttachThreadInput/AllowSetForegroundWindowapproaches, and checkIsFocused()after focus changes. - Linux:
gtk_window_present()without a timestamp is subject to focus-stealing prevention; usegtk_window_present_with_time()with the last event time. Blur()should hand focus back to the previously active window or app. On macOS it only doesorderBack:, and on WindowsSetFocus(nullptr), which leaves the app active. Typical use: a launcher/search bar that hides and pastes into the previous app. Related: libnativeapi/nativeapi#59 (app-level hide on macOS).
Background:
- leanflutter/window_manager#364: focus() not always working, isFocused() always false (Windows)
- leanflutter/window_manager#218: focus() doesn't focus the window on Ubuntu
- leanflutter/window_manager#387: how to unfocus the window and bring back the previous one
- leanflutter/window_manager#352: focus the previous window when hiding
- Dominant language
- C++
- Stars
- 34
- Forks
- 7
- Avg merge
- 3d 1h
- Merged PRs (30d)
- 1
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from libnativeapi/nativeapi
-
bug
Difficulty 4/5 3-5 days Newbie friendliness 45/100
libnativeapi/nativeapi#81 ·
-
bug
Difficulty 4/5 3-5 days Newbie friendliness 45/100
libnativeapi/nativeapi#80 ·
-
bug
Difficulty 4/5 3-5 days Newbie friendliness 35/100
libnativeapi/nativeapi#79 ·
-
bug
Difficulty 4/5 3-5 days Newbie friendliness 45/100
libnativeapi/nativeapi#78 ·
-
bug
Difficulty 4/5 3-5 days Newbie friendliness 45/100
libnativeapi/nativeapi#77 ·
All issues in libnativeapi/nativeapi
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
objectionary/eo-graphs#74 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 95/100
-
enhancement
Difficulty 1/5 Under an hour Newbie friendliness 88/100
QuantStack/git2cpp#187 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100