Description of problem: With gtk3-3.19.5 (either -1 or -2), the --geometry option to gnome-terminal no longer works, for example "gnome-terminal --geometry=80x24" creates a window with the wrong size. It works properly with gtk3-3.19.4-1.fc24. Version-Release number of selected component (if applicable): gtk3-3.19.5-2.fc24.x86_64 How reproducible: always
Still broken with 3.19.6.
Still broken with 3.19.7. Is it possible that this is a gnome-terminal bug? Seems strange that gtk3 would be responsible for such a selective bug, but I don't know enough about the packages to say.
BTW, this happens using either Wayland or Xorg. The window seems to come up in the same wrong size either way.
Filed https://bugzilla.gnome.org/show_bug.cgi?id=760944 upstream against gnome-terminal.
(In reply to Andre Robatino from comment #2) > Still broken with 3.19.7. Is it possible that this is a gnome-terminal bug? No, the very specialized gtk feature that only gnome-terminal was using to support its chunky resizing is no longer working.
(In reply to Matthias Clasen from comment #5) > (In reply to Andre Robatino from comment #2) > > Still broken with 3.19.7. Is it possible that this is a gnome-terminal bug? > > No, the very specialized gtk feature that only gnome-terminal was using to > support its chunky resizing is no longer working. According to https://git.gnome.org/browse/gtk%2B/commit/?id=08974a1e9a6099a5a94b9d56970dbf96e473ba87 (mentioned in https://bugzilla.gnome.org/show_bug.cgi?id=757282 ) window: Ignore geometry widget Ignore the geometry widget passed to gtk_window_set_geometry_hints(). Usind the widget itself was a hack that complicates the size request machinery. It is also incorrect in that it doesn't respect height-for-width. Last but not least, it was only used by gnome-terminal and that application can easily work without it. It seems from the above that this should be reassigned to gnome-terminal, and that it should be able to implement --geometry differently.
Yes, gtk removed support, so gnome-terminal should either remove that command line option, or implement the behavior in a supported way. Reassigning.
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle. Changing version to '24'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase
This bug is still in Fedora 24: $ rpm -qa | grep gtk3-3 gtk3-3.20.6-1.fc24.i686 gtk3-3.20.6-1.fc24.x86_64 $ uname -a Linux blueglow 4.5.7-300.fc24.x86_64 #1 SMP Wed Jun 8 18:12:45 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux $ cat /etc/redhat-release Fedora release 24 (Twenty Four) $ rpm -qa | grep gnome-terminal-3 gnome-terminal-3.20.2-2.fc24.x86_64 $ gnome-terminal --hide-menubar --geometry=180x22+0+0 Option "--geometry" is no longer supported in this version of gnome-terminal.
Will whatever patch is landed upstream in https://bugzilla.gnome.org/show_bug.cgi?id=760944 be applied to gnome-terminal in Fedora, post-haste so that we don't need to wait until F25 for this important feature to be working again?
I assume this metioned patch will also fix the very annoying problem with terminal geometry not changing when zooming?
This is reported as fixed upstream now. What does it take to get it into F24?
Looks to be fixed in F24. The --geometry flag works on my currently installed version 3.20.3-1.fc24.
*** Bug 1351384 has been marked as a duplicate of this bug. ***
It doesn't seem fixed in my F24? gnome-terminal-3.20.3-1.fc24.x86_64 gnome-terminal --help-all says: --geometry=GEOMETRY Set the window size; for example: 80x24, or 80x24+200+200 (COLSxROWS+X+Y) but gnome-terminal --geometry=+0+0 places the window in the middle of the screen, not the top left, as does: gnome-terminal --geometry=80x24+0+0 The COLSxROWS works (it always has), but not the +X+Y Can anyone else confirm this actually works in F24?
When using the default Wayland, the same thing happens in F25. (I believe setting location works in X, though. I don't know if that's a Wayland issue or something that can be fixed in gnome-terminal.)
I'm using X in F24 (no wayland). No update has fixed this bug on my side here. I don't think the fix ever made it into the Fedora packages. Can the original reporter confirm this is the case and reopen this bug?
I'm the original reporter, but I don't have any F24 machines any more, they're running F25 now. I verified that on F25, the location setting works on X but not Wayland. I'll reopen the bug for F24.
Andre, sorry, but I jumped the gun. I had a chance to test this bug on a different F24 box that uses a stock wm and --geometry worked! No bug! So it is solved on F24 with X. My personal box uses sawfish wm and there appears to be a new conflict between the ignore-program-positions, place-window-mode and gnome-terminal. I think this may be more a sawfish bug than a gt bug, so you can once again close this bug (as it pertains to X). I will follow up with the sawfish guys. Further info: I was fooled a bit because with my normal settings xterm's geom would work but not gt's. My normal settings are "place-window-mode" centered. With that, xterm geom still works but not gt's. Weird. geom works for everyone if I set "place-window-mode" to "none". But then I lose non-geom'd windows starting in the middle where I like them. Oh well. I'm 100% positive gt + geom used to work with "centered" mode, so I'm not sure why it's broken now. Maybe something in gtk changed how it effects placement. P.S. As for wayland not supporting positioning by design, that provides yet another reason why I will postpone the switch to it as long as humanly possible. Wayland was probably designed by the windows-are-always-maximized crowd who don't care about such things as placement. Me, I have 100+ windows open in 16 workspaces at all times on 2880x2550 screen(s). Reboots are hell and only by scripting with -geom can I remain sane. Placing all the windows by hand takes forever.