Skip to content

Conversation

@IMbackK
Copy link
Contributor

@IMbackK IMbackK commented Jun 3, 2020

Ignore mb_wm_client_want_focus in mb_wm_client_base_take_focus and mb_wm_client_base_focus
because getting wants_focus from x11 wid dose not work and results in the root window gaining focus

…_wm_client_base_focus

because getting wants_focus from x11 wid dose not work and results in the root window gaining focus
@freemangordon
Copy link
Contributor

Not to be picky, but maybe squash all the focus changes into one commit (or several commits, separated by functionality/logic), I am not sure I'll be able to do any other type of review but coding style otherwise. @MerlijnWajer - what do you think? Also, please elaborate on what this patch is fixing, as it is not clear why "...getting wants_focus from x11 wid dose not work..." - is that a bug introduced by previous patch or it was there all the time, or... ?

@MerlijnWajer
Copy link
Member

@freemangordon - I don't think we want to squash the commits already in master, that's effectively rewriting the git master history - let's not.

@IMbackK - I'd like to merge this ASAP since I think I'm also being hit by some of the bugs, can you elaborate a bit more what this attempts to fix? Just a few more sentences so we know what's going on.

@freemangordon
Copy link
Contributor

@MerlijnWajer - ok, lets not force-push then. But still I would like to have some explanation on the fix.

@MerlijnWajer
Copy link
Member

@freemangordon -

21:33 < Wizzup> uvos: btw if you can, please comment on the focus PR
21:33 < Wizzup> I want to get it done tonight
21:34 < uvos> Wizzup: i cant/ dont want too untill i know why wants_focus dosent work
21:34 < Wizzup> I thought it fixed it?
21:34 < uvos> Wizzup: i have no good awnsers to freemangordon's questions
21:34 < uvos> Wizzup: no the focusing is fixed by ignoring wants_focus
21:34 < Wizzup> honestly the only problems I see is that osso-xterm loses focus when a menu or something else pops up
21:35 < uvos> Wizzup: wants_focus is sometimes wrong
21:35 < Wizzup> # sleep 120 ; /etc/init.d/droid4-powermanagement status
21:35 < Wizzup> d=2020-06-08|t=19:34:26|i=OFF:0,RET:3306|p=102|c=NA|b=none
21:35 < Wizzup> still not quite there, but I think if it idles a bit longer it'll get there
21:35 < Wizzup> ok, back a bit later
21:35 < uvos> Wizzup: the root window is focused, often this is very broken but causes stock x11 focus follows mouse behavior
21:35 < uvos> masking the problem
21:36 < uvos> if you need something that works now
21:36 < uvos> please either commit forcus patch 3, knowing that this is a temporary solution untill i know what the deal is with wants_focus
21:36 < uvos> or revert to focus patch 1
21:36 < uvos> for non devel at least
21:36 < Wizzup> first, reverting patch 2 ?
21:37 < uvos> ?
21:37 < Wizzup> iirc there were three PRs
21:37 < Wizzup> one where you, fmg and I worked a lot on - the first one
21:37 < Wizzup> then a second one by you, which I merged
21:37 < Wizzup> and this is the third one
21:37 < Wizzup> so you're saying revert back to the state of PR 1
21:37 < uvos> either A: apply focus patch 3 and wait for 4 or, or revert 2
21:38 < uvos> number 2 is very broken
21:38 < uvos> number 1 and 3 are equaly somewhat broken
21:38 < Wizzup> ok
21:38 < Wizzup> going to hop to the shop quickly
21:39 < uvos> Wizzup: so your goning to apply 3 or revert 2?
21:39 < Wizzup> yeah seems like an improvement either way
21:39 < Wizzup> brb- otherwise shop will be closed
21:39 < uvos> ok
21:40 < uvos> pach 1 has the benefit of being well tested - i would recommend reverting 2 for now and wating for 4
21:41 < uvos> or kepping at patch 1 for non-devel and going 3 for devel
21:41 < uvos> pr 3 or pr 2 state should definatly not go into non-devel
21:47 < uvos> so here is the executive summary on the patches:
21:48 < uvos> patch 0: _net_active_window dosent work breaking qt
21:48 < uvos> patch 1: _net_active_window dosent work with workaround for qt
21:48 < uvos> patch 2: focuses root window, causing focus follows mouse behavior and lots of breakge
21:49 < uvos> patch 2: wants_focus is ignored, causing windows that dont want keyboard focus to be focused
21:49 < uvos> *patch 3
21:55 < Wizzup> I'd like to go to patch 1, since I've seen that work for all my purposes at least

@parazyd
Copy link
Member

parazyd commented May 2, 2021

@IMbackK Is this in any way related to the other PR #7 I just merged?

@IMbackK
Copy link
Contributor Author

IMbackK commented May 2, 2021

no, and this pr is still eventually required (dont merge it as is it dosent work right), if we want __NET_ACTIVE_WINDOW/input focus to work correctly in all cases. admittedly the cases it dose not work right atm involve clients that have multiple windows that are both visible at the same time. this ofc is impossible in hildon.

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.

4 participants