-
-
Notifications
You must be signed in to change notification settings - Fork 842
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
Dispatcher movewindoworgroup
to move into/out-of an unlocked group
#2851
Comments
movesinglewindow
to move into/out-of an unlocked group with a bindm
movesinglewindow
to move into/out-of an unlocked group with a bindm
movesinglewindow
to move into/out-of an unlocked group
movesinglewindow
to move into/out-of an unlocked groupmovewindoworgroup
to move into/out-of an unlocked group
This does not work because all dispatchers are triggered, and they conflict.
Is there some magical order in which these work? |
I just realized that when using |
Doesn't Hyprland/src/managers/KeybindManager.cpp Line 1952 in 7e8a212
Hyprland/src/managers/KeybindManager.cpp Line 1969 in 7e8a212
|
Does this mean moving the container like what If the default behaviour of dispatchers ignoring
|
It's been a while so I'm not sure how clearly I remember, but I'm quite sure having those three dispatchers made it behave really weirdly. Like it would pick up the window and put it back, for an example of the behavior of one particular order. I'm trying to remember if that was my testing with the keyboard but I don't think so, because I remember walking away and forgetting about it, then coming back and thinking "what the heck is happening to my mouse 5". So I'm not sure what that means, but regardless of how the code is written, I'm almost positive those three lines caused funky things. |
≥ Does this mean moving the container like what swapActive or moveActiveTo does? Yes for the former, but what is
That sounds exactly like the behavior I'm after.
Row number 4: active is window, direction is window --do nothing. I don't think that's what I want, that should behave as
I assume you're talking about a new one, |
Yes, by the dispatcher I mean the hypothetical new dispatcher who will move the window or group.
Having the new dispatcher swap window position movewindow or swapactive would be inconsistent with how the dispatcher it is supposed to combine works. The existing dispatchers, namely This inconsistent behaviour could confuse users who are familiar with the current functionality and defaults. Therefore, in my opinion, the new dispatcher should not swap container positions by default when both the active and target containers are windows. Instead, it would be better to provide an option to enable container swapping via a configuration flag, for those who want that behavior. Hyprland/src/managers/KeybindManager.cpp Lines 2053 to 2054 in 7e8a212
Hyprland/src/managers/KeybindManager.cpp Lines 2074 to 2075 in 7e8a212
|
Please note that this hypothetical behaviour ignores |
The current |
My idea for the
Two thoughts on this. This is inherently rather complicated, and therefore just calling the functions of other dispatchers or combining them would not be appropriate. For brevity, I use terms like
Because you wish to remain "consistent" with how these work (and this consistency does not adhere to my ideal functionality) I have introduced two behavioral "modes", A and B. Behavior A is essentially "this dispatcher is generic and dispatches other behaviors, and Behavior B is "move the window if it is possible". Maybe instead of two behaviors (
Now, I would like to see something very similar to work with |
For another new dispatcher to work with
|
No, |
I'm annoyed, because you didn't read the preface.
|
I am truly sorry for the frustration or offence, but this is to clear up any confusion about what the dispatcher actually does, so we can collaborate more effectively. If you prefer, we can stop this conversation. Hyprland/src/managers/KeybindManager.cpp Lines 2036 to 2069 in 7155b4c
NOTE: if (!PWINDOW->m_sGroupData.pNextWindow)
PWINDOW->m_dWindowDecorations.emplace_back(std::make_unique<CHyprGroupBarDecoration>(PWINDOW));
|
@spikespaz Hi, sorry for the intrusion, would you like to test this PR? #3006 |
The new dispatcher is currently named The dispatcher accepts any args that moveintogroup accepts. For example, you can test it like this
|
Other changes to the behaviour of existing dispersers are
Thank you very much for your time and feedback. |
Hi, I have no way to meaningfully make this enhancement any better, but I'd like to enter the discussion by pointing out that I've found this Issue thread when trying to implement a dispatcher of the name "movewindoworgroup" described in Hyprland Wiki If this is not an implemented feature or a feature in testing only, why have it be described as available to use inside of the Wiki? |
Already implemented and merged: #3006 (with the exception of the mouse bindings), released in v0.30 and the wiki, to my knowledge, always documents the last git main branch. @vaxerski Should this be closed? |
Is it implemented as of version 0.29.1-1? |
I ask because in said version, hyprland told me no such dispatcher existed |
released in v0.30 |
Ah thank you, I hadn't read that, very sorry for the inconvenience. |
I apologize for this interaction. |
Wasn't this implemented already, btw? I mean, there's a dispatcher, but the issue is still open. |
Description
I would like a dispatcher to move windows into/out-of groups when the window is not in a locked group.
This effectively combines
moveintogroup
andmoveoutofgroup
, but allows using the same bind for both dispatchers. This would work because groups can be locked, in which case this dispatcher would move the group rather than a window.Maybe name it one of these:
movewindowmaybegroup
moveunlockedwindow
(Makes less sense when a window outside of a group)movewindoworgroup
(I like this one best)The text was updated successfully, but these errors were encountered: