Originally the drop-down menu would scroll back up and leave everything as it had been for when I drop-down again. Now when the drop-down terminal scrolls back up, the dimension of the terminal window actually changes and closes down toward zero. This makes for a nice transition, but kills applications that require a minimum size. Desktop: Arch Linux 4.4.25-1-lts xfce4-terminal 0.8.0 (Xfce 4.12) Nano 2.2.6-3 Steps to recreate issue: *scroll down* $ nano *scroll up* *scroll down again* Window size is too small for nano... $
Hi, Your scenario is working fine for me; I'm also on Arch Linux but have newer component versions. Can you try updating nano and maybe also vte3 and even gtk3? The versions here are: nano 2.7.0, vte3 0.46.0+5+g398a3f8, gtk3 3.22.1+8+ge11df6c.
Created attachment 6878 Video of bug in action I should probably have noted that I am using SSH to work with a Debian Jessie server, and I have completely up-to-date programs on Arch. However, I believe we are getting a bit off the main point. The problem here isn't nano, because nano is certainly not the only terminal program that requires a minimum window geometry (in some versions). The issue is that the new way to scroll-up shrinks the window's geometry, causing some programs to exit. Attached is a webm of the event. First part is by manually shrinking the terminal screen and the other is of the drop-down terminal scrolling up.
Thanks, I was able to reproduce this bug on 0.8.0 with show/hide duration time > 0. However, current git version seems to fix the bug. Could you please try it - since you're on Arch? AUR package is https://aur.archlinux.org/packages/xfce4-terminal-git/
Just FYI: My favorite easy test case for tracking size changes is: $ zsh $ trap 'stty size' WINCH (It used to work in bash <= 4.2 too but bash-4.3 broke it, it delays handling WINCH until it's about to redisplay the prompt anyways.)
Another easy method should be to have a debug build of vte, and run xfce4-terminal with VTE_DEBUG=resize.
Created attachment 6879 Config File I updated to 0.8.0git-f778632 with no luck % trap 'stty size' WINCH # scroll up and drop down % 14 95 % 9 95 % 4 95 % 5 95 % 10 95 % 15 95 % 19 95 However, if I decrease the animation duration to <54ms, then the issue stops (although at that speed, it is instantaneous). I've attached my config file.
This is understood as the terminal window is getting smaller when hiding. If you don't want this effect, set duration time to 0 - the the window won't be resized and cause any problems. However, speaking of nano, it seems this particular issue has been resolved in their code and fix was included in something around version 2.3.3 (based on the date): http://savannah.gnu.org/bugs/?27265 I cannot reproduce the issue on my machine with nano 2.7.0 but can reproduce it on Ubuntu 14.04 machine with nano 2.2.6.
As much as I understand, this issue is not about nano in particular. Quite a few apps do probably have some visible side effects if the window is shrunk and then re-grown. E.g. text editors are expected to keep the cursor inside the visible region, and as a consequence, if you start with the cursor near the bottom and then shrink and enlarge the window, in most of the editors the viewport is scrolled so that the cursor is near the top. mc, when copying many files, updates the panels behind the copy dialog upon a resize, but not normally. Again you might say it's a bug in mc, but in turn there's a visible side effect of hiding and then dropping down the terminal again. The list is presumably much longer than this. I think it's a reasonable feature request (or, rather, a bug) that xfce4-terminal should animate hiding the terminal without actually ever changing its size. I guess this is achievable by placing Vte inside a GtkBox or similar with probably the shrink: true property, or something like this. At least, Terminator/Terminix used to sometimes do this accidentally when the shrink property of H/VPaned was set incorrectly.
Egmont, I think what you are saying makes sense, thank you. In fact, there's another option I'm going to try - I oversaw it in tilda which had had the same "window too small" issue with nano. The option is to move the window outside of the visible screen area instead of shrinking it - this will keep the window size. I think I will make it work tomorrow.
Nice idea... just make sure to test it with a huge variety of window managers, I'm afraid some may force the window to be in the visible area, breaking this concept. Hope not :) Another idea that occurred to me is to somehow take a "snapshot" of the vte widget's contents and replace vte with that still picture which you can deform in any way you wish (such as e.g. stretching or even funnier animations). It gets a bit tricky when the dropdown is opened again, probably you'd need a newer snapshot rather than the old one. I don't know how to take such a snapshot, but Terminix manages to do it for its window list thumbnails.
-- GitLab Migration Automatic Message -- This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/apps/xfce4-terminal/-/issues/16. Please create an account or use an existing account on one of our supported OAuth providers. If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev