adding transition #752
adding transition #752
Conversation
|
Is it possible to make the transition direction depend on wether your going to the next/previos workspace instead of just what app is transitioning. Sorry I see you can use or for this functionality. |
I don't think any way exists to find out which workspace is currently on because there are lot's of different window manager out there. So basically
Happy to hear you enjoyed the looks, I totally forgot about man pages but will look for it in the future, Thanks for mentioning that. |
There was a problem hiding this comment.
Thanks for your work!
In general I have some reservation about the compositor moving users window around (changing opacity/color/etc is fine). The reason being the confusion this could cause, because although the window is shown at a certain location on screen, it doesn't accept user interaction at that location.
But I guess it is for the user to decide whether they want this. So I won't reject this PR on that ground.
This PR is somewhat messy, I would like to see some clean ups:
- bug fixes shouldn't be in separate commits. each commit should not have known bugs at the time of merge.
- changes should be splitted into smaller commits. this is to make it easier in the future to locate origin of bugs. as an example, for this PR, you could split it into:
- add config options
- add easing functions
- implement transition
- implement transition rules.
As a side note, I wonder if the current fade-in/fade-out feature can be implemented with the same transition mechanism, if you make it more generic.
| @@ -1,3 +1,28 @@ | |||
| ################################ | |||
There was a problem hiding this comment.
There is not enough explanation here for:
- what does transition do? i.e. what is being transitioned?
- what is transition-offset?
- what is the meaning of each transition-direction?
| @@ -581,6 +582,10 @@ char *parse_config(options_t *opt, const char *config_file, bool *shadow_enable, | |||
|
|
|||
| .track_leader = false, | |||
|
|
|||
| .transition_direction = -1, | |||
There was a problem hiding this comment.
Wrong indentation size. Can you run clang-format over your changes?
|
|
||
| // Transition | ||
| if(w->transition_time >= 0.0f && w->transition_time <= 1.0f) { | ||
| // TODO: use refresh rate instead of using static 60 fps calculation |
There was a problem hiding this comment.
I'd like to see this todo completed before merging
| unsigned int direction = w->transition_direction; | ||
|
|
||
| // Smart direction | ||
| if(direction > TRANSITIONDIR_TOP) { |
There was a problem hiding this comment.
I don't quite understand the logic here, maybe because it is not explained what the transition directions mean.
| @@ -0,0 +1,173 @@ | |||
| #include <math.h> | |||
There was a problem hiding this comment.
This file doesn't follow picom's naming convention.
|
Moved to #766. |
Accept my apology
So this is my first ever PR and I'm not that much familiar with Picom and Compton code base yet and i really understand if this not going to get merged, But i said give it a try.
How works
This PR adds transitions to windows, It basically gives static offset from specific direction to window and then transition form there.
Configurations
I tried to replicate CSS transition properties in configs, So these are configs:
transition-durationtransition-offsettransition-directiontransition-timing-functiontransition-rule(similar to opacity rule but it changes transition direction)There are more details about each config in picom.sample.config file.
Demo