search

TimUntersberger / nog

A tiling window manager for Windows
MIT License
697 stars 20 forks source link

Window gets managed on wrong monitor #269

Open ramirezmike opened 3 years ago

ramirezmike commented 3 years ago

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.

  1. PowerLauncher opens
  2. You tell it to launch notepad for example
  3. PowerLauncher closes -> focus returns to previous application
  4. 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.

keepitsane commented 3 years ago

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 😄 .

TimUntersberger commented 3 years ago

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.