-
-
Notifications
You must be signed in to change notification settings - Fork 31
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
split ratio, split horizontal factor, split vert factor #44
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Unescaped
%
character (156) makesautotiling -h
crash. Please use%%
instead. - As well
-sw
as-sh
&-sr
are floats. Shouldn't they all have the1.0
default value?
After short testing: I don't think I would use any of the new arguments. But I may be wrong, of course. @Syphdias, what do you think?
Fixed the issues. This PR is mostly cosmetic, its kind of nice to have golden ration split rule. It can help reduce amount of window resizing, if user has some specific workflow needs (like me - I prefer slight bias toward top/bottom splits, and I prefer to have bigger 'Mater' window, thus I can have smaller child splits now). Also this kind of helps to get spiral layout. User does not have to use it if you like 'normal/unifom' splits. |
Funny, I already coded up the split ratio a few days ago in a very similar manner and already use it with The other two options are interesting. I don't think I would use them though. I would try to avoid running the resize in the default case though. The help text is not very clear to me, I had to look at the code to understand what is did. Suggestion for more readability. For me this makes more sense since you can see the ratio being built: -new_layout = "splitv" if con.rect.height > 1/splitratio*con.rect.width else "splith"
+new_layout = "splitv" if con.rect.width/con.rect.height < splitratio else "splith" |
After some further testing: I could use |
Small heads-up, no matter which PR will be merged first, it will result in a merge conflict. At least on the handler and the function definition. |
ok, all should be ok - I synced my fork and pushed Merge commit. |
Guys, I do hope you test all the stuff against i3, do you? I have no working i3 installation at the time. |
@JoseConseco The if e.change == "new" and con.percent: with if e.change in ["new", "move"] and con.percent: ? |
@nwg-piotr, did you try that without a limit? |
Moving windows with keyboard or i3-msg/swaymsg command behaves oddly one way or another w/ autotiling turned on. One needs to change focus first. Another way (at least working on sway) is Mod1 + mouse drag. Dunno how many users use the mouse, however. |
I can only speak for myself. Mouse dragging is quite new in i3 and I only use it sometimes, for example if I drag something into deeper structures. I still stand by my point that there should be no resizing if the option is not set (default 0.0 and check |
Default in this case is if e.change in ["new", "move"] and con.percent:
if con.parent.layout == "splitv": # top / bottom
if output_name in settings["autotiling-output-splitheights"] and \
settings["autotiling-output-splitheights"][output_name] != 1.0:
i3.command("resize set height {} ppt".format(
int(con.percent * settings["autotiling-output-splitheights"][output_name] * 100)))
else: # left / right
if output_name in settings["autotiling-output-splitwidths"] and \
settings["autotiling-output-splitwidths"][output_name] != 1.0:
i3.command("resize set width {} ppt".format(
int(con.percent * settings["autotiling-output-splitwidths"][output_name] * 100))) |
I'm new to i3 so I do not feel like I can say how things should work. Feel free to modify this in any way u want. |
Yes.
We are having an open discussion. Anybody who has an opinion, can voice it. Some things we agree on, some things we disagree on. It's part of the process and hopefully the result is a better tool for all. |
To make things even harder, the repo owner does not use i3 at all. 😜 Since I moved to hybrid AMD graphics, X11 detects my outputs on the random basis, and usually I need to restart i3 3 or more times before it starts working properly. Autotiling is just a small gear in the nwg-shell project, and I wish I had someone to keep a careful watch on it. For the project purposes I use the nwg-autotiling, script, as an entry point of nwg-shell-config. It's aimed exclusively at sway, and drops most of startup arguments (uses a common json config file), but shares the code base with autotiling. To sum all the above up: we need discussion and a lot of testing. |
Can autotile create container only after new Window is created? |
The fact that the new split is always set when you focus to a container, breaks a couple of things. Moving a container becomes a bit odd, swiching to tabbed/stacked is not possible because it will not switch the right container (for [A [B [C]]] we want the BC-Container to be switch to stacking, but instead we switch the C-Container. The limit option somewhat mitigates that.
I cannot be a bool though, because no new layout is also valid. [A [B C D]] should sill be possible. There can be more than two containers in another container. I would really like it, if there was a way to do it. I don't know if it is possible though. I fear i3 only knows of the new window after it is already there and you would need to go to the previously focused window, set a layout, and move the new window to it. |
Will you finish the PR though? |
Guys, I'm not going to insist on merging or further work on this PR, at least until we have an agreement. Probably I'll add |
The change is - |
Also clauses in order not to |
Ok, I pushed the ignore resize if == 1, and added move event. Any thoughts about remaking autotile - to only do the split after the new window is added?
|
Do you have any example code to look at? |
I wrote a prototype. https://github.com/Syphdias/autotiling/blob/experimental-switching/autotiling/main.py It does not support any arguments yet. |
Did any of you get a chance to try it out? You need to provide the |
Nope, sorry. I'm low on time. I figured I will move to https://github.com/hyprwm/Hyprland since it already has all the features I want (dynamic binary tree partitioning, tabs, good mouse support - for swapping resizing windows, nicer ui, easier to use etc). |
Sorry, I'm working on two different things at he same time. Will take a look ASAP. |
IMO the feature looks good. I don't have time at the moment to test to much extent, however @nwg-piotr you said you had implemented a similar feature before? If it worked then, it's probably good here as well. |
I use exactly this solution in nwg-autotiling, but I was afraid that merging it here could raise one more shitstorming, as this script is quite widely used. One day I'll buy a 6-pack and make a decision. ;) |
Hahah that sounds good :) |
split ratio - for example 2 => window has to be 2x wider than normal, before left right split is done.
split widht - 0.8 => reduce size of new window 20% when left/right split
split height - similar to above for top/bottom splits