[gtk 3.20] broke geometry of window

[realh]

After upgrate gtk 3.0 to version 3.20 (gtk 3.20 + vte 0.44), roxterm does not accept no more geometry settings of the window - window will appear always the smallest as possible.

also 'roxterm --geometry 120x30' does nothing

Reported by: *anonymous

Original Ticket: roxterm/bugs/125

[realh]

I second this one. I think this commit should be the culprit

https://git.gnome.org/browse/gtk+/commit/?id=08974a1

"Ignore the geometry widget passed to gtk_window_set_geometry_hints()."

Original comment by: javiereg4

[realh]

See also https://bugzilla.gnome.org/show_bug.cgi?id=760944

Original comment by: egmont

[realh]

Ugh, getting the window size right and keeping it right has always been difficult. So I either need to hack some rather complicated/fragile/wierd code, rewrite most of roxterm from scratch (which it needs anyway), or give up on it altogether :-(.

Original comment by: realh

[realh]

It seems the geometry is now interpreted as pixels instead of character columns/rows, so as a temporary workaround you can specify the desired size in pixels.

Interestingly gnome-terminal on the same system still supports character geometry, maybe you can check their code to see how to pass it along to libvte?

Original comment by: *anonymous

[realh]

A comment in the GTK commit says that gnome-terminal was the only app that used the geometry widget; they overlooked poor old ROXTerm. The other common terminals mostly still use GTK2, but there's been mention of a new one called Terminix.

gnome-terminal's code still assumes the use of a geometry widget in gtk_window_set_geometry_hints, so a quick fix for ROXterm isn't as simple as just copying whatever changes g-t made, because apparently they didn't make any for this. And it has its own history of window geometry bugs.

Original comment by: realh

[realh]

.

Original comment by: *anonymous

[realh]

g-t doesn't have a fix committed yet, but allegedly the one in the bugtracker works. I haven't had the chance to verify it yet.

Terminix doesn't do geometry (it doesn't make sense for a multiple-terminals-in-one-window app, there's just no way to get it right).

Original comment by: egmont

[realh]

This is the solution Mate developers used, that inspired the one for gnome-terminal https://github.com/mate-desktop/mate-terminal/commit/c0efce1

Original comment by: javiereg4

[realh]

Tony, First thanks for making Roxterm, while I've only been using it for a year or two, it is much better for my needs than any alternatives. The killer feature for me is the ability to drag-drop files from the GUI and have it automatically insert the path into the CLI, like the OS X terminal. LXterm doesn't, nor any others I tried so far.

Since I do not wish to go back to manually typing paths (this is the 21st century, right?) I also hope there is a way to get Roxterm working again. Can't help much myself, I'm a sysadmin not a programmer, except to troubleshoot/diagnose/test new builds.

I found a workaround to this geometry bug #125, but it is tedious and has to be done on every invocation of the program. If it can be automated, for example by inclusion in the source code, or even by being the default behavior for libgtk 3.20+ as defined in the configuration files installed with the package, the problem will disappear, at least until they break something upstream again.

Here is my suggested workaround: Open the Preferences menu, select Edit Current Profile. Adjust the Width of the window. One column up or down, either works. Voila, window now no longer small, but about the size expected +-1 column. To make sure it won't grow/shrink over time with repeated invocations, best to make it both increase and decrease 1 column per invocation, so the net effect is 0, it simply forces it to redraw at the right size.

Original comment by: lyubod

[realh]

The killer feature for me is the ability to drag-drop files from the GUI and have it automatically insert the path into the CLI, like the OS X terminal. LXterm doesn't, nor any others I tried so far.

gnome-terminal does that too.

Original comment by: realh

[realh]

So does Terminator and Terminix (just for the record).

Original comment by: *anonymous

[realh]

Thanks for your quick reply. I will give gnome-terminal a shot, based on your recommendation. A little apprehensive, I'll quote you, from this thread no less as to why I don't want to depend on it:

"gnome-terminal... And it has its own history of window geometry bugs."

i.e. you fix/workaround their bugs faster than they do :-)

Original comment by: lyubod

[realh]

I wish I was kidding about the bugs, but I had to overcome 3 separate ones to get gnome-terminal to work about as well as roxterm did out of the box:

https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/996731 Same problem as nautilus, won't show in menu, desktop file needs editing

https://bbs.archlinux.org/viewtopic.php?pid=1412603#p1412603 crashes even in terminal, unless the fix is applied

http://www.howtogeek.com/howto/ubuntu/set-the-default-terminal-emulator-on-ubuntu-linux/ how to reset x-terminal-emulator so it default to gnome-terminal, note that the character before config has to be a double dash "--"

These require at least a logout/login or in some cases a reboot to take effect.

Debian Stretch, May 2016 Breadcrumbs for others with the same problem

Original comment by: lyubod

[realh]

Any updates on this?

Original comment by: *anonymous

[realh]

Yes, roxterm is now discontinued I'm afraid. See [https://sourceforge.net/p/roxterm/discussion/422638/thread/60da6975/]

Original comment by: realh

[realh]

Tony: Sad to see roxterm go, it was my favourite terminal emulator! Thanks for all the work on it!

Original comment by: *anonymous

[realh]

Don't know if this is helpful, however I implemented a geometry switch in Terminix a couple of months ago but did it in a way that was quite simple. Basically I just ignored the GTK support for geometry and relied on VTE to set the geometry in the exact same way that profile preferences does it, by setting the VTE width and height on startup via vte_terminal_set_size. The window then grows/shrinks automatically to accomodate the VTE.

I haven't had any complaints about this implementation but I don't know how many folks are using it.

Original comment by: *anonymous

[realh]

Shane, come back!

Original comment by: *anonymous

[realh]

It still works fine once you set the geometry in pixels. (Which makes more sense than rows/columns anyways)

Isn't it just a matter of changing the default to a pixel value?

I realize theres other issues in the long term but I would really like to see RoxTerm continue! I've tested every terminal I can find and its the only one that does everything I need without some glitch on my setup

Original comment by: *anonymous

[realh]

I have just upgraded my gtk+ to 3.20 (actually the complete system from Xenial to Yakkety beta), and gnome-terminal's resize works fine, just as before.

The details, patches etc. should be at the aforementioned gnome-terminal bug.

I did not follow that thread and I don't know what was going on or how it was fixed, but there's a proof that it's fixable.

Alas, roxterm is already removed from Yakkety.

It'd be sad to see this project getting abandoned just because noone feels like implementing this one-time fix, even despite having access to the same fix for gnome-terminal.

Original comment by: egmont

[realh]

I don't think it's that simple. I did look at what they'd done to gnome-terminal, but its interactions between the top-level window and vte are rather different from roxterm's and I didn't see anything there I could easily apply to roxterm's code. I couldn't even see that they'd had to make any changes at all to avoid suffering the same bug as roxterm.

Besides this bug roxterm heavily relies on at least one related function that is now deprecated so I'd have to deal with that too. And there are several other outstanding bugs. The codebase is frankly a mess, somewhat compromised by its slow evolution, and there were always difficulties, not so much with getting windows to open at the right size, but to stay the right size. Tab sizing is a similar story. Successive versions of GTK tend to change these problems, but never stop them from being problems.

I'm sorry, but I don't feel motivated to put in so much hard work to turn this code (most of which I've lost familiarity with by now) into something I can be proud of again, and it never felt like it had more than a small niche following.

It feels like all the desktops and major apps are dying a slow death anyway.

Original comment by: realh

[realh]

Thank you for all your work on this project during years. I would rather say "It feels like everything on earth is dying a slow death anyway", lol. And programmers become family founders, have some more important things to do in real life as years are passing away, their centers of interest move and it's more sane for them than having a monolithic no-life coding 24/24.

Good luck Tony, happy life! May all your professional and personal projects be successful!

FOSS projects can die, but not our love for FOSS community

Original comment by: fenyx81

[realh]

Hi Tony, Don't give up, roxterm is great indeed.

Original comment by: *anonymous

[realh]

An interesting note: if you start roxterm in maximized or fullscreen mode (e.g. roxterm -m), then when you unmaximize it it has the correct size. This is not the case if you start it normally and enter either of those modes. Perhaps this will be a hint for a real fix.

I'm willing to put some time into fixing this bug. I'm a C programmer though not a GTK programmer. I use roxterm because it is much faster for scrolling when lots of text is being printed than anything else I've tried; it beats xfce4-terminal hands down. Any interested in collaborating? -- dwksrc at gmail period com

Original comment by: *anonymous

[realh]

If you need anything like a higher level of access to this project, or export to github, just ask.

Original comment by: realh

[realh]

I sent you a preliminary patch via email. Hopefully I'll have time to fix its bugs and send in a real fix for this bug in the next few weeks -- dwksrc at gmail period com

Original comment by: *anonymous

[realh]

Thanks for making the effort. I hope you can get it working properly. Again, let me know if you want to be added to the project or move it to github.

Original comment by: realh

[realh]

github would be nice :)

Original comment by: *anonymous

[realh]

Done: https://github.com/realh/roxterm

Original comment by: realh

[realh]

Tony: It was my favourite terminal, thanks for all the work. I'm going to use it on ubuntu 16.04. Hope you or someone can fix it someday.

Original comment by: *anonymous

[realh]

For anyone interested, I have a fix for this issue for roxterm-3.3.2. It can be found here: https://gitweb.gentoo.org/user/haarp.git/tree/x11-terms/roxterm/files/gtk+-3.19.5+-geometry-fix.patch

All credits go to "d wk" for the fix, I just adapted it for 3.3.2.

Original comment by: haarp

[realh]

Roxterm is a great terminal, please don't give up.

Original comment by: *anonymous

[realh]

haarp, This patch seems to be incompatible with the code at https://github.com/realh/roxterm . Is there any way to merge it in there?

Original comment by: *anonymous

[realh]

haarp, this patch appears to be incompatible with the source at https://github.com/realh/roxterm . Is there any way it could be merged in there?

Original comment by: jonorthwash

[realh]

Patches fine for me. Are you using patch -p1?

Original comment by: *anonymous

[realh]

Patches fine for me. Are you using patch -p1?

Original comment by: haarp

[realh]

Ah, got the patch to apply now. Not sure what I was doing wrong before (pretty sure I was using -p1). Now to convince it that it does have a version and stuff...

Original comment by: jonorthwash

[realh]

I notice that this patch seems to cause crashes a lot when moving tabs in/out of the window. Any fix for that?

Original comment by: *anonymous

[realh]

Although we've managed to get rid of the main symptom, it still isn't right, and now has the opposite problem in Wayland. I think replacing gtk_window_parse_geometry should be the next step. Also, gtk_widget_get_alloc*, and even trying to read the size from the GdkWindow, do not appear to be reliable. All the functions that need to calculate the size of the top-level required to accommodate a terminal of a desired size probably need to be done during "size-allocate" signal handlers, which seems successful so far (when toggling the menu and tab bars).

[realh]

I just can't fix this. We need to call gtk_window_set_default_size before showing it, but to call gtk_window_set_default_size we need to know the size of the "chrome" and the window decorations. But even though I've packed all the widgets and called gtk_window_show_all on them (except for the top-level window, but I've called gtk_widget_realize on it), reading the allocations still returns useless values for the window and the vbox. gtk_widget_get_preferred_width/height returns values that are a bit more realistic, but they're still wrong.

[realh]

I played around with the ordering of realize and show_all and suddenly started to get sensible values out of them. Then there was a bit of a whack-a-mole session, but I think I can finally consider this fixed. I'll see what I can do about the other reports before releasing, but some of them may need feedback from users of packaged versions.

[ramnes]

Awesome!

[dflock]

This still happens for me on latest roxterm on Xubuntu 20.04.2