LilyTerm causes Xorg to go mad by fighting with the awesome window manager about its size

[blueyed]

I have noticed that when I use a titlebar for the clients/windows in the awesome window manager and "font_name = Ubuntu Mono 12" (size appears to be irrelevant), LilyTerm misbehaves when I make the client fullscreen: the Xorg process goes nuts (CPU and memory), and it seems like the LilyTerm window gets bigger and bigger (according to the scrollbar). Nothing is visible in the window (just the background, no cursor etc).

This is caused by using font_name = Ubuntu Mono 12.

With the default of Monospace 12, or when the client/window has no titlebar, it works as expected.

I am using the default titlebar config for awesome (which is just disabled by default), and toggle it using the following key binding:

awful.key({ modkey, "Shift"   }, "t",      awful.titlebar.toggle),

This does not happen with gnome-terminal.

This happens with both size_hints_honor = false and unconfigured (should be true) in awesome's settings.

I am using awesome 3.5.2 and LilyTerm master.

Reported for awesome at: https://awesome.naquadah.org/bugs/index.php?do=details&task_id=1214 (includes an xtrace log).

[blueyed]

This appears to be a bug in LilyTerm.

From the awesome bug report:

Reason for closing: Not a bug Additional comments about closing: Let's start with quoting the relevant standard that lilyterm is violating (ICCCM § 4.2.4):

The response of the client to being resized should be to accept the size it has been given and to do its best with it. Clients must not respond to being resized by attempting to resize themselves to a better size. If the size is impossible to work with, clients are free to request to change to the Iconic state.

The bug comes from LilyTerm/src/window.c, function window_size_request() which calls gtk_window_resize(), something that is not allowed from within the size request handler.

I do not understand why the code thinks that it has to do this. It might be possible that awesome is calculating the geometry from the size hints incorrectly. However, that still doesn't allow LilyTerm to violate the standard. (Also, I am too lazy to compile LilyTerm and add some printfs to test this and the #ifdef hell in the code already scares me)

[blueyed]

More information from the awesome bug report:

This has nothing to do with size hints. If some magic settings* are enabled, LilyTerm considers itself to be smarter than everyone else. Whenever it is resized to a different size than it wants to be, it just resizes itself to its prefered size. This has nothing to do with the size of characters etc. I don't even see how this could be influenced by your Ubuntu Mono font.

*: This is the relevant code. Judge yourself if this is self-explanatory: // [Showing/Hiding tabs bar] and [Change the vte font] won't run the following codes. if (win_data->keep_vte_size&0xa94a)

[Tetralet]

Due to the strange resize behavior of GTK2+/GTK3+, LilyTerm must handle the size itself, or it may cause problem.

Please visit follow link for more information: https://lists.debian.org/debian-mentors/2010/10/msg00497.html

Bad news: the size behavior was changed (again) in the recent version of GTK3+... Now it became almost un-fixable.

The LilyTerm resize policy is very sample: LilyTerm is just only trying to keep the size that the vte widget asked for. In your case, (Ubuntu Mono 12 + Awesome), after calling gtk_window_fullscreen(), the vte widget ask for keep the size to 576x314 (82x24), so lilyterm resize itself to 576x314. I have no idea how to fix it... Sorry.

Please use GTK2+ version of LilyTerm instead. Thanks!