focus-follows-mouse will make focus on desktop when mouse hover on it #7
Assignees
Labels
enhancement
New feature or request
Comments
|
I don't think that implementing a brand new |
LGUG2Z
added a commit
that referenced
this issue
Aug 23, 2021
Decided there should be a quick way to toggle the native ffm functionality, it gets especially annoying when trying to click drop downs from the system tray etc. re #7
|
@crosstyan you might want to try out this new |
|
@LGUG2Z I now prefer leaving I found an AHK script as a possible alternative to |
LGUG2Z
added a commit
that referenced
this issue
Sep 4, 2021
This commit implements an initial attempt at a custom focus follows mouse and autoraise implementation which only responds to hwnds managed by komorebi. I was browsing GitHub and came across the winput crate which has a clean API for tracking both mouse movements and button presses, which seems to be just enough to get this functionality working. Once again, Chromium and Electron are the bane of every platform they run on and Windows is no exception, so I've had to add a hack to work around the legacy Chrome windows that get drawn on top of Electron apps with the Chrome_RenderWidgetHostHWND class. It is fairly naive; it just looks up an alternative (and hopefully correct) hwnd based on the exe name, but this will no doubt be fragile when it comes to applications that have multiple windows spawned from the same exe. For now I've opted to keep the same komorebic commands for enabling, disabling and toggling focus-follows-mouse, in order to preserve backwards compat, but those commands will now enable and disable this custom implementation instead of the native Windows X-Mouse implementation. Perhaps in the future the specific implementation to target could be specified through the use of an optional flag. re #7
|
@crosstyan I've added a first attempt at a custom implementation of focus follows mouse that ignores the desktop and taskbar, I'm trying it out now and it seems okay for my relatively basic usage; if you get a chance it would be good to see if you come across any edge cases with it! |
LGUG2Z
added a commit
that referenced
this issue
Sep 4, 2021
This commit adds an optional flag to allow users to select the focus follows mouse implementation that they wish to use (komorebi or windows). The flag defaults to komorebi. The ahk-derive crate has been updated to enable the generation of wrappers fns that require flags. I pushed the ffm check up to listen_for_movements() so that we don't even try to listen to the next event from the message loop unless komorebi-flavoured ffm is enabled. re #7
LGUG2Z
added a commit
that referenced
this issue
Sep 7, 2021
This commit implements an initial attempt at a custom focus follows mouse and autoraise implementation which only responds to hwnds managed by komorebi. I was browsing GitHub and came across the winput crate which has a clean API for tracking both mouse movements and button presses, which seems to be just enough to get this functionality working. Once again, Chromium and Electron are the bane of every platform they run on and Windows is no exception, so I've had to add a hack to work around the legacy Chrome windows that get drawn on top of Electron apps with the Chrome_RenderWidgetHostHWND class. It is fairly naive; it just looks up an alternative (and hopefully correct) hwnd based on the exe name, but this will no doubt be fragile when it comes to applications that have multiple windows spawned from the same exe. For now I've opted to keep the same komorebic commands for enabling, disabling and toggling focus-follows-mouse, in order to preserve backwards compat, but those commands will now enable and disable this custom implementation instead of the native Windows X-Mouse implementation. Perhaps in the future the specific implementation to target could be specified through the use of an optional flag. re #7
LGUG2Z
added a commit
that referenced
this issue
Sep 7, 2021
This commit adds an optional flag to allow users to select the focus follows mouse implementation that they wish to use (komorebi or windows). The flag defaults to komorebi. The ahk-derive crate has been updated to enable the generation of wrappers fns that require flags. I pushed the ffm check up to listen_for_movements() so that we don't even try to listen to the next event from the message loop unless komorebi-flavoured ffm is enabled. re #7
|
After using this implementation for a week I'm happy to make it the new default. Changes have been merged to the |
alex-ds13
added a commit
to alex-ds13/komorebi
that referenced
this issue
Jan 21, 2025
# This is a combination of 8 commits.
# This is the 1st commit message:
fix(bar): add simplified config for bar
This commit creates a few new config options for the bar that should
make it a lot simpler for new users to configure the bar.
- Remove the need for `position`: if a position is given the bar will
still use it with priority over the new config. Instead of position
you can now use the following:
- `height`: defines the height of the bar (50 by default)
- `horizontal_margin`: defines the left and right offset of the bar, it
is the same as setting a `position.start.x` and then remove the same
amount on `position.end.x`.
- `vertical_margin`: defines the top and bottom offset of the bar, it is
the same as setting a `position.start.y` and then add a correct amount
on the `work_area_offset`.
- Remove the need for `frame`: some new configs were added that take
priority over the old `frame`. These are:
- `horizontal_padding`: defines the left and right padding of the bar.
Similar to `frame.inner_margin.x`.
- `vertical_padding`: defines the top and bottom padding of the bar.
Similar to `frame.inner_margin.y`.
- Remove the need for `work_area_offset`: if a `work_area_offset` is
given then it will take priority, if not, then it will calculate the
necessary `work_area_offset` using the bar height, position and
horizontal and vertical margins.
# This is the commit message LGUG2Z#2:
feat(bar): set margin/padding as one or two values
This commit changes the `horizontal_margin`, `vertical_margin`,
`horizontal_padding` and `vertical_padding` to now take a
`SpacingAxisConfig` which can take a single value or two values.
For example, you can set the vertical margin of the bar to add some
spacing above and below like this:
```json
"vertical_margin": 10
```
Which will add a spacing of 10 above and below the bar. Or you can set
it like this:
```json
"vertical_margin": [10, 0]
```
Which will add a spacing of 10 above the bar but no spacing below. You
can even set something like this:
```json
"vertical_margin": [0, -10]
```
To make no spacing above and a negative spacing below to make it so the
tiled windows show right next to the bar. This will basically be
removing the workspace and container padding between the tiled windows
and the bar.
# This is the commit message LGUG2Z#3:
fix(bar): use a right_to_left layout on right side
This commit changes the right area with the right widgets to have a
different layout that is still right_to_left as previously but behaves
much better in regards to its height.
# This is the commit message LGUG2Z#4:
fix(bar): use default bar height
When there is no `work_area_offset` and no `height` on the config it was
using the `BAR_HEIGHT` as default, however the automatica
work_area_offset calculation wasn't being done properly. Now it is!
# This is the commit message LGUG2Z#5:
feat(bar): monitor can be `MonitorConfig` or index
This commit allows the `"monitor":` config to take a `MonitorConfig`
object like it used to or simply a number (index).
# This is the commit message LGUG2Z#6:
docs(schema): update all json schemas
# This is the commit message LGUG2Z#7:
fix(bar): update example bar config
# This is the commit message LGUG2Z#8:
fix(bar): correct work_area_offset on secondary monitors
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm not sure if it's a bug (maybe it's a feature) but with
focus-follows-mouseenabled the focus will be on the desktop when I move cursor on it, which sometimes is annoying.Suggestion: with
focus-follows-mouseenabled, user need to make an explicit click to change focus on desktop when mouse hover on it.Update: auto focus on taskbar is also annoying.
The text was updated successfully, but these errors were encountered: