GithubHelp home page GithubHelp logo

sbmpost / autoraise Goto Github PK

View Code? Open in Web Editor NEW
1.4K 14.0 58.0 6.74 MB

AutoRaise (and focus) a window when hovering over it with the mouse

License: GNU General Public License v3.0

Objective-C++ 98.19% Shell 0.57% Makefile 1.25%
autoraise autofocus osx mouse

autoraise's People

Contributors

dimentium avatar fathah1 avatar sbmpost avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

autoraise's Issues

File-open dialogs sometimes refuse to say raised

I don't know how to repro this yet but when it happens it's very frustrating behavior. The mouse will be clearly inside the file-open dialog yet the window behind it will autoraise, making it very hard to use the file-open window (you can still do it if you're very quick).

Compatibility with Keyboard Maestro?

Hello!

I have a lot of keybindings set up in Keyboard Maestro that allow me to hit a given key combination to bring an application to the foreground. So, let's say for example, I hit "cmd+opt+shift+s" and that brings Slack to the foreground.

I only recently started using AutoRaise, and was hoping that the "warp" feature would work with this method of activating an application, but alas, it does not. Is there any way to get this to work? Ideally I think that the warp feature would have an additional option (or a separate option entirely) that basically says "anytime that a window takes focus (outside of the mouse being the one to activate that application), move the mouse to that window".

Is this possible and I just don't have the application configured properly?

Suggestion: set a different delay for a window on another screen

Hi,

I do not have much use of AutoRaise as it is now (maybe I have misconfigured it?). However, one feature I would really like is the activation of a window when my mouse moves to another screen.

I use 2 screens: my main iMac screen for most of the work and a second monitor for "supporting material". As such, I often have some applications on one screen and other applications on the other one, and I often need to copy/paste some contents between those applications on different monitors.

In such a scenario, I would love AutoRaise to automatically activate an application but only when the mouse goes to another monitor. In order to keep AutoRaise compatible with its current behaviour, I suggest creating a new delay setting for when the mouse pointer goes to a different screen, so that wouldn't change AutoRaise's current behaviour on a single screen.

Unistall/Remove AutoRaise

Hey,
I removed the AutoRaise file but it still starts, after every reboot. Surely there must be a way to completely remove it, that I am missin right?

Fixing macOS window state oversight in full screen apps

Hi,

This is not a bug report, but an idea.

I found that in many apps while in fullscreen, for example on two monitors or even split screen on a single monitor - active/inactive window state loses it's purpose and is almost invisible to the user. Right now I have two Microsoft Edge windows open in split screen and there is literally not a single way of identifying which is frontmost and therefore which has keyboard focus (switching between tabs with keyboard etc). I run AutoRaise to mitigate this. This is done by a Keyboard Maestro variable that looks for the fullscreen status via a menu item - as soon as KM identifies the the status as being full screen, it turns on AutoRaise. Switching to any app that is not full screen, AutoRaise is turned off.
This way, when in non-full screen (as originally designed) the user is in control of which window is frontmost by clicking because it is visible and identifiable. When the window(s) is/are full screen and window focus is non-identifiable AutoRaise handles the focus.
I hope it makes sense and gives an idea for a feature. A built in feature for this would be great because via Keyboard maestro there is a considerable delay between the activation and quitting of AutoRaise.

Focus-follows-mouse should always be immediate, just the actual autoraise delayed

(Thank you so much for making this! I've been waiting for this for... over 12 years. I'm the one who wrote the Stack Overflow question you cite in the README.)

Proposal: What it says in the title. That's how it works in Linux and I think it's better. More correct even. You always want the window the mouse is on to immediately have focus. It's just the autoraise -- bringing the window to the foreground, potentially covering up other things -- that should have the delay.

I recall having a delay of 500ms in Linux. When I try that here with AutoRaise it's way too much. But I conjecture that it would be fine if the focus-following part were immediate.

(As a kinda related thing, I see you suppress the autoraise when the mouse is moving, which is a very nice touch!)

Version for High Sierra

The created app bundle is for macOS 10.14. AutoRaise file is working on macOS 10.13.6 but every time on launch it is necessary to allow the "System Preferences - Security and Privacy - Privacy". Would it be possible to have a version to macOS 10.13.6 High Sierra? AutoRaise is a very useful and practical. Thank you.

Feature request: Mouse follows focus

Thank you for useful app!

Is it possible to add a new feature?

Description:
Moving cursor to focused window (when switching through hotkey or other way).

At the moment I use yabai for this behavioir (but 'focus follow mouse' functionality in your app match me better).

NSBundle.h:91:143: error: function does not return NSString

This might be due to some unmet requirement - I'm running BigSur 11.6.2 at the moment - but I thought I'd mention it here in the event someone else hits this.

`bhodgens@cloudbook:AutoRaise$ make install
g++ -O2 -Wall -fobjc-arc -o AutoRaise AutoRaise.mm -framework AppKit
In file included from AutoRaise.mm:25:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX12.1.sdk/System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:12:
/Library/Developer/CommandLineTools/SDKs/MacOSX12.1.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSBundle.h:91:143: error: function does not return NSString

  • (NSAttributedString *)localizedAttributedStringForKey:(NSString *)key value:(nullable NSString *)value table:(nullable NSString *)tableName NS_FORMAT_ARGUMENT(1) NS_REFINED_FOR_SWIFT API_AVAILABLE(macos(12.0), ios(15.0), watchos(8.0), tvos(15.0));
    ~~~~~~~~~~~~~~ ^ ~
    /Library/Developer/CommandLineTools/SDKs/MacOSX12.1.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSObjCRuntime.h:103:48: note: expanded from macro 'NS_FORMAT_ARGUMENT'
    #define NS_FORMAT_ARGUMENT(A) attribute ((format_arg(A)))
    ^ ~
    1 error generated.`

Any help is, of course, appreciated, though I'll be upgrading soon and I'd suspect that would fix things.

[feature] add animation to find cursor after warping

Sometimes I lose track of my cursor after using alt-tab to switch windows, because autoraise will move the cursor to the center of the freshly focused window.
Perhaps animating the cursor to the new location, or having the cursor blink or pulse to reveal its new position would be helpful.

Attached a patch file that shows a very hacky POC, that 'animates' the cursor. Ideally it would use a timer, and some physics. But this is more to show the idea.
demo.patch.txt

Only one Chrome window is ever autoraised

I just got a new M1 Mac and installed AutoRaise via Homebrew.

I'm seeing the following regression from the old version I had on my old Mac:

Replicata

  1. Install AutoRaise via Homebrew
  2. Open multiple Chrome windows
  3. Move the mouse over some other application
  4. Move the mouse to a different Chrome window

Expectata

That the Chome window that the mouse is on gets focus (aka focus follows mouse).

Resultata

Just one Chrome window ever gets focus.


This is pretty high severity for me, and I can't go back to the old binary I was using since it's not compatible with an M1 Mac.

Functionality not working with separate instances of Safari

Hi!

I like the app! I missed the functionality from linux, but I noticed that if I have two separate Safari windows open, it won't work as expected, you still need to physically click to change the focus. Is this intentional or was it missed?

The dialog windows and menu pop ups make the app lose focus to windows underneath

I am seeing some annoying and weird behavior. Let's say an app opens a File Choose dialog. If this dialog overlaps another app, it raises the window underneath after the delay, lowering the window which popped the dialog. So, I lose the app I was working on.

Same thing with menu pop ups. If I am in Firefox, I go to the apple menu bar and select file and move the mouse to any of the menu items, it will raise the window underneath that menu to the front.

Why is it not able to distinguish between the app's menu/dialog window vs the main window of another app?

Also, the Autoraise.delay is looked up in current working directory. In some cases, I run it as service, I can't control the current working dir. Is it possible to move that to my home dir i.e. always pick the file from ~/ instead of the current working dir.

Make Auto-Raise an Option

If this is possible, can there be an option to not auto-raise the window. The result would be that the focus follows the mouse and that's it.

Hey dude mouse follow focus not working

here is
also an option to warp the mouse to the center of the activated window, using the cmd-tab key combination for example.

I did as you told added a folder name in application folder and used chmod 700 AutoRaise, still after cmd+tab cursor did not made it's way int middle. And can you help me in automator i was not able to follow you.also thanks for making this available

Segmentation fault after some mins

I regularly hit a segmentation fault with the latest master:

./AutoRaise -delay 4

v2.4 by sbmpost(c) 2021, usage:
AutoRaise -delay <1=20ms, 2=40ms, ..., 0=warp only> [-warpX <0.5> -warpY <0.5> -scale <2.0> [-verbose <true|false>]]

Started with 80 ms delay
[1]    24410 segmentation fault  ./AutoRaise -delay 4

Are there some logs I could check?

AutoRaise/AutoFocus on mouse click only?

Hey,

Like many, I'm trying to get autofocus to work on MacOS after coming from a different OS that allowed this. However, I only want it to work on click. My only issue is that I sometimes have to double-click to click a button or link in another window.

Would this be possible with your nifty little app? I just want to eliminate the doubleclick, but not autoraise on hover.

Thanks! Kind regards,
Inigo

Raise when window is maximized

When command-tab is used to switch between a maximized app and a non-maximized app, moving the mouse back over the maximized app does not auto-raise or focus. This behavior is limited to just maximized apps. Maximized application being defined as: the menubar showing and 3 sides of the application touch the sides of the display and the top of the application is touching the bottom of the menubar.

Switch on hover

I wonder if it could switch on hover i.e. when the mouse is not moving. So it could switch very rapidly if the mouse stops on the window and ignore the mouse is just crossing over a window. Anyway it seem workable as is, thanks.

Zoomed windows doesn't raise

Hi,

I don't know - is it bug or feature :)
But zoomed windows doesn't jump up.
There is video:

Screen.Recording.2021-01-24.at.20.25.37.mov

Make AutoRaise coexist with "Witch" and BetterTouchTool

Hi

Thank you first and foremost for such a good app!

For some time now the warp function doesn't work. I think it is since I moved to a setup with an external monitor. is there a problem for the warp functionality in this context?

Thanks.

Proposal: be robust to imprecise mousing

As discussed in #8, it's frustrating when AutoRaise accidentally happens due to imprecise mousing, like when you're trying to click something near the edge of the window and the mouse drifts slightly outside the window for too long.

(The ideal solution, what Linux window managers do, is instant focus-follows-mouse with like 500ms delayed autoraise. But Apple doesn't allow for that. There's no such thing as focus-follows-mouse without autoraise.)

One idea from @sbmpost was to add padding or an artificial border so that you have to go beyond that extra padding before AutoRaise considers the mouse to have left the current window.

But that's fraught. It can interact weirdly with the exception where a window doesn't get autoraised if it would fully obscure the current window. Also if a window is peeking out at the edge of the screen then it means that window can never be autoraised!

Proposal:

  1. An artificial border / padding is used to prevent the current window from losing focus if the mouse is only barely outside it.

  2. Exception: if the mouse is at the edge of the screen, that's intentional. Conceptually, having the mouse at the screen edge is like having it way past the screen edge. That's where I'm trying to go and am only stopped by the screen edge. It's not imprecise mousing.

  3. The "fully contained" exception only applies if the current window is truly fully contained -- no artificial border. We want to keep a window from totally disappearing. If it's peeking out, it's not totally disappearing.

Use mouse cursor 'warp' ONLY

How can I use the 'warp' feature without activating focus follows mouse and autoraise? I would like my mouse cursor to warp to the window when I cmd + tab but do not want the functionality of focus follows mouse and autoraise. Is this possible?

Feature: Decouple autofocus from autoraise

Hi,

I am a Linux user, using i3 as my [tiling] window manager. I have to use a Mac for work reasons. You cannot image how your small program makes me happy when switching over :-)

I'd have maybe a feature request: would it be possible to have a configuration option to choose whether we want just have the autofocus functionality without the autoraise?

Thank you!

Prevent autoraising while dragging or resizing a window

Bug report!

Replicata

  1. Take an iterm2 window that overlaps a google chrome window (I don't think it matters which apps)
  2. Click and hold the top edge of the iterm2 window at a spot where it's in front of the chrome window
  3. Slowly drag up and down to make the iterm2 window taller and shorter

Expectata

That I'm always on top of (the edge of) the iterm2 window so it should keep focus.

Resultata

The chrome window jumps in front of the iterm2 window!

Create a homebrew formula

It would be nice to have a formula for the popular homebrew package manager to install & update autoraise, even using a non-core tap.

Flicker Issue

On version 3.1 compiled with the EXPERIMENTAL_FOCUS_FIRST flag, I noticed a weird flicker in the Preview app when I tried to adjust the colours through the histogram. In the GIF below, one can observe the flickering when I hover the cursor around the histograms. In order to reduce the size of the GIF, I had to reduce the framerate but one can still see the histogram disappearing.

Kapture 2022-06-06 at 11 16 02

Renaming files and folders is difficult with AutoRaise turned on

I'm not sure how to solve this problem, but I have noticed that renaming files and folders is very difficult when AutoRaise is turned on.

I will try describe the reproduction steps as best I can:

  1. Open Finder and right-click on a file to rename it.
  2. At this point the "right-click menu" will disappear and the file name becomes editable.
  3. But because the mouse is now hovering over white folder space AutoRaise focuses on that, causing the file to immediatley stop renaming mode.

This makes it very hard to rename files and folders.

Because of this behaviour it would be great to have a setting that temporaily turns off AutoRaise while renaming files/folders.

Change focus when only screen changes

I have two monitors and I only want to change the focus when mouse switches between the screens, not the apps. Is there any feature for this purpose?

How can I run ./AutoRaise -delay 2 -warpX 0.5 -warpY 0.5 automatically?

How can I program macOS to run the command ./AutoRaise -delay 2 -warpX 0.5 -warpY 0.5 automatically on startup? This command is executed by right clicking on the Applications folder, and selecting new terminal tab here. I can't find a way for macOS to auto do this by its own on startup, rather I have to manually do it everytime i start the machine up. Any help would be much appreciated.

Proposal: app for macOS

I quickly made an app with the provided binary, perhaps you guys could make that one available for download that way it is not terminal-dependent.

https://www.mediafire.com/file/clb12ihiviosho7/AutoRaise.app.zip/file

to check the app for malware, just remove the ".app" and run a diff with the binary in the app and what you provide. Also, the info.plist may require a bit of adjustment for the copyright; I just provided placeholder stuff.

An app icon would be nice too:)

AWESOME SOFTWARE!!!! LOVE IT

Focus change to Finder

Great app, I didn't realize this existed. I'm been griping about MacOS focus for years.

I noticed when you have focus on an app like Safari, when you hover over empty desktop, it doesn't change the focus to Finder. I'm not sure if this is the expected behavior, or if I even dislike it. Is this expected, and if so, was that just the behavior you wanted?

Putting mouse in Chrome's file-chooser fails to trigger autoraise

Replicata

  1. In Google Chrome, choose "Open File" from the file menu.
  2. File-choosing popup modal thing pops up.
  3. Move cursor to any other window (another Chrome window or another app, doesn't matter)
  4. The other window autoraises fine
  5. Move cursor back into file-chooser popup.

Expectata

Autoraise should happen.

Resultata

The window from step 3 stays focused and raised. I.e., autoraise fails to happen. (If in step 5 you move the cursor to the window from step 1 but outside the file-chooser popup then autoraise works as expected.)

Doesn't raise emacs (mostly)

Thanks very much for this software!

I've run into one problem - emacs windows aren't raised on mouse over. Strangely, even mousing over the window title bar doesn't work. Well, with one exception - if the emacs toolbar is enabled, mousing over that does raise.

I've installed emacs from homebrew: brew install emacs.

When using autoraise.app where do I create the config file?

These are the steps I have done:

  1. I downloaded the master branch
  2. Unzipped it inside my downloads folder
  3. Ran cd ~/AutoRaise-master && make clean && make
  4. Moved autoraise.app to the applications folder
  5. Deleted the remaining files in the downloads folder since I was not using them (was this correct?)

After all that the app works fine.

But now I want to setup a configuration file as per the Readme, and I don't know where to place that file.

The autoraise.app application I moved from the downloads folder to the applications folder was just a single file. So I don't know how to create a configuration file "inside" of that.

Hide config files

Thank you very much for making this app, love it! One idea, could you make AutoRaise.app look for hidden files in the home directory instead, ie ~/.AutoRaise.delay and ~/.AutoRaise.warp?

Regression: special case for display boundary when suppressing autoraise

As I understand it, there's a safety margin to avoid accidental autoraising when resizing windows: If the mouse cursor is just barely outside of a window then we assume you didn't mean to actually leave the window, so autoraising is suppressed.

That's fine but there should be an exception to that if the mouse cursor is at the edge of the display. See a screenshot in a previous gissue for my use case here.

In short, if a window is peeking out from behind another window and that peeking-out window is flush with the display boundary, I should be able to fling the mouse cursor to the boundary to make the peeking-out window autoraise.

This used to be how it worked (after some discussion in #8) but seems to have regressed.

When using autohide menu bar on an external monitor, hovering over the menu bar raises the window underneath

Hello, this is such a great utility. No "focus-follows-mouse" is always the thing I miss most from Linux.

I noticed that when using the MacOS autohide menu bar setting with an external monitor, hovering over the menu bar (in its revealed state, on top of any windows underneath) raises the window underneath, preventing access to the menu bar. I wondered if this is a bug; it seems to me as though any window obscured by a visible menu bar should not be raised.

Make it focus without bringing window to the front

Similar to ctrl+opt+click, I'd like to config this tool to focus a window without bringing it to the front of all other windows. The primary use-case for this tool for me is to focus on a window for quick access to keyboard shortcuts for that window. The focus without raise feature could be instant or customized to a specific delay.

If I want to bring the window to the front, then it would be nice to make this tool bring the window to the front after 500ms of no cursor motion. This way I can move my cursor anywhere without raising windows but focusing instantly on windows. Only after stopping my cursor on one window will the window be raised. This is the ideal UX I'd like to achieve. Is this doable?

Change focus only when on different monitors

Hi,

First, thank you for developing this very useful app. I am wondering if it's possible to only switch the focus when the cursor is on different monitors. If two apps are on the same desktop/monitor, the focus should not change.

Thanks.

Ignore `NSMenu` window

AutoRaise causes problems with menu bar apps that use NSMenu since it tries to activate the app. When a NSMenu is open and the app gets activated, the NSMenu closes immediately.

I'm not familiar with the AX APIs, but you may be able to detect that it's a NSMenu window. The class name for a NSMenu window is NSMenuWindowManagerWindow.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.