Replies: 1 comment
|
OK, I have a PR ready that I could submit. I used the name While I was at it, since I was touching all the relevant code anyway, I also added a global command However, as predicted (since the assumption that titlebars are horizontal and at the top was embedded in many places in the code), this would be a fairly large PR: Please advise as to how I should proceed and whether you would like me to submit this change as a PR. Thanks so much. |
Uh oh!
There was an error while loading. Please reload this page.
I am switching to Wayland from Xorg/Fluxbox, and a feature I miss is the ability to specify which side (top/bottom/left/right) of the border the tabs for each tabbing group are located. (For applications where I want to maximize usable height, I put the tabs on the left; for a tab group that I keep at the bottom of my screen I put the tabs at the bottom, to keep the important stuff more in the middle of the screen.)
I have the strong impression that due to its commitment to i3wm fidelity, such a feature would not be accepted in official sway itself. I was wondering if I do the work to generate a PR supporting title location specification, what its chances would be to be accepted into SwayFX? On the one hand, this feature is pretty much just an appearance change -- where are the titlebars located? -- but on the other hand, it might be a slightly more extensive code change than usual because the assumption that titlebars are horizontal and at the top of each container is baked into the code in a number of places, so the PR would touch a fairly large number of files.
To be slightly clearer on the proposal, just as each container can currently have a layout (tabbed/stacking/splith/splitv), this PR would also allow each container, including single-window-wrapping containers, to have a titleside (top/bottom/left/right). The titlebar, if displayed according to the current (unchanged) rules for that, would be on the side specified by the titleside, with text rotated to fit on left/right titlebars. These conventions have the slightly weird consequence that a tabbed container containing four windows which each used a different one of the four titlesides would end up surrounded by four full-length titlebars along each of the four sides of the border -- the titlebars would only split into tabs (or stack for stacking containers) when there is more than one child in that container with the same titleside. But presumably the most common sort of use of specifying the titleside would be, for example, to say that all browser windows would have titleside
left, and then presumably one is making a tabbed container of a bunch of browser windows, so you end up with one set of tabs along the left edge of that container.OK, so I would welcome any thoughts on whether a feature along these lines would stand a reasonable chance to be accepted into SwayFX, and if so, I would of course also welcome feedback on the specifics of the design of the feature, including the name of the property "titleside," which I actually don't love -- I just haven't come up with anything better.
[I had originally thought that only containers with children would have a titleside, but then I realized two things: (a) that policy would prevent one from putting the title of a single floating window on whatever side you wanted, so therefore every container should have a titleside, and (b) then one has to figure out what to do when the titleside of a container is
rightbut the titleside of (say) all of the children isbottom. And so then I realized that the tabs of a tabbed container really belong to the children, as shown by the fact that the container has its own additional titlebar/tab when it is one of multiple children in a higher-level container. So therefore, it seemed to make more sense to allow the titleside of a container to dictate its own titlebar location, even when it is in a container, leading to the proposal as outlined above. But I would be willing to be re-convinced that the titleside of a container should override the titlesides of its children, so that there could not be a tabbed container with tabs on more than one side, if the maintainers here thought that system would be better.]All reactions