[Original comment by motif]

couldn't add i3log since it's generally larger than 1 MB

This is pretty much by design (of the implementation). I guess an acceptable way of achieving the wanted behaviour is to configure the window (in case it is borderless) to use less space than it normally would.

I will look into this, but not before the release of 4.1.

-ETIME, moving to 4.3

[Original comment by motif]

saw 4.1 has quite # of enhancement and bug fixes, particularly like the floating windows focus capability and looks like the problems with properly vertical/horizontal split are resolved?....
but still looking for borderless support, probably would wait for upgrade until this feature is there... :)

really like i3's performance btw, simple, clean, fully flexible and not bloated at all.... (though haven't tried 4.1.x yet)

[Original comment by klaas@…]

I attached a patch with a new command which can solve this issue:
As urxvt can actually handle width/height that are not "correct" with regard to *_increment by filling the space itself, we can actually ignore the size increment hints it sets and get a better results. To enable this in the configuration I added a command: "sizehints increment disable|enable|toggle".
This use case could be fixed like so: for_window [class="URxvt"] sizehints increment disable

There are some things I'm not entirely happy with:

• It has no effect on containers that have no window, but subcontainers: Should the command affect all leaf window containers?
• I'm not sure I correctly forced a redraw of that container, or if I should.

Hey klaas,

Thanks for working on this. I’ve looked at your patch and while it works, I’m not very happy with it. Introducing a new command to work around things like that is really not worth it and I’d like to avoid cluttering i3 with X11 workarounds.

Instead, how about the following course of action? I’ve read that Openbox 3.4 does not honor the size increments in fullscreen mode (see http://openbox.org/wiki/Help:Upgrading_to_3.4#Maximized_terminal_windows) and that at least urxvt, xterm and gnome-terminal cope with that just fine (I additionally tested ROXterm, which also works). Openbox 3.4 was released several years ago and they still do it that way, so it can’t horribly break things.

Therefore, I suggest we just don’t honor resize increment hints in tiling mode ever (but for floating windows, like GIMP toolbars, which rely on it). What do you think?

Best regards,
Michael

[Original comment by anonymous]

That would be perfect. I did not dare suggest that and didn't know that Openbox does it. In my opinion size increment hints are very much tied to a floating layout and there's no satisfying way to handle them in a tiling mode - except letting the application handle the extra space.
So I'm very much in favor of handling it that way.

I’ve posted to the mailing list, unless any good reason comes up for NOT doing it, i3 v4.3 will ignore size increment hints.

This ticket was fixed in commit http://c.i3wm.org/40b12c0a:
Remove support for resize increment size hints for tiling windows

As discussed on the mailing list and the bugtracker.

fixes #540

[Original comment by Robert.Siemer-i3wm.org@…]

You asked for reasons to honor size increment hints some time ago. I’m surprised no-one spoke up yet.

i3 is all about screen space: If I have a terminal (or two: one above the other) next to a browser, I would like to snap to a size (when resizing with a mouse) where I lose no space in the terminal(s) which I could use better in the browser. When resizing “in steps” with the keyboard jumping to a point in this grid would be nice sometimes, too.

If there are competing increments, ignoring them all together is a good first approach.