These two problems arose only after the upgrade from Xubuntu 118.04 to 18.10 and were verified by another user on the Xfce Forums. Problem #1 If I have an xfce4-terminal on the desktop and start a program such as the nn(1) news reader or mutt(1) mail reader, the programs start properly and recognize the terminal geometry. They utilities will also adapt properly to the terminal being resized. However, if you start a terminal and specify the utility using the -e flag, such as: xfce4-terminal -T Mutt --geometry 80x34+938+0 -e /usr/bin/mutt xfce4-terminal -T NN --geometry 80x31+938+0 -e nn The terminal will start with the proper size, but the size information (lines and columns) is not being passed to the the program (nn or mutt) and it defaults to assuming an 80x24 window size. If the terminal is then resized, the utility will NOT respond to the new size. One forum user suggested that this may be due to a switch to vte3 in the latest release. Problem #2 As way of background, I do have general problems with my desktop configuration since upgrading to 18.10. I have two monitors and always ran separate desktop managers on each screen. This broke during the upgrade and I cannot get a proper desktop environment on display :0.1. I have reported this as a bug here: https://bugzilla.xfce.org/show_bug.cgi?id=15116 I have a working desktop running on display :0.0 and have been able to launch Firefox and a couple of xfce4-terminals on display :0.1, but only by setting the DISPLAY variable before the command. For example: (DISPLAY=:0.1 xfce4-terminal --geometry 80x33+0+47 >/dev/null 2>&1 &) However, any attempt to use the command line option --display=:0.0 or --display=:0.1 are being ignored. Once I've placed anything on display :0.1, when I launch the command as: xfce4-terminal -T Mutt --geometry 80x34+938+0 --display=:0.0 --color-bg=#EDF4F0 -e /usr/bin/mutt the terminal still ends up on display :0.1. The --display option appears to be ignored as I've also noticed with other applications such as Firefox, and thus the need for the trick of setting the DISPLAY environment variable before launching the app. I mention this here because there is some chance that the two option problems may result from the same cause.
Problem #1: Works fine here on Xubuntu 16.04 with the latest xfce4-terminal: I've tested it using nano and mutt, both adhere to the geometry and window size changes. Could you please check if there's any difference for you when your this script from a terminal that's already open versus when you run it via the -e option? In my case, the output is the same and matches the terminal geometry. $ cat ~/winch.sh #!/bin/bash trap 'echo -n winch:; stty size' WINCH echo $LINES $COLUMNS stty size sleep 1 stty size sleep 1000000
Yes, everything worked fine for me for all the past versions of Xubuntu. All these problem only started with the upgrade to 18.10. Running from an open terminal that is 80x40 in size: 1-> /u/jeff/winch.sh 40 80 40 80 Running using -e 2-> xfce4-terminal --geometry 80x31+938+0 -e /u/jeff/winch.sh 31 80 winch:31 80 31 80 In both cases, I resized the window and nothing happens (i.e., no trap output on the resize), but in the second case, why does the trap output appear between the two stty outputs? I ran the second command multiple times and in a few cases I get: 31 80 31 80 without the trap output displaying.
To validate what OP is seeing, I'm seeing the same issues with mutt (Arch Linux running latest version of xfce4-terminal from git). When running "xfce4-terminal --geometry 80x40+938+0 -e /tmp/winch.sh" file, I actually get: 0 0 winch:40 80 40 80 What's interesting though, if I change the winch.sh file to: #!/bin/bash trap 'echo -n winch:; stty size' WINCH echo $LINES $COLUMNS stty size sleep 1 stty size sleep 10 /usr/bin/mutt It now works (running mutt from the script). mutt responds correctly. But "xfce4-terminal --geometry 80x40+938+0 -e /usr/bin/mutt" does not.
Yes! Good catch ToZ. I have two scripts. mutt_run is used to fire up mutt in a terminal and nn_run similarly launches nn. I created an executable named nnx which contains: #!/bin/ksh nn In my nn_run script, I replace the line: xfce4-terminal -T 'NN_News_Reader' --geometry 80x31+${X}+0 --color-bg='#EDF4F0' -e nn & with: xfce4-terminal -T 'NN_News_Reader' --geometry 80x31+${X}+0 --color-bg='#EDF4F0' -e nnx & and this works! The resulting initial terminal size is recognized by nn (just as you reported for mutt) although it doesn't respond to size changes. This appears to be a limitation of the very old nn code as mutt does adjust as you stretch the window. There seem to be some terminal initialization problem in conjunction with processing the command line arguments. Of course, the -e nn should work just like the nnx script but this one level of indirection appears to step around the bug. Now, is the failure to honor the --display option related to the terminal parsing bug or something more generic to xfce4 as a whole?
mutt is working fine here on Arch Linux, as well as nano. ToZ, what version of vte3 and xfwm4 do you have installed? I have the latest git versions of those in my system. Also, can you check how nano behaves under the same circumstances?
Jeffery and ToZ, could you please also verify the behavior of your apps when run with gnome-terminal? The command line parameters should be the same as with xfce4-terminal.
I installed gnome-terminal and modified my launcher scripts to use it. As far as the terminal sizing issue is concerned, running the command: gnome-terminal --geometry 80x31+0+0 -e nn >/dev/null 2>&1 & ends up with nn running at a default 80x24 size, but running: gnome-terminal --geometry 80x31+0+0 -e nnx >/dev/null 2>&1 & causes nn to run with the actual terminal dimensions -- i.e., with 31 lines. So the redirection is required similar to xfce4-terminal. (I had to add the output redirection to /dev/null because gnome-terminal spits out a bunch of junk when launched.) --------------------------------------------------------------- Although it is not documented on the gnome-terminal manual page, I tried to specify --display=:0.0 and --display=:0.1 on the command line. The program did not balk, but it seems to ignore this setting and always started the terminal on display :0.0 This is different from xfce4-terminal which also ignores the --display option but always starts on display :0.1. --------------------------------------------------------------- I then modified the script to use xterm. When it executes as: xterm -ah -T 'NN_News_Reader' -geometry 80x31+0+0 -fg black -bg '#EDF4F0' -e 'nn' & It works! nn runs with 31 lines without the need for the nnx redirection. Also, I added the "-display :0.0" and "-display :0.1" options to the xterm line and the xterm honors this and starts up on the appropriate display! However, on the xterm window decorations, the minimize and maximize buttons work, but the close/exit [X] button is a noop! --------------------------------------------------------------- I hope all of this provides some insight. Xterm appears to be functioning as a (mostly) proper X11 application, while the gnome and xfce4 terminals are not. It all very confusing. Packages: gnome-terminal 3.30.1-1ubuntu1 xfce4-terminal 0.8.7.4-0ubuntu1 xterm 330-1ubuntu3
P.S. Bringing this full circle, the xterm results make me think that what we're observing is a more fundamental flaw in the Xubuntu system with the 18.10 release. If you refer to my original bug report regarding the desktop failing to run on the second screen, and refer to all the data I provide at: http://smallthoughts.com/xfce/xfce.html it is surprising that xfce4-display-settings and arandr cannot properly identify the second display, and all the xfce4 applications seem to ignore the --display option, while standard X11 applications such as xterm and xscreensaver do see the second display and run properly on both screens. I hope this provides a clue as to where to look for the underlying problem.
(In reply to Igor from comment #5) > mutt is working fine here on Arch Linux, as well as nano. > > ToZ, what version of vte3 and xfwm4 do you have installed? I have the latest > git versions of those in my system. > Also, can you check how nano behaves under the same circumstances? xfwm4 latest build from git tree. vte3 version 0.54.3-1 (from Arch repositories). mutt issue exists in gnome-terminal as well. However, nano seems to work fine for me.
-- 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/31. 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