-
-
Notifications
You must be signed in to change notification settings - Fork 895
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
Streamline dwindle groups #593
Conversation
Stick with the original idea of groups being non-terminal nodes that expose windows of child nodes. Keep the binary tree intact all the time.
After some testing - this PR introduces a lot of issues the new rewrite was supposed to get rid of
Is all of this really worth it just to enable "remembering the layout"? I think we're missing the point of what most people want when they see groups. They want a group, not a façade. That was my original thought regarding my group rewrite (c319a2a) Feel free to prove me wrong, but I feel this is an overkill, and will lead to more issues than it solves. The only requests I've heard from people is #598, being groups of single windows. Never anything else. Of course this PR also introduces some temporary issues, like the code styling not following the Hyprland code styling, but again, that's just a temporary easy-to-fix thing. Feel free to elaborate on this PR. |
Worth? IDK. It is a wishlist item though. |
Ok, thank's again for looking into this and your honest feedback. My reply gonna be a rather longish read (again) and I will discuss things on a more general level. Sorry for it; We also use a different place for further discussions, since this not focused on the initial PR any more: Let me first explain an example situation, in which I would like to use some kind of grouping feature: I am scientist and when doing analysis a typical workspace looks like this:
In such a context I would like to group windows mostly for two reasons:
So, yes, I would say "remembering the layout" is important here. In particular a dynamic tiling algorithm should honor the (limited) adjustments that have been made by the user and try to preserve them. For the reset, it should deliver predictable results that follow a logic to which the user can adapt to -- and in my particular use case this is where the current implementation fails (cf the videos): I made to videos, in which I compare the behavior of the main branch (1st clip) with this branch (2nd clip): main-220831-1312-03.mp4branch-screencast-220831-1311-07.mp4In case of this branch (not possible in the main branch atm) I also regroup a node being already a group. The group eating aspect (as you called it) can become quite handy to enlarge an already existent group. The fact that groups can be nested is not important and could be abandoned. With the decorations being fixed its also clear on which node the With this in mind I tried to see how far I could get with the facade implementation. It was mostly a poc and atm I do not expect from it to deliver perfect results. But from my point of view this implementation looks cleaner (less However, I do admit that we are not there yet and I cannot guarantee that I can resolve all the issues in the near future (probably not, due to time constraints). I could still try to keep slowly/gradually working on this (so exactly the opposite to the current hyprland dev spirit) but only if has the realistic possibility of being finally merged in. So, before discussing the details we should reach conclusion on:
Btw, do WM like bspwm or awesome offer a grouping feature for their dwindle layout. How do they handle them? I would lean toward the facade, but this is the implementation perspective. From the user perspective, I want to have groups that do not deteriorate a window arrangement once they get dissolved again. How this is done behind the scenes is merely an academic discussion, that I have to admit. |
This is how Hyprland should have been designed in the first place. The current implementation displays an abhorable lack of forethought; when writing software it is best to work around the premise of a prototype. You build something twice, expecting to throw it away the first time. This pull request is fundamentally correct in the principle it regards--it deserves attention. |
Believe me, I am still bothered by this almost every day...
Key aspect of this PR was to promote the facade aspect and to demonstrate that you can reach a concise design that delivers all the functionality that we expect + even more. Also, none of the issues brought up by @vaxerski seem to fundamentally contradict with my approach, though it still needs some development work. Once it is is finished, I beg to differ here:
I am quite busy at the moment, but I have not forgotten about this PR and whenever I find the time, I would like to work on it/ bring it forward again |
I think this is quite debatable!
It's a luxury be allowed to rewrite and change stuff on the way, when you discover how things actually should work. |
And Hyprland is written by someone for fun so iterative improvement ought not to be an issue. |
@spikespaz : Your right!
at a point where you have already gained information by trying things. |
@Dickby Apologies. Perhaps this was a bit harsh. I say this because I made my own prototype in OpenGL and came up with the exact solution provided by this PR. |
e309ecf
to
5eb98c0
Compare
Definition
I had a look into the implementation of dwindle groups. For a clean design and rigorous implementation, I would propose the following definition:
Implementation guidelines
Implementation wise this can be achieved when sticking to the following principles:
Development state
In this PR, I implemented the outlined behavior to provide a proof of concept. It was easiest to discard the most recent changes w.r.t groups in the main branch (in particular c319a2a) and give it a fresh start.
Apart from a cleaner implementation, we gain the following:
Demo:
The following video:
hyprland.mp4
demonstrates the new features. It is driven by the playbook below:
Unresolved issues:
Atm, a few things still need to be done:
I submit this PR to trigger a discussion and get some feedback although the implementation is not finished and thoroughly tested.
I also do not now how much time I can invest into this within the next week, so help with the remaining issues would be appreciated. But imho, it would be worth it!