I appreciate, once again, all of your great work on the recent 2.16 Betas. An issue has been bugging me for years, so I finally thought of a possible solution which is hopefully a (relatively) straightforward and useful feature to add to XMBC (perhaps in the next beta series). I wouldn't be at all surprised if this has been previously mentioned. Let me explain.
Per profile (in each layer), provide a checkbox option to 'Activate' the window under the cursor when the 'Middle Button' is pressed - This option is ONLY needed for the middle button (see below).
With the exception of the 'Middle Button', ALL of the other (non-wheel) mouse button presses automatically activate the window under the cursor (if it is not already active). Go ahead try them all... This presents an issue for XMBC users (like myself) who have profile customizations for the 'Middle Button' in that it often produces unexpected (and undesired) behaviors when clicking the 'middle button' while hovering over a non-active window.
, I've defined my 'middle button' to issue the 'Close' command in my 'Default' XMBC profile and defined it to issue 'Ctrl+W' simkeys (Close Tab) in my 'Chrome Browser' profile. So if I casually hover over a non-active Chrome window and start scrolling up/down and then decide I want to now close the tab with the 'Middle Button', XMBC (via default Windows behavior) sends the 'Ctrl+W' command to whatever non-chrome active window which 'fakes me out'
and often ends up closing unintended windows (like MS-Office Apps or File Explorer) that also interpret 'Ctrl+W' as close window. So I then have to waste time reopening these windows and then remember to activate the Chrome window before clicking the 'Middle Button' again.
There are also several other frustrating cases I could mention, but I'll refrain to keep this post succinct. This situation ONLY exists with the 'Middle Button' in XMBC because Windows naturally 'activates' a non-active window (or Desktop) under the cursor when ANY of the other (4) mouse buttons are pressed while hovering - But fails to do so with the Middle Button (I'm guessing that this works ok for the default Middle button 'multi-scroll' functionality - which many, including myself, never use).
Without a ton of work, XMBC could be uniquely positioned to alleviate this inconsistency (and the resulting undesired behavior) by providing a simple option to 'activate the window under the cursor'
before sending any 'Middle Button' associated commands or keys. Perhaps a checkbox next to the 'Middle Button' on each profile layer could be implemented to provide the most flexibility and backward compatibility (See attached Screenshot Mockup).
What do you think of this idea? Have you (or anyone else) also experienced this issue/frustration?
Your feedback and consideration on this is much appreciated!
You do not have the required permissions to view the files attached to this post.