Improve pulldown animation

[Kalabasa]

Some stuff I did for my own tilda to make the animations smoother. I thought I'd share some.

• Changed the easing steps of the animation. I replaced the hardcoded easing steps with two functions animation_ease_function_<up | down>(i,n). The positions are still precomputed.
• Changed the number of frames from 16 to 32.
• Made vertical animation not resize the window. The window just moves off-screen as in horizontal animation. Fixes #14 and the terminal flashes when collapsing. So, there's no resizing at all now.
• Prevent overlapping animations (e.g., when you press the hotkey rapidly). It caused crashing, I think. Now, you have to wait for the animation to finish before you can toggle again.
• Put config_getint call outside the animation loop to prevent stuttering due to getint doing file I/O.

[lanoxx]

Hi,

thanks a lot for your patch. When reviewing your patch I noticed that the whole animation thing does not seem to work on metacity and it looks like also not on compiz and mutter, so I am wondering which window manager are you using? In generally I think moving rather than resizing is a good idea and I have been wanting to work on this for quite a while but never found the time, so your patch is very welcome, but we need to make sure this works on all window managers.

I will try to find out whats preventing the window from moving outside of the screen area on my window manager. Maybe we can add a conditional flag that keeps the old resizing code for window managers that dont support moving windows outside the screen area.

[Kalabasa]

I'm using xfwm4 but I haven't tested other window managers. The animation works in all directions on xfwm4.

[lanoxx]

Ah I see, I also tried xfwm4 earlier and noticed that it worked there.

[lanoxx]

Ok, I found some more information, for example Metacity constrains windows movement to be fully on screen, so windows cannot programmatically move themselves partially outside the screen, which is why the scroll animation breaks. Only if the user actively grabs the frame and moves it partially out of the screen then thats a different story.

There is an exception though: If the window is of type DOCK or DESKTOP then these constraints do not apply.

• The DESKTOP type window causes a window remain behind all other windows so the window is only visible if all normal windows are minimized.
• The DOCK type causes a window to be always above all other windows and behave like a panel

In order to make the animation experience more reliable and smooth we could make the tilda window a DOCK type window and restore the normal window state after the animation. When I have time I will give this a try and let you know if that works.

[lanoxx]

So I pushed wip/animation with a few changes on top of your commit (squashing your two commits into one). Notably I am setting the window hint to type DOCK before the animation and then reset that after the animation, that allows us to get a working animation on at least metacity, compiz and mutter and xfwm4. I did not test other window managers.

I also prevent the animation when the tilda window is fullscreen as I could not reliably get that to work and I removed your if branch, as that was not really needed:

            if (tw->current_state != STATE_GOING_DOWN)
            {
                break;
            }

The tw->current_state == STATE_UP at the beginning of the branch was already enough to prevent flickering during pull up and down.

Finally I also split the code in the pull function into separate pull_up and pull_down functions as it was really getting a little too big.

Please let me know what you think. If I don't here any complaints I will probably merge it in a few days.

@pik If you have time, maybe you can give this a try as well :-)

[Kalabasa]

Thanks. I tested the latest wip/animation 12433f1df9e9373b41264c3c8227cb3ed439487c on xfwm4. The window does not get focus after pulling out.

Testing previous commits, 7e582a1021cbe67ccd7787c1f009220a37c54d4b was the last commit where the window gets focus, and 56122f59c86b960523d56ce5722d610ac75efbd4 (set hint to DOCK) is when the window stops getting focus on pull out.

I tried putting tilda_window_set_active (tw) back to the beginning of the function. The result was that tilda gets focus for a split second at the beginning of the animation and then loses focus.

I also tried using gtk_window_present() despite the warnings (didn't see graphical glitches though), but the window still can't get focus.

It has something to do with the dock type, but I don't know why.

[lanoxx]

Hi, I just tried this with xfwm4 and I have no trouble getting focus. I can see the coursor carret getting focus immediately after the animation has finished.

Which version of xfwm4 do you have?

This is xfwm4 version 4.11.1 (revision 2b800f4) for Xfce 4.10
Released under the terms of the GNU General Public License.
Compiled against GTK+-2.24.23, using GTK+-2.24.23.

Build configuration and supported features:
- Startup notification support:                 Yes
- XSync support:                                Yes
- Render support:                               Yes
- Xrandr support:                               Yes
- Embedded compositor:                          Yes
- KDE systray proxy (deprecated):               No

[bnkr]

Perhaps you should look at #116 and some associated bugs if you're getting problems with xfwm4. I've always had some strange behaviour with tilda focus not matching what the window seems to be doing on that window manager (e.g. F11 sometimes maximises tilda when itilda is pulled up). You may be hitting this strangeness too.

[Kalabasa]

    This is xfwm4 version 4.10.1 (revision 3918e6b) for Xfce 4.10
    Released under the terms of the GNU General Public License.
    Compiled against GTK+-2.24.25, using GTK+-2.24.25.

    Build configuration and supported features:
    - Startup notification support:                 Yes
    - XSync support:                                Yes
    - Render support:                               Yes
    - Xrandr support:                               Yes
    - Embedded compositor:                          Yes
    - KDE systray proxy (deprecated):               No

Seems to be a problem at my end. Maybe I'll upgrade xfce and test. I'm using a modified build for now. Thanks.

[lanoxx]

@Kalabasa Were you able to resolve the issues you had with my animation branch and your version of xfwm4? I am considering to merge the animation branch into master before I release Tilda 1.3, so some more feedback would be nice.

[Kalabasa]

I upgraded to xfwm 4.12 and I am using latest wip/animation and there were no major problems.

The only minor issue right now is that the terminal gets focus only after the animation finishes. I was used to being able to type commands immediately after pressing the toggle key. But it's not really a showstopper, I guess.

[lanoxx]

I just merged it to master. Thanks for reporting back. I think the fact that you cannot type commands immediately is a result that I set tilda active only after the animation finished. I am not exactly sure anymore why I did that but it must have been because of some other issues, so for now I will leave it like this.