| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Remove this file as it isn't relevant at this point. We'll go with the
simplified About panel instead.
|
|
Don't use my initials.
|
|
|
|
Remove: File, Edit, View, Format
These don't apply to this app and their functions aren't relevant here.
|
|
|
|
|
|
|
|
The framework was getting copied to Resources/, but the app was told to
look for it in Frameworks/, so it was crashing on launch.
Here's the error:
Dyld Error Message:
Library not loaded: @executable_path/../Frameworks/MASShortcut.framework/Versions/A/MASShortcut
Referenced from: /Users/USER/Documents/*/Low Battery Yup.app/Contents/MacOS/Low Battery Yup
Reason: image not found
Thank goodness for Console and logging and crash logs. Never would have
figured this out otherwise. Worked fine in Debug configuration and when
building for Release in Xcode. Just didn't work in the final archived
app. Works now though, phew!
|
|
|
|
Include a description of the problem case and application, a screencast
and screenshot, installation information, and license information.
|
|
My release build was failing because of this error:
error: -fobjc-arc is not supported with fragile abi
Set MASShortcut to force 64-bit architectures because it uses ARC and
from what I understand ARC can only be used on 64-bit.
|
|
|
|
|
|
|
|
* 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.
|
|
|
|
Add the necessary keys to the launchd plist to start the daemon
application with the right properties on login.
Used the Tunnelblick launchd plist as a reference.
|
|
Add a new button to the UI that either launches or quits the daemon
depending on whether it's currently running.
The button is set as a "Toggle" type that will cycle between "Launch
Application" and "Quit Application" labels when clicked.
Depending on the button's state (0 or 1), it will either launch or quit
the daemon.
The button's initial state is set on the UI application's launch to
determine how it should read & what it should do.
|
|
This reverts commit e5debc332f2b11f4e768e0a5b0f2b8770c25523e.
Actually, I don't really like that. The methods should instead do first
and error if it doesn't work. Why bother checking? We'll keep the
`isRunning` method around though because we need it to know what the
"Launch Application" button should read.
|
|
If the daemon is already running when `launch` is called, don't bother
launching. If the daemon is not running when `quit` is called, don't
bother quitting.
|
|
Says whether or not the daemon app is currently running.
|
|
Launch the daemon when checked and quit it when unchecked.
Now that I'm committing this, I don't really think this is the exact
right behaviour. I think running and terminating the app should be maybe
a different control so that running it isn't contingent on having it
start at login.
|
|
Add "Low Bettery Yup.d" to "Low Battery Yup"'s Target Dependencies and
copy the "Low Bettery Yup.d.app" bundle into "Low Battery Yup"'s bundle
resources.
This will allow us to distribute the daemon more easily so there's only
one app that users see instead of two. It also allows us to locate the
app more easily since it's contained within the UI app's application
bundle.
|
|
Add a Key-Value Binding in Interface Builder to
`NSUserDefaultsController` so that the checkbox value gets persisted
between launches of the app.
This fixes the bug mentioned in a77a053f90a7b2588dbaabedbf25f908680f2f30
such that now unchecking the box and closing the app will result in the
checkbox being unchecked on the next launch.
Wow, that was super easy!
|
|
A new checkbox in the UI that asks whether the app should start at
login. Checking and unchecking the box moves a LaunchAgent plist into
and out of `~/Library/LaunchAgents/`. This plist file will define
instructions to start the daemon on login.
Also add a `DaemonLauncher` class that will launch or quit the daemon
when the checkbox is clicked.
Bug:
Currently the app always starts with the checkbox checked. That's not
what should happen. Instead, we should save the checkbox value to
`NSUserDefaults` so that it has the previous value when the program is
launched.
|
|
Add the method to the header file from the original commit in
319dd672e1c75f39bcb9239117e520513da6609a.
|
|
Keep the code more organised by defining a name for this functionality
since we want to add some additional code here to handle the "Start at
login" checkbox.
|
|
This will enable and disable the daemon and set whether or not it starts
at login.
|
|
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!
|
|
Reopened the Xcode project after this merge
1cf0b1458248b75c3270b3b6cc7edc643e810929 and Xcode updated the file.
|
|
Conflicts:
Low Battery Yup/en.lproj/MainMenu.xib
|
|
Automatically merge this file. I got conflicts in it trying to do a
merge and it seemed like a bad time. Not conflicts I should be resolving
myself manually.
Got the tip from a Stack Overflow answer by Josh Brown:
http://stackoverflow.com/questions/31541624/merge-conflicts-with-project-pbxproj-on-git-xcode-ios/32567843#32567843
According to this, though:
http://stackoverflow.com/questions/12907605/xcode-project-file-git-merge-conflict
that won't work in all cases. We'll try it anyway and hope for the best.
|
|
Since `kPreferenceGlobalShortcut` was defined in two different files,
extract it to a single file that gets imported where it's needed so
we're not doubly defining the same string.
|
|
If a global keyboard shortcut has been stored in the `NSUserDefaults`,
display that in the shortcut selection widget.
|
|
Because it's more explicit about the methods in our .m file and that
makes it clearer.
|
|
Broke the reference to `_shortcut_view` in
a984e2dd951bcbfe5e3e6374213eb9a5fd5423cf so when we called methods on
it, they didn't work. This fixes it. Oh man that gave me a hard time.
Glad I took a break and had an idea to call methods on the superclass
and see if they worked. They did, but not methods on `ShorcutView`. So
from that I figured out that I needed to update this reference.
|
|
This will enable us to access it later in the daemon.
|
|
Clean up the code after that commit. A whole bunch of stuff is no longer
necessary so get rid of it all.
|
|
Fuck damn it finally freaking works! Damn, just had to take a 1.5 hour
nap after that.
We're finally able to extract a shortcut out of the MASShortcutView.
After trying a whole bunch of different things, I ultimately tried
opening the debugger and figured out that for whatever reason the
bindings weren't getting created and because of that my shortcut wasn't
getting saved in the user defaults.
Couldn't figure out how to get the binding to work even after includes
and whatnot.
Finally decided screw it I'm going to subclass the view and get the
shortcut and store it in `NSUserDefaults` myself. So that's what we're
going to do and this is the first step to getting that working.
Hoo boy.
Definitely need to vaccum the code after this.
|
|
|
|
This app has only one window and one function. Since it's so simple, it
only needs to be open for a short time. It should close when its window
is closed.
|
|
Add a text field to the MainMenu.xib primary window and use it to allow
users to type hotkeys. I'm thinking we might use this instead of
MASShortcut since I've been having trouble getting that to work
(couldn't figure out how to get a registered hotkey out of
NSUserDefaults).
This tool seems simpler, and could be just the ticket.
|
|
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.
|
|
Also remove the `@property` for the window because we're old school.
|
|
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.
|
|
|
