[Compiz] [Bug 455241] Re: New windows steal focus
I don't know which was first metacity or mutter, but it seems that both projects use the same approach (https://bugs.launchpad.net/hundredpapercuts/+bug/495403/comments/9). I don't know why compiz insists on going a different route after more than 7 years of complains. -- You received this bug notification because you are a member of compiz packagers, which is subscribed to compiz in Ubuntu. https://bugs.launchpad.net/bugs/455241 Title: New windows steal focus To manage notifications about this bug go to: https://bugs.launchpad.net/compiz/+bug/455241/+subscriptions ___ Mailing list: https://launchpad.net/~compiz Post to : compiz@lists.launchpad.net Unsubscribe : https://launchpad.net/~compiz More help : https://help.launchpad.net/ListHelp
[Compiz] [Bug 455241] Re: New windows steal focus
FWIW The GNOME mutter project contains a detailed explanation about how to handle window focus to never have "focus stealing": https://github.com/GNOME/mutter/blob/master/doc/how-to-get-focus-right.txt Quote follows: Also, sometimes a new window will be mapped (e.g. unminimizing a window or launching a new application). Most users want to interact with new windows right away, so these should typically be focused. This does conflict with the invariants for sloppy and mouse focus modes, so this wouldn't be true for a strict-pointer-focus mode. For all other modes (non-strict-pointer-focus modes), there are only two cases in which a new window shouldn't be focused: 1) If the window takes a while to launch and the user starts interacting with a different application, the new window should not take focus. 2) If the window that will appear was not launched by the user (error dialogs, instant messaging windows, etc.), then the window should not take focus when it appears. To handle these cases, Metacity compares timestamps of the event that caused the launch and the timestamp of the last interaction with the focused window. (Case 2 is handled by the application providing a special timestamp of 0 for the launch time, which ensures that the window that appears doesn't get focus) If the newly launched window isn't focused, some things should be done to alert the user that there is a window to work with: 1) The _NET_WM_DEMANDS_ATTENTION hint should be set 2) If the new window isn't modal for the focused window, it should appear below the focused window so that it doesn't obscure the focused window that the user is interacting with. 3) If the new window is modal to the focused window, the currently focused window should lose focus but the modal window should appear on top. -- You received this bug notification because you are a member of compiz packagers, which is subscribed to compiz in Ubuntu. https://bugs.launchpad.net/bugs/455241 Title: New windows steal focus To manage notifications about this bug go to: https://bugs.launchpad.net/compiz/+bug/455241/+subscriptions ___ Mailing list: https://launchpad.net/~compiz Post to : compiz@lists.launchpad.net Unsubscribe : https://launchpad.net/~compiz More help : https://help.launchpad.net/ListHelp
[Compiz] [Bug 1607472] Re: compiz lockscreen crashed with SIGABRT in AcceleratorController :: OnActionActivated
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: compiz (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of compiz packagers, which is subscribed to compiz in Ubuntu. https://bugs.launchpad.net/bugs/1607472 Title: compiz lockscreen crashed with SIGABRT in AcceleratorController :: OnActionActivated To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1607472/+subscriptions ___ Mailing list: https://launchpad.net/~compiz Post to : compiz@lists.launchpad.net Unsubscribe : https://launchpad.net/~compiz More help : https://help.launchpad.net/ListHelp
[Compiz] [Bug 1430888] Re: DRI_PRIME with radeon/intel windows do not draw
more probably candidate is mesa, please test yakkety which has 12.0.1 commit 9ee3f097b65398250e836785a7e87520eda8298d Author: Michel Dänzer Date: Thu Jun 9 15:15:19 2016 +0900 st/dri: Clear drawable texture_mask in dri2_invalidate_drawable This makes sure that dri_set_tex_buffer2 -> dri_drawable_validate_att will re-create the front left attachment buffer after the drawable got invalidated. Fixes window contents not updating until the window is resized when using DRI2 PRIME. Reviewed-by: Nicolai Hähnle Reviewed-by: Marek Olšák ** Package changed: compiz (Ubuntu) => mesa (Ubuntu) ** Changed in: mesa (Ubuntu) Assignee: (unassigned) => Timo Aaltonen (tjaalton) ** Changed in: mesa (Ubuntu) Status: Confirmed => Incomplete -- You received this bug notification because you are a member of compiz packagers, which is subscribed to compiz in Ubuntu. https://bugs.launchpad.net/bugs/1430888 Title: DRI_PRIME with radeon/intel windows do not draw To manage notifications about this bug go to: https://bugs.launchpad.net/xorg-server/+bug/1430888/+subscriptions ___ Mailing list: https://launchpad.net/~compiz Post to : compiz@lists.launchpad.net Unsubscribe : https://launchpad.net/~compiz More help : https://help.launchpad.net/ListHelp
