Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Respect FocusIn/Out mode in a hacky way #162

Closed
wants to merge 2 commits into from

Conversation

iacore
Copy link

@iacore iacore commented Jul 8, 2022

Attempt to recreate different focus "mode" with Xlib API. Works good enough.

@DemiMarie

Attempt to recreate different focus "mode" with Xlib API. Works good enough.
@DemiMarie
Copy link
Contributor

Does this have any remaining bugs that you are aware of?

@iacore
Copy link
Author

iacore commented Jul 8, 2022

No. I haven't used this separated patch though.

This still gets confused when VM transfer focus among its windows.

This fixed the bug that the mouse remains grabbed when the focused window is killed with "Close Window" from XFCE
@iacore
Copy link
Author

iacore commented Jul 10, 2022

This is still buggy. When window is killed with keyboard shortcut, Mouse focus is grabbed, but never returned.

@DemiMarie
Copy link
Contributor

Does e0265cd fix it?

@iacore
Copy link
Author

iacore commented Jul 11, 2022

Not entirely. I don't know much about how server-client tracks mapped windows. I only know about the X part.

The current issue is only that in AppVM 1, sometimes the focused window is destroyed (without user interaction), then the focus is transfered to another window in AppVM 2 (because it was previously focused in dom0), but AppVM 2 don't think it has focus.

Sadly, in a single AppVM, if there are three windows, the server may think (focus transfer) "A -> B", but the client thinks "A -> C". This is up to the window manager to decide what to focus after window "A" is destroyed, and we have 2 WM+X server.

I don't know how to fix this other than being the X server itself, and use custom WM/X server that is meant to be nested (don't know if we need XFCE4 inside AppVM). We should probably retire the current gui-proxy-thingy for a proper solution (custom X server). That would get other benefits like supporting multiple input devices of the same kind.

@DemiMarie
Copy link
Contributor

I don't know how to fix this other than being the X server itself, and use custom WM/X server that is meant to be nested (don't know if we need XFCE4 inside AppVM). We should probably retire the current gui-proxy-thingy for a proper solution (custom X server). That would get other benefits like supporting multiple input devices of the same kind.

@locriacyber: What about having a dummy window that is given focus whenever a window loses focus?
@marmarek: Am I correct that a custom X server is out of the question?

@iacore
Copy link
Author

iacore commented Jul 12, 2022

What about having a dummy window that is given focus whenever a window loses focus?
Users probably expect to have focus returned to last window they used (when a window is closed).

@DemiMarie
Copy link
Contributor

What about having a dummy window that is given focus whenever a window loses focus?

Users probably expect to have focus returned to last window they used (when a window is closed).

My thought was that this window would get a FocusIn event from the GUI daemon if it belonged to the same qube. Otherwise, it is better for no window to have focus.

@marmarek
Copy link
Member

@locriacyber: What about having a dummy window that is given focus whenever a window loses focus?

I think gui-agent already does something like this. Look for g->stub_win usage.

@iacore iacore closed this Aug 11, 2022
@iacore
Copy link
Author

iacore commented Aug 11, 2022

Superseded by #169

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants