[openbox] urxvt maximized

Mikael Magnusson mikachu at gmail.com
Wed Jan 4 15:38:36 EST 2012


On 4 January 2012 21:30, Brian Mattern <rephorm at rephorm.com> wrote:
> On Wed, 04 Jan 2012, Jorge Almeida wrote:
>
>> On Wed, Jan 4, 2012 at 3:11 PM, Mikael Magnusson <mikachu at gmail.com> wrote:
>> > On 4 January 2012 15:38, Jorge Almeida <jjalmeida at gmail.com> wrote:
>> >> On Wed, Jan 4, 2012 at 11:58 AM, Mikael Magnusson <mikachu at gmail.com> wrote:
>> >>> On 4 January 2012 12:54, Jorge Almeida <jjalmeida at gmail.com> wrote:
>> >>>> I've noticed a problem with rxvt-unicode: when a window is maximized, an
>> >>>> obnoxious unusable strip appears at the bottom of the window (about 1/2
>> >>>> cm of heigth). The strip disappears when the window is unmaximized. I
>> >>>> have no idea whether this happens in other WMs. I currently have no
>> >>>> other WM installed. xterm does not exhibit this behavior. Anyone with
>> >>>> this problem?
>> >>>>
>> >
>> > Could you explain what the actual problem is? xterm behaves the same
>> > as urxvt for me, ie, any line or column that cannot fully fit a cell
>> > is left empty and unused.
>> >
>> http://www.math.ist.utl.pt/~jalmeida/urxvt_max.png
>> http://www.math.ist.utl.pt/~jalmeida/xterm_max.png
>> http://www.math.ist.utl.pt/~jalmeida/nomax.png
>>
>> The first picture shows the obnoxious dark blue strip at the bottom, the
>> second doesn't. Both have a regular blue strip that is vim-specific, and
>> has nothing to do with this. In bash, writing at the bottom of the
>> maximized urxvt window means writing just above the dark blue strip,
>> which is annoying. The third shows non-maximized windows, with the
>> expected behavior.
>>
>> Of course, this problem may not be related to openbox at all...
>
> It looks like when maximized, openbox forces the window to be the actual
> size of the 'maximized' region, instead of respecting its request to
> only be multiples of a given size. So, this leaves a space at the bottom
> of the window that rxvt cannot use.
>
> Maybe openbox should be changed to respect size increments when
> maximizing a window? (i.e., make it the largest multiple of the
> increment that is smaller than the available space)

Clearly showing whatever is behind the window is not going to be more
homogenous than what he has now :). I already mentioned this
possibility earlier in the thread. The icccm says the following:
"The base_width and base_height elements in conjunction with width_inc
and height_inc define an arithmetic progression of preferred window
widths and heights for nonnegative integers i and j".
Ie, preferred, not mandatory.

Also what dana said.

-- 
Mikael Magnusson


More information about the openbox mailing list