Fix special workspaces

[rehanzo]

Fixes #18 , and fixes up operation of special workspaces in general. It now operates exactly how it does for any of the non-plugin layouts now.

I added the special_scale_factor config option, which is also present in the other non-plugin layouts, so the scaling factor for special workspaces can be modified.

Have a look over, and hopefully its good to go!

[rehanzo]

Just realized autotiling doesn't seem to work consistently with the special workspaces. It should be a simple fix I'll get to soon, so maybe hold off merging until then.

[rehanzo]

Ok nevermind I've fixed that up lol, good to look over now.

[DiXN]

The tab bar does not scale with special_scale_factor.

[rehanzo]

The tab bar does not scale with special_scale_factor.

Thanks for bringing that up, didn't test with tabs. I know it seems a bit weird, but I'd say it makes sense. The tab bar rests at the top of the "splittable space", for lack of a better term. The alternative would be to rest it at the top of the highest window within the specific tab, but that would mean it would move up and down depending on what windows you opened, so I think the way it is right now makes the most sense.

May sound confusing, so I'll demonstrate with an example. Suppose you have two different tabs in a group within a special workspace, laid out as such:
Tab 1:

Tab 2:

In this scenario, if we had the tab bar sitting at the top of the highest window, the bar would jump up and down if you flipped back and forth between tabs. This can also apply to the width, where it would get wider and shorter depending on how wide it is from the leftmost border edge of the leftmost window to the rightmost border edge of the rightmost window. Even if we wanted it to act this way, pretty sure that would require work in terms of how the tabs/groups themselves work, not special workspaces.

Now it would either be this, or instead of scaling the windows, we would scale the actual groups themselves which might also include the tab bar itself. In this scenario though, I think having groups scaled would look really odd, and not really what would be expected. Splits inside groups would have normal sizing relative to the scale of the group, which would just make the behaviour very confusing.

Let me know if any of that didn't make sense, or if you disagree with anything :)

[outfoxxed]

In this scenario, if we had the tab bar sitting at the top of the highest window, the bar would jump up and down if you flipped back and forth between tabs

This should not happen, because a group node should always have a fixed size in hy3. Child nodes may only exist inside the constraints of the parent node.

Now it would either be this, or instead of scaling the windows, we would scale the actual groups themselves which might also include the tab bar itself.

The node as a whole should be scaled. do this by scaling the root node and allowing node scale to propagate via recalcSizePosRecursive.

Unless I misunderstand something about the special workspace, it is an optionally smaller/scaled workspace layered over the main one. Correct me if I misunderstand that, because I personally don't use the special workspace.

[rehanzo]

Unless I misunderstand something about the special workspace, it is an optionally smaller/scaled workspace layered over the main one. Correct me if I misunderstand that, because I personally don't use the special workspace.

With special workspaces, its the windows that are scaled down, not the workspace. The workspace should be the same size, but the windows themselves are scaled down by the factor. So its almost like the windows are taking up the same space without scaling, but they are shrunken down within that allocated space. I'm still new to the codebase so correct me if I'm wrong, but with this scenario the nodes shouldn't be scaled down, because that would shrink down the workspace and the usable space, which is not really expected behaviour.

Here's an example, with a layout in a normal workspace, and the same layout in a special workspace overtop:

The workspace is the same size, but the windows are scaled down. Since the allocated space is the same, I believe it makes sense that the tab bar stays in the same space, with the windows simply being shrunken.

[outfoxxed]

Yeah I'm not really sure what to do with that. if the tab bar is over a single node it can scale with it, but that won't work for multiple nodes. Maybe placing it somewhere like 50% through the top padding and 50% into the side padding would be good.

Maybe add a mode to scale the entire workspace instead of individual windows?

[rehanzo]

Yeah I'm not really sure what to do with that. if the tab bar is over a single node it can scale with it, but that won't work for multiple nodes.

Yea exactly, with one it wouldn't be an issue, but multiple would have unexpected behaviour.

Maybe placing it somewhere like 50% through the top padding and 50% into the side padding would be good.

Not entirely sure what you mean by this. By padding, do you mean the space that is created from the shrunken windows? If so, I'm not so sure that would work too well. Depending on your layout, you can have it so that the windows fill up that area. That's why I personally think since its still usable space that windows can split into, the current implementation is the best.

Maybe add a mode to scale the entire workspace instead of individual windows?

I could, but I personally wouldn't care for it. I like the look that the scaled down windows gives when using the special workspace like a parking space for certain windows, but wouldn't necessarily want a shrunken workspace overall. If that's something others wanted though, I'd be down to do it.

[outfoxxed]

Mmm yeah. I've got one more somewhat more complicated option. What if we categorized windows in a tab group and windows outside of a tab group differently, and scaled an entire group as a single window if it uses a tab. It seems somewhat inconsistent but I really dislike the disconnected tab bar.

[rehanzo]

Ah that may work. Scaling the entire group down, and then not applying the scaling to the windows inside the group could very well be the way to go. I'll take a shot at that soon.

[DiXN]

Found another issue with toggling special workspaces on fullscreen windows. After hiding the special workspace again, the fullscreen window behind it will be tiled. Ideally, it should remain fullscreen. I am not sure if this PR is still the right place to report this issue, otherwise I'll open a new issue.

[outfoxxed]

@DiXN

Found another issue with toggling special workspaces on fullscreen windows. After hiding the special workspace again, the fullscreen window behind it will be tiled. Ideally, it should remain fullscreen. I am not sure if this PR is still the right place to report this issue, otherwise I'll open a new issue.

this is an unrelated known issue, but thanks for reporting it

[outfoxxed]

@rehanzo are you still working on this?

[rehanzo]

My bad, I completely forgot about this. Unfortunately, I don't use the plugin anymore since the hyprland dwindle window movement changes. Hopefully someone can pickup where I left off!