From 12b8f0e762ae62d9797f0a7100c52c1fae33fc97 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?VESSE=20L=C3=A9o?= Date: Tue, 16 Jul 2024 21:55:11 +0200 Subject: [PATCH 1/3] rfc: 1-animation-slide-side --- rfcs/0001-animation-slide-side.md | 68 +++++++++++++++++++++++++++++++ 1 file changed, 68 insertions(+) create mode 100644 rfcs/0001-animation-slide-side.md diff --git a/rfcs/0001-animation-slide-side.md b/rfcs/0001-animation-slide-side.md new file mode 100644 index 0000000..af53e36 --- /dev/null +++ b/rfcs/0001-animation-slide-side.md @@ -0,0 +1,68 @@ +--- +feature: changing slide side animation +start-date: 2024-06-16 +author: Ciflire +--- + +# Summary + +Trying to normalize the side parameter given to animation + +# Motivation + +I felt like the animation side is not consistent. To give an example I will be +using my configuration file: + +``` +animation=windowsIn, 1,2,windowIn, slide bottom +animation=windowsOut,1,2,windowOut, slide bottom +``` + +These two animation have the same side given, but one gives an animation that +slides **from** bottom **to** the center and the other gives an animation that +slides **from** center **to** bottom + +This bothered me, so I decided i would make an RFC to get feedback on that, to +know if I am the only thinking that or not as I could get no feedback in the +discord. + +# Detailed design + +The other conception of it would be to think of a vector which to me feels more +intuitive when thinking of animation, and movement. Instead of thinking of a +fixed size. + +# Examples and Interactions + +The previous configuration would be rewritten into + +``` +animation=windowsIn, 1,2,windowIn, slide top +animation=windowsOut,1,2,windowOut, slide bottom +``` + +Where `top` and `bottom` give the direction of the window when going in or out. + +# Drawbacks + +People would have to change this in their entire config, could also be +counterintuitive to other people just as the way it is designed today is +counterintuitive to me +Having to change the actual implementation + +# Alternatives + +Keeping the way it is + +# Prior art + +This is already impleted + +# Unresolved questions + +Still no community feedback so I use this dedicated space to have some + +# Future work + +Feel free to criticize it, sorry for my English as well i'm not native, also +first time doing an RFC From fef54a7592afdfc55adc633e8357167032c2238a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?VESSE=20L=C3=A9o?= Date: Wed, 17 Jul 2024 00:04:57 +0200 Subject: [PATCH 2/3] rfc: detailed motivation beside the motivation the rest wasn't modified yet but will be --- rfcs/0001-animation-slide-side.md | 28 +++++++--------------------- 1 file changed, 7 insertions(+), 21 deletions(-) diff --git a/rfcs/0001-animation-slide-side.md b/rfcs/0001-animation-slide-side.md index af53e36..a5945cc 100644 --- a/rfcs/0001-animation-slide-side.md +++ b/rfcs/0001-animation-slide-side.md @@ -6,31 +6,18 @@ author: Ciflire # Summary -Trying to normalize the side parameter given to animation +This RFC aims to agree on a rule for forced side option of the slide animation style # Motivation -I felt like the animation side is not consistent. To give an example I will be -using my configuration file: - -``` -animation=windowsIn, 1,2,windowIn, slide bottom -animation=windowsOut,1,2,windowOut, slide bottom -``` - -These two animation have the same side given, but one gives an animation that -slides **from** bottom **to** the center and the other gives an animation that -slides **from** center **to** bottom - -This bothered me, so I decided i would make an RFC to get feedback on that, to -know if I am the only thinking that or not as I could get no feedback in the -discord. +The way the animation `slide` is used feels inconsistent in two ways at the moment i'm writing this: +- First, it describes a side that can be the side by which the animation starts as well as its end. For example the keyword `bottom` used for animation `windowsIn` will move the window **from** the bottom to the desired position and for the animation `windowsOut` the window will be slided to the bottom of the screen +- Secondly, following that logic, the keyword `bottom` would be used to make the window pop from the bottom and close sliding to the bottom. The same keyword is then used for two different visual results. +This RFC will allow to write the documentation as clear as possible without having to detail each case, or by try and fail by the user # Detailed design -The other conception of it would be to think of a vector which to me feels more -intuitive when thinking of animation, and movement. Instead of thinking of a -fixed size. +The new design for the forced side # Examples and Interactions @@ -47,8 +34,7 @@ Where `top` and `bottom` give the direction of the window when going in or out. People would have to change this in their entire config, could also be counterintuitive to other people just as the way it is designed today is -counterintuitive to me -Having to change the actual implementation +counterintuitive to me Having to change the actual implementation # Alternatives From 2edcca677b74fd27fef6d44a0487b0b459996c92 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?VESSE=20L=C3=A9o?= Date: Wed, 17 Jul 2024 20:58:27 +0200 Subject: [PATCH 3/3] rfc: added refs, rewrote it Some sections are still empty, i don't know what to put it there by reading the template. But I will fill these up if remarks/questions are asked. --- rfcs/0001-animation-slide-side.md | 150 +++++++++++++++++++++++++----- 1 file changed, 125 insertions(+), 25 deletions(-) diff --git a/rfcs/0001-animation-slide-side.md b/rfcs/0001-animation-slide-side.md index a5945cc..c7f0e89 100644 --- a/rfcs/0001-animation-slide-side.md +++ b/rfcs/0001-animation-slide-side.md @@ -6,49 +6,149 @@ author: Ciflire # Summary -This RFC aims to agree on a rule for forced side option of the slide animation style +This RFC aims to agree on a rule for forced side option of the slide animation +style # Motivation -The way the animation `slide` is used feels inconsistent in two ways at the moment i'm writing this: -- First, it describes a side that can be the side by which the animation starts as well as its end. For example the keyword `bottom` used for animation `windowsIn` will move the window **from** the bottom to the desired position and for the animation `windowsOut` the window will be slided to the bottom of the screen -- Secondly, following that logic, the keyword `bottom` would be used to make the window pop from the bottom and close sliding to the bottom. The same keyword is then used for two different visual results. -This RFC will allow to write the documentation as clear as possible without having to detail each case, or by try and fail by the user +The way the animation `slide` is used feels inconsistent in two ways at the +moment i'm writing this: + +- First, it describes a side that can be the side by which the animation starts + as well as its end. For example the keyword `bottom` used for animation + `windowsIn` will move the window **from** the bottom to the desired position + and for the animation `windowsOut` the window will be slided to the bottom of + the screen +- Secondly, following that logic, the keyword `bottom` would be used to make the + window pop from the bottom and close sliding to the bottom. The same keyword + is then used for two different visual results. +- The use of the term "slide" makes the user consider the movement and not the + side This RFC will allow to write the documentation as clear as possible + without having to detail each case, or by try and fail by the user # Detailed design -The new design for the forced side +The design at the moment is that the orientation of the animation depends on +wether the window is closed or not. + +```cpp +// src/managers/AnimationManager.cpp +void CAnimationManager::animationSlide(PHLWINDOW pWindow, std::string force, bool close) { + pWindow->m_vRealSize.warp(false); // size we preserve in slide + + const auto GOALPOS = pWindow->m_vRealPosition.goal(); + const auto GOALSIZE = pWindow->m_vRealSize.goal(); + + const auto PMONITOR = g_pCompositor->getMonitorFromID(pWindow->m_iMonitorID); + + if (!PMONITOR) + return; // unsafe state most likely + + Vector2D posOffset; + + if (force != "") { + if (force == "bottom") + posOffset = Vector2D(GOALPOS.x, PMONITOR->vecPosition.y + PMONITOR->vecSize.y); + else if (force == "left") + posOffset = GOALPOS - Vector2D(GOALSIZE.x, 0.0); + else if (force == "right") + posOffset = GOALPOS + Vector2D(GOALSIZE.x, 0.0); + else + posOffset = Vector2D(GOALPOS.x, PMONITOR->vecPosition.y - GOALSIZE.y); + + if (!close) + pWindow->m_vRealPosition.setValue(posOffset); + else + pWindow->m_vRealPosition = posOffset; + + return; + } + + const auto MIDPOINT = GOALPOS + GOALSIZE / 2.f; + + // check sides it touches + const bool DISPLAYLEFT = STICKS(pWindow->m_vPosition.x, PMONITOR->vecPosition.x + PMONITOR->vecReservedTopLeft.x); + const bool DISPLAYRIGHT = STICKS(pWindow->m_vPosition.x + pWindow->m_vSize.x, PMONITOR->vecPosition.x + PMONITOR->vecSize.x - PMONITOR->vecReservedBottomRight.x); + const bool DISPLAYTOP = STICKS(pWindow->m_vPosition.y, PMONITOR->vecPosition.y + PMONITOR->vecReservedTopLeft.y); + const bool DISPLAYBOTTOM = STICKS(pWindow->m_vPosition.y + pWindow->m_vSize.y, PMONITOR->vecPosition.y + PMONITOR->vecSize.y - PMONITOR->vecReservedBottomRight.y); + + if (DISPLAYBOTTOM && DISPLAYTOP) { + if (DISPLAYLEFT && DISPLAYRIGHT) { + posOffset = GOALPOS + Vector2D(0.0, GOALSIZE.y); + } else if (DISPLAYLEFT) { + posOffset = GOALPOS - Vector2D(GOALSIZE.x, 0.0); + } else { + posOffset = GOALPOS + Vector2D(GOALSIZE.x, 0.0); + } + } else if (DISPLAYTOP) { + posOffset = GOALPOS - Vector2D(0.0, GOALSIZE.y); + } else if (DISPLAYBOTTOM) { + posOffset = GOALPOS + Vector2D(0.0, GOALSIZE.y); + } else { + if (MIDPOINT.y > PMONITOR->vecPosition.y + PMONITOR->vecSize.y / 2.f) + posOffset = Vector2D(GOALPOS.x, PMONITOR->vecPosition.y + PMONITOR->vecSize.y); + else + posOffset = Vector2D(GOALPOS.x, PMONITOR->vecPosition.y - GOALSIZE.y); + } + + if (!close) + pWindow->m_vRealPosition.setValue(posOffset); + else + pWindow->m_vRealPosition = posOffset; +} +``` + +I'm giving my example that i tested and apologize for the bad quality. I only +changed the `if` statements where `force` argument is not empty. + +```cpp +if (force != "") { + if (force == "bottom" && !close) + posOffset = Vector2D(GOALPOS.x, PMONITOR->vecPosition.y - PMONITOR->vecSize.y); + else if (force == "bottom") + posOffset = Vector2D(GOALPOS.x, PMONITOR->vecPosition.y + PMONITOR->vecSize.y); + else if (force == "left" && !close) + posOffset = GOALPOS + Vector2D(GOALSIZE.x, 0.0); + else if (force == "left") + posOffset = GOALPOS - Vector2D(GOALSIZE.x, 0.0); + else if (force == "right" && !close) + posOffset = GOALPOS - Vector2D(GOALSIZE.x, 0.0); + else if (force == "right") + posOffset = GOALPOS + Vector2D(GOALSIZE.x, 0.0); + else if (force == "top" && !close) + posOffset = Vector2D(GOALPOS.x, PMONITOR->vecPosition.y + PMONITOR->vecSize.y); + else if (force == "top") + posOffset = Vector2D(GOALPOS.x, PMONITOR->vecPosition.y - PMONITOR->vecSize.y); +``` + +I guess it could be refactored but i do not have the experience yet to do it +(intoducing a close bit for example). The slide direction does not depend on +whether the window is opened or closed. Meaning `slide top` will allways slide +the window to the top. # Examples and Interactions -The previous configuration would be rewritten into - -``` -animation=windowsIn, 1,2,windowIn, slide top -animation=windowsOut,1,2,windowOut, slide bottom -``` - -Where `top` and `bottom` give the direction of the window when going in or out. - # Drawbacks -People would have to change this in their entire config, could also be -counterintuitive to other people just as the way it is designed today is -counterintuitive to me Having to change the actual implementation +- Users will have to modify their configuration based on that change +- Could feel counterintuitive to users (as much as the actual behaviour is to + me) # Alternatives -Keeping the way it is +- Keeping the way it is # Prior art -This is already impleted +[This issue](https://github.com/hyprwm/Hyprland/issues/6826) mentions the way +animation work. I will emphasize the end of the description section "using +`slide top` (it then slides down)". The user has to describe the exact visual +result of that animation. I will allow myself to infer that the need to give +this information means that it doesn't feel intuitive to the user. This is also +a pretty recent change as it was implemented and merged the 15th of june. Before +that the option existed but was not parsed (ref: +[6512](https://github.com/hyprwm/Hyprland/issues/6512)) # Unresolved questions -Still no community feedback so I use this dedicated space to have some - # Future work - -Feel free to criticize it, sorry for my English as well i'm not native, also -first time doing an RFC