I would like to create an app that intercepts the mouse coordinates and modify them.
I want to build an app that runs in the background and intercepts the mouse movement, filtering it, for all apps running on macOS.
Suppose the mouse is scrolling freely but if the user presses a global shortcut, like CMD ALT X, the vertical scrolling is filtered and just the horizontal scrolling passes to macOS.
First question: what should I use to do that? Just point me in the right direction if the topic is too extensive.
Second question: is that possible to do for a sandbox app?
Is there any sample code or article/guide suggesting how to best implement a click+scroll feature as common in apps like Adobe XYZ, Pixelmator, ..:
The user clicks in a view while holding down the Space key to scroll the view
Should we just move the containing scroll view every time the mouse moves by the delta amount since the previous mouse moved event?
Is there any built-in functionality in NSScrollView that we can hook up to in order to perform the click-&-drag scrolling?
Or should we simulate clicking&dragging the scrollbar via the NSScroller APIs?
Any hints appreciated!
Not looking for sample code to copy&paste here, more what's the best/most compatible/least code strategy!
Let's say I have a floating, borderless, circular NSWindow.
It is circular because the content view simply draws a red circle.
That content view needs to be layer-backed ([contentView setWantsLayer:YES]), because I'm applying CoreAnimations on it, e.g., animated scaling.
Usually, the clickable area of a NSWindow is defined by the transparency of the pixels of the content view. However, once the content view of a NSWindow becomes layer-backed, transparent areas will also receive clicks, unfortunately.
In my case, this is a serious problem, because I only want to receive clicks within the radius. But now, a click within the rect of the window, but beyond the circle radius, will activate the window (and thus, the entire app), which it shouldn't. Also the window is draggable via the corner of its content view.
My initial thought was to implement [NSWindow sendEvent:] in a subclass and check whether the click was performed within the radius, using [theEvent locationInWindow]. I thought I could simply discard the event, if it's beyond the radius, by not calling [super sendEvent:theEvent] then. This however did not work: I noticed, that the mouseDown:; window method is called even before the sendEvent:; method.
I've search a lot but the only idea I found, was to have a proxy like non-layer backed NSWindow on top of the window, which delegates clicks conditionally, but this led to unpredictable UI behavior.
Do you guys have any idea, how to solve it?
So after a few weeks, I came to the following results:
A) Proxy window:
Make use of a non layer-backed proxy window, which is placed on top of the target window as a child window. The proxy window has the same shape, as the target window, and since it is not layer-backed, it will properly receive and ignore events. The proxy window delegates all events to the target window by overwriting sendEvent:. The target window is set to ignore all mouse events.
B) Global Mouse Pointer observation:
Install both a global and local event monitor for NSMouseMovedMask|NSLeftMouseDraggedMask events using addGlobalMonitorForEventsMatchingMask and addLocalMonitorForEventsMatchingMask. The event monitors disable and enable ignoring mouse events on all registered target windows based on the current global mouse position. In the case of circular windows, the distance between the mouse pointer and every target window must be calculated.
Both approaches work well in generally, but I've been experiencing some unpredictable misbehaviors of the child window approach (where the child window is 'out-of-sync' of its parent's position).
UPDATE: Both approaches have some significant disadvantages:
In A), the proxy window sometimes may be out of sync and may be placed slightly off the actual window.
In B), the event monitor has a big impact on battery life while moving the mouse, even if the app is not the front-most application.
If you want to Discard mouseDown event based on position you can use the:
CGPathContainsPoint(path,transform,point,eoFill):Bool
Setup your path to match your graphics. Circles, ellipses, rectangles, triangles or paths and even compositional paths (paths with holes in them).
The only thing which I disklike whith highslide is the fact that when I click a thumbnail and it gets bigger I only can shrink it back when I click exactly in the image area.
Is it possible to shrink the image back when clicking outside the image area?
(and optional also shrink it back when I hover outside the image with the mouse cursor?)
Thanks
If you use a dimming background (hs.dimmingOpacity=0.7, for example), clicking outside the image area will close the expander. This requires highslide-full.js. If you don't want a dimming background, just set the opacity to a tiny value, like hs.dimmingOpacity=0.01.
It might be possible to include an onAfterExpand event to close the expander when you hover outside the image, but I think I can guarantee that you wouldn't like it. If a visitor clicked on a thumbnail, but didn't just happen to have his mouse over the image when it opened, it would immediately close again. That would be very frustrating behavior for the site visitor.
In almost any Windows application, I notice that holding the mouse button down in a non-client area causes the painting to stop. Why is this required?
For example, I have a Managed Direct 3D application which displays a spinning cube. If I place the pointer over the title bar and hold the mouse button down, the cube ceases to spin even though I have not coded any such condition into my loop.
Why is painting halted? What are the benefits? Most importantly, how can I work around this?
When you click on the title bar, there's a brief pause while the window manager tries to determine whether or not you're clicking or beginning a drag (moving the window). If you're still holding down the button, then it's a drag: the window manager sets up its own message loop and pumps messages until you release the mouse. Your window should still be able to process messages, because they'll still be dispatched, but if your animation depends on a custom message loop then you'll be stuck 'till the modal drag loop ends.
Work around it by triggering your animation in response to messages: a timer seems like a good choice to me.