You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is mentioned in the README's Known Problems section.
To Reproduce
The problem is that the focus returns to the previous window after PowerLauncher closes, before spawning the new window.
PowerLauncher opens
You tell it to launch notepad for example
PowerLauncher closes -> focus returns to previous application
notepad launches
If the previous application mentioned in step 3 is managed by nog, the workspace will change to its grid. The only way to fix this (at least that I know of) is if we implement our own application launcher that is connected with nog.
Proposed Solution
What if we added a sort of "soft-monitor-lock" within nog.. like maybe a keybinding that you activate that then ignores focus events on other monitors from a focused-workspace perspective and then unlocks either by manually unlocking or by manually navigating to another workspace.
This would be like.. if you needed to open/close a single program multiple times on a monitor and don't want to keep jumping focus to another monitor when nothing is on your primary monitor. You could just "lock" the monitor so nog retains focus on the workspace on that monitor until you unlock it.
It's a little hacky but idk, maybe it could spark some ideas. Plus this issue could just be used to track this anyway.
The text was updated successfully, but these errors were encountered:
Another hacky approach could be to simply keep track of the monitor that is currently focused and unless there is a rule in the config file saying otherwise to automatically move the window to the last active monitor.
I feel like if a user has Nog in work mode they would expect it to have control over all the windows and where they spawn by default, and feel like adding additional keybindings might just make it more complicated and difficult to use then expected.
Just my opinion I don't mind either approach, but it would be nice to finally have this bug fixed as it does get annoying after a while 😄 .
I worked on a custom menu that has deep nog integration (Making it possible to easily run lua code) using iced.
It is almost done, the only thing missing are two ui/ux things that have to be fixed on the iced side (initial window position and resizing the application at runtime). This also showed that we could refactor our appbar to use iced instead making it cross platform per default and makes it possible to more easily customize the bar with more advanced features.
Version (which release did you use?)
master
Describe the bug
This is mentioned in the README's Known Problems section.
To Reproduce
The problem is that the focus returns to the previous window after PowerLauncher closes, before spawning the new window.
If the previous application mentioned in step 3 is managed by nog, the workspace will change to its grid. The only way to fix this (at least that I know of) is if we implement our own application launcher that is connected with nog.
Proposed Solution
What if we added a sort of "soft-monitor-lock" within nog.. like maybe a keybinding that you activate that then ignores focus events on other monitors from a focused-workspace perspective and then unlocks either by manually unlocking or by manually navigating to another workspace.
This would be like.. if you needed to open/close a single program multiple times on a monitor and don't want to keep jumping focus to another monitor when nothing is on your primary monitor. You could just "lock" the monitor so nog retains focus on the workspace on that monitor until you unlock it.
It's a little hacky but idk, maybe it could spark some ideas. Plus this issue could just be used to track this anyway.
The text was updated successfully, but these errors were encountered: