mirror of
https://github.com/hyprwm/RFCs.git
synced 2024-12-05 03:15:58 +01:00
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.
This commit is contained in:
VESSE Léo
parent
fef54a7592
commit
2edcca677b
1 changed files with 125 additions and 25 deletions
|
|
@ -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
|
||||
|
|
|
|||
Loading…
Reference in a new issue