Comment 3 for bug 880672

Revision history for this message
James Pharaoh (jamespharaoh) wrote :

I didn't see this bug because I am trying to fix behaviours specific to raise-on-click. I've applied the patch and it still fails miserably for me.

My changes are intended to fix the behaviour for people who use focus-follows-mouse with raise-on-click disabled. The following behaviour is what I expect:

- Click on title bar raises the maximised window
- Drag title bar moves the maximised window, without raising it

The solution accepted for the previous bug fails because dragging the title bar both raises and activates that window. We need to make sure that the window is only raised and activated when the user spdecificly clicks rather than drags if raise-on-click is disabled.

My patch will probably need a little modification to apply to the upstream unity and ubuntu head where this patch has been applied. For a start, I've modified the existing OnMaximizedGrabStart function whereas the patch adds a new OnMouseClicked. I have also removed a call to WindowManager::Activate in OnMaximizedGrabMove. The patch uses Raise instead of Activate although I'm not sure what the impact of this is.

The biggest difference in my code is that I've created a new class called Behaviour and passed this through various constructors into PanelMenuView. This provides an interface for querying the raise-on-click setting, and can of course be extended for any other settings in the future.

So anyway, in my case there is definitely still a problem and it seems sensible to manage it with a separate bug. The description is probably a little confusing.

What should I do now? Do you accept the intention of the changes I am making here? I can create a new version against unity upstream if that's what is required.

To be honest I am finding loads of problems with my "unusual" setup of focus-follows-mouse and raise-on-click disabled. I am probably going to try and drive an effort to tackle all of these issues together over the next few weeks.