Animations 2: Electric Boogaloo

Well, this was a disaster. To the people who saw my last devlog, i said that i was going to try to fix a problem that i encountered by using resizing and movement animations simultaneously.
I spent an egregious amount of time researching how i could force smithay to render the window stretched in such a way that it would cancel out any size errors, but it turns out that the method i used just… did nothing? i dont really know what happened, but i made a quick and dirty fix for now by making the movement animation wait a couple of animation ticks before starting, and it has worked decently so far.

I think i’ll get to work on the privileged section’s movement and swaps and whatnot now.

Below is an example where you can see that the edge isn’t freaking out like before anymore:

Animations!!

I’ve been at work to make animations, and it turned out decently. The only real problem i have with the current implementation is that when a window is subject to both a resize animation and a move animation, the far edge of the window in relation to the one that’s moving will bleed into the next cell a bit, so i need to fix that.

Other than that, it’s smooth sailing; now i only need to fix that last problem and probably refactor the animation code because it’s a complete mess.

Here’s a video of the animations working:

Bugs, bugs everywhere.

I was planning on just abstracting away some parts of functions in other functions for this devlog, so that i could complete the window expansion and movement logic. Since i had spent barely half an hour doing that i thought this devlog would have been too short, so, i also decided to start making movement and resizing animations; but little did i know that i was, all of me, deceived.

As i was thinking at yesterday’s code, i found some inconsistencies in my logic, i ended up also fixing a bunch of bugs that completely escaped me while writing the code, and i ended up needing to fix those…

First

The first bug i found regarded the movement and expansion of windows: what should a window do if in the way it wants to move there are two windows, the first that can move out of the way and the other can’t? Up until now, the window that had to move (or expand) would not have performed the action because of the 2nd window, but the first one would have moved regardless. I fixed it so that if any of the obstructing windows cannot move, none will.

Second

While fixing the first bug, i stumbled upon a second one; in my tiredness from late-night coding, i had somehow managed to forget to update the available cells when a window expands… Yeah that was dumb TuT.

Third

Now again, while fixing the second bug, i found a third! This one was perhaps even dumber, because i had forgotten to update the cells a new window occupies when it expands. Again, quite dumb, but now it works at least…

I managed to add a few things, going insane in the meanwhile.

First of all, i reorganized the files of the project in some folders, because more folders are (almost) always good.

Second, i discovered that a decent algorithm i had made to find which window was under the pointer, which first checked the section (top or bottom), then row and column (which would make a small amount of checks), can’t work while i don’t lock in my layout! this is because i can’t get a certain window geometry unless i do a linear search over every window, which is a complete waste of time, because at that point, it’s faster to just make a linear search over all windows and check if each is under the pointer. So, until i figure out the spacing and in general the fancy stuff in the layout, i won’t be able to use my algorithm.

Third, i went absolutely insane trying to implement multi-cell windows on the map. like. i think i remade the algorithm close to 10 times before landing on something i like. in the meanwhile, i also added moving windows, simply because if you try to extend a window into already occupied cells, the layout manager will try to move all windows in the row(s) or column(s) out of the way to make space for the expanded window. I am quite happy with it now, even if it can only be expanded to the right for now because i want to split up some huge functions into smaller functions.

Anyways, here’s a demo; it spawn three terminals, moves the third one under the first one, extends the one that just moved once to the right, and then moves the first and second window downwards and back, moving the extended window in the meantime.

Note: for some reason, the terminal that gets extended doesn’t realize it was extended until i type something, hence it looks like a very very very bad cut. I swear it isn’t, you can look at the code if you don’t believe me TuT

I managed to do a bunch of stuff, in no particular order:

• dealt with window decorations (and, i’m going to go on a quick rant here, i’ve lost my mind trying to understand weston-terminal wouldn’t lose its window decorations even if it seemed like i was doing everything right for a good 45 minutes. Only after that amount of time, i decided that it would have been wise to try another terminal, and would you believe it! alacritty removed its decorations flawlessly! turns out that weston-terminal just… doesn’t respect the decoration config??? anyways, i’m now using alacritty and kitty because they respect the decoration config and have slightly different colors by default.)
• fixed the privileged space’s (the strip above) tiling
• added input!
• oh and changed the background color to a nice mauve i guess

Anyways, have a demo video; you can see alacritty and kitty being alternated because the former has a grey-ish background, and the latter has a black background:

I got winit to work, and it was surprisingly easier than i thought it would be. Also, i fixed a bug where columns and rows were swapped in the bottom grid, oops.
Anyways, it works! and my layout manager does too! Well, at least partially, because the top strip isn’t resizing the windows like i want it to, but that’s something i’ll work on in the future.

Well, this is a huge project. For now, i’ve worked actually learning how a compositor is made, and how to do tiling. I should have the bases for a layout manager and an app state manager, but, knowing how these things go, they’re likely both broken in some way.

For now, the tiling is split in two sections: the top one, is privileged and cannot be attacked, meanwhile the bottom section is a grid where the windows will be hittable boats by opponents

Anyways, i’ll try to make the backend trait and to implement the winit backend to get a display out.