| Age | Commit message (Collapse) | Author |
|---|
|
|
|
* Remove the old point assignments
* Remove the comments describing the pixel offsets from the bottom-left
of the low battery alert window
* Remove the NSLog for inspecting the frame rect values
* Remove the `width` variable which is no longer used
|
|
Previously, the point set to be clicked for the low battery alert was
only valid on a 13" 1440x900 screen. This change allows the click
functionality to work on any screen size.
I discovered in 954071bcc651ed5876d8ac0c3e8c253d4470c416 that I couldn't
use a percentage to get the height of the "OK" button.
But, the low battery alert uses `NSWindow`'s `-center` method, so I
thought up a hack to make a fake window, center it, and get the window's
frame dimensions. The fake window I create has the same (close enough)
dimensions as the low battery alert (measured from a screenshot).
I then use those dimensions to figure out where to click so that I'm
clicking in the right place on the "OK" button.
We also add a check to reinitialise the dimensions and reset the current
window if the main window has changed from what we thought it was. This
should allow the app to still work if you launch it from one display and
later plug in another as your main display where the low battery warning
will now appear.
We need to subtract the frame's Y coordinate from the screen height
because the frame origin uses standard bottom-left origin coordinates,
while `CGDisplayMoveCursorToPoint` uses top-left origin coordinates.
|
|
Wanted to get a percentage that I could apply to the height to get to
the right pixel position on the screen, but it doesn't seem like it's
going to be that simple. The percentages are off for a big screen and a
small screen, so I can't rely on a single percentage value.
After some research, my current idea is to make a fake window, call
NSWindow -center on it, and get the coordinates of that window to figure
out where the mouse should be positioned.
|
|
Get the shortcut saved from the windows application in our daemon and if
there is one, use that as the hotkey to activate the mouse click.
Yay! This is coming together!
|
|
Don't keep allocating and releasing `Mouse` objects when the hotkey is
pressed. Instead, allocate a single instance to use for the entire run
time of the application.
|
|
* Add DDHotKey library to the project. Just copy the files in from the
latest HEAD@e0481f648e0bc7e55d183622b00510b6721152d8.
* Only add DDHotKeyCenter.{h,m} & DDHotKeyUtilities.{h,m} to the "Low
Battery Yup.d" target as the *TextField file is only useful for a UI
to choose a hotkey, and we don't have a UI in this target.
* Set the DDHotKey* files to use ARC when compiling since they require
it. This was done by going to Build Phases -> Compile Sources and
adding this flag for both files:
-fobj-arc
this I figured out thanks to the following SO post:
http://stackoverflow.com/questions/6448874/disable-automatic-reference-counting-for-some-files/10255815#10255815
* Link Carbon.framework because DDHotKey depends on it to register
global hotkeys
* Move our mouse moving & clicking code to a new method that gets used
as the global hotkey action
* Fix a runtime error caused by MainMenu.xib not being available (as a
result of f0e8b5188e6fb984511eb01849380669e69632a6). To do this, we
modify `main.m` to bypass the check for MainMenu.xib as described in
this SO post:
http://stackoverflow.com/questions/6945872/cocoa-app-without-a-mainmenu-xib/6946016#6946016
* Delete the `window` `IBOutlet` since we no longer have a MainMenu.xib
and don't have a window in this app.
|
|
Since we alloc-inited the mouse, we need to make sure to release it when
we're done with it. Forgot to do this when I originally wrote this bit.
|
|
Since this is a backround app
(3db243f3c84f7ab36747f4badfd4f57a26563821), we don't have a UI and have
no need for any nib files.
We'll make an additional target as a separate application that does
have a UI and will allow customisation of the global hotkey.
|
|
Modify the coordinates such that instead of clicking the center of the
screen, we click the OK button on the low battery warning dialog.
Rename the method according to its new intent.
TODO: This probably doesn't work on other displays that have different
resolutions. We need to check that and figure out a cross-display
solution.
|
|
Make this a background-only app. We don't have any UI for the daemon
part of the app. It should just sit quietly until it's called by a
global hotkey to click in the right part of the screen.
|
|
Change the last space to a dot to make it more obvious that it's
supposed to mean 'daemon'.
|
|
This method isn't reused anywhere so it can go back into the
`moveToCenter` method.
Originally created before `_cursor_position`. See
1832514ab872dec621d5f403eb5328167b3da033.
|
|
Method that clicks the mouse.
* Add `_cursor_position` instance var that describes the current cursor
position after the `moveToPoint` method is called
* `click` will click at the `_cursor_position` point
* I had extracted the centering code to `centerPoint` (which maybe
should have been called `pointAtCenter`) out of the `moveToCenter`
method because I briefly used it in `click` as a test before adding
the `_cursor_position` ivar. This should be reintegrated with
`moveToCenter`.
* Add a `post_mouse_event` function that abstracts the CG calls needed
to send a mouse event since we need both click down and up events.
Based on:
http://stackoverflow.com/questions/1483657/performing-a-double-click-using-cgeventcreatemouseevent
|
|
* Create a `Mouse` class to group mouse movement and click functionality
* Add functions to move the mouse to the center of the screen (primary
display)
* Move the cursor to the center on launch
|
|
|
