zeroxoneafour / kwin-autotile

Autotile script for kwin
https://store.kde.org/p/2003956
MIT License
43 stars 1 forks source link

autotiling is not working across activites #19

Open arghyasinha opened 1 year ago

arghyasinha commented 1 year ago

Suppose I have opened a dolphin window (say) in workspace 1 of activity 1. It will tile perfectly. Suppose I switch to activity 2 and open a terminal window in workspace 2; it will not tile as expected. Instead, it cares about the dolphin window opened in Activity 1 in the same workspace and tiles on the right side of the screen, leaving a blank space on the left side. Similarly, if I switch to activity 1 again, the dolphin window will tile to the left side of the screen and leaves a blank space on the right side. The workaround to this is to work on different workspaces across activities. However, this is not very convenient. Is it possible to isolate the windows in the activities so that they do not leave blank spaces for other windows in other activities and tile them accordingly?

zeroxoneafour commented 1 year ago

The thing about activities vs virtual desktops is that activities are an array, as a window can belong to multiple activities, but cannot belong to multiple virtual desktops (unless it is in all virtual desktops). With the current setup of the app, you could not share windows between activities and have tiling work. This could be implemented but would require quite a bit of code restructuring (would have to change the liberally-used windowsOnDesktop() function).

I am thinking about restructuring the entirety of the selective tiling code that allows for virtual desktops, maybe by using a Map where the key is an object of String and Number for the activity and virtual desktop, with the value being a reference to the tile on that specific activity/virtual desktop.

Needless to say, this issue may not get resolved for a few weeks.

Sorry for the late response!

arghyasinha commented 1 year ago

Okay, as I understand, Kwin actually hides a window across multiple activities instead of isolating them in a single activity; yeah, that makes sense. As you pointed out, identifying a window with a key consisting of information about the corresponding activity and workspace should work if Kwin provides that information. Thanks for your response. You are doing an awesome job!!!

zeroxoneafour commented 1 year ago

So I took a look at my code and tried my hand at refactoring it, and I think the easiest way to solve this problem is a complete rewrite of the entire codebase. The code being built without support for a window being in multiple places has been severely limiting, and I need to restructure a lot of the back parts of the code to make up for it.

Right now, the order of execution is as follows -

  1. Detect input and trigger functions
  2. Move window into tile instantly
  3. Set keys and other hidden values

But I can see that with a window being in multiple places, this approach is fundamentally flawed. Moving a window into a tile upon receiving input will not work ex. if a desktop is changed. The window will not know to change positions. Therefore, the code will be restructured to execute as such -

  1. Detect input and trigger functions
  2. Set keys for where the window will be tiled
  3. Poll every desktop/activity/screen switch and if the window is visible, set its position to the key

This should work for the vast majority of use cases (one problem I see is that if a window is opened on an unfocused screen/activity it won't tile, but I can just add a poll listener there.) Tbh I did not expect that this would be the issue that would necessitate a full-scale rewrite.

zeroxoneafour commented 1 year ago

Try the latest build from the github and see if it changes anything about autotiling for activities for you