-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Issues with programs that spawn child windows #44
Comments
Should I understand that the first window is managed as expected, but the popups it triggers aren't ? In theory one could just add support for multiple client windows but:
I don't see how that could work, if you know please enlight me :) Regardless, I think I see your use case and use a very similar one for some VPN app. Edit: and have a nice day ;) |
I just released a new version : 1.8.0 I believe a special workspace can do the job, if you need to quickly move windows between the special workspace and the normal active one, in two directions, have a look at https://github.com/hyprland-community/pyprland/wiki/toggle_special (same as I recommended before, but now it has its own plugin and has been renamed for clarity). Closing the issue since I don't think scratchpads is meant to cover those use cases. If you have a proposition or a clear feature request feel free to re-open or create a new issue. |
It also causes other issues, for example:
But even when I got to my special workspace and I moved it to my normal workspace next time pyprland toggles slack it moves both windows to scratch:slack and I'm back at step 1. I think matching windows would need to be matched by any attribute, similar to hyprland rules (in this case I could use Example hyprctl output:
|
So to be sure, in your scenario, you want the original window to be the scratchpad but sub-windows to not have a special threatment ? You would provide |
Hi, thank you for a quick response! |
If I push some experimental version later, are you able to test it without having a proper release (use the latest git version)? |
Yes I should be able to to test it tomorrow. Thank you! |
Not sure what update did it (might by hyprland) but the behaviour changed for the better. Now |
In theory only one is added... so it must be a rule in your hyprland.conf ? Actually you made me think about implementing some kind of group of windows and matching multiple clients, but today it's not possible so I'm surprised this is happening for you. |
The new window has the same PID as the original one (in slack - see below). I don't have any window rules for slack, it must by from
In the above: main slack window (564ba17da140) is started by This window is hard to access to me because `pyprland' only toggles the main window. I managed to move that window to regular workspace with some script and now it works as expected |
In theory only the first created one will be the scratchpad... it should be visible in pyprland's log file... (passed via |
sorry just edited above with some extra info |
Note that now you can match by initialTitle if you like... |
didn't expect this to be relevant to others 😄 maybe a wiki entry or a guide on this matter would be helpful for future references. i'll try to add if i find the time! |
There is a chance Hyprland assigns the child window to the special workspace... |
Hi! I've stumbled across this issue while using KeePassXC, specifically when clicking on buttons that spawn child windows, such as the password generator.
With
hyprctl clients
:This is the main window, which is obviously locked when a modal window is on:
This is the child (modal) window created:
Since both windows share the same class but not the same window address, they can be shown at the same time by pypr?
Anyways, have a nice day/night :)
The text was updated successfully, but these errors were encountered: