mirror of
https://github.com/hyprwm/RFCs.git
synced 2026-05-07 13:38:14 +02:00
Merge 2edcca677b into 3965580f56
This commit is contained in:
VESSE Léo
GitHub
commit
b5273c4d8d
1 changed files with 154 additions and 0 deletions
154
rfcs/0001-animation-slide-side.md
Normal file
154
rfcs/0001-animation-slide-side.md
Normal file
|
|
@ -0,0 +1,154 @@
|
|||
---
|
||||
feature: changing slide side animation
|
||||
start-date: 2024-06-16
|
||||
author: Ciflire
|
||||
---
|
||||
|
||||
# Summary
|
||||
|
||||
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.
|
||||
- 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 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
|
||||
|
||||
# Drawbacks
|
||||
|
||||
- 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
|
||||
|
||||
# Prior art
|
||||
|
||||
[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
|
||||
|
||||
# Future work
|
||||
Loading…
Add table
Reference in a new issue