Re: [wmii] Issues with current tip.

>> Hmm, try number 4 at writing this entry to the mailing list, the last
>> 3 times wmii crashed when dealing with spawning Gimp with images, I'll
>> include a backtrace of that as well. First off, one of the new
>> problems I encountered with the current tip.
>>
>> When selecting a window (for movement) using either MOD1+LClick or by
>> using the grab square on the title bar, two things happen:
>>
>> 1. All windows on the screen excluding the windows on the bottom of
>> the column shrink in height by a few pixels. Empty space is also
>> created below each of the windows (not above, all top of column
>> windows are still flush).
>>
>> 2. All bottom of column windows on the screen seem to maintain their
>> height, however still gain a bit of empty space below them.
>>
>> When I release the mouse button, all windows return to their previous
>> height. The window I select doesn't seem to matter.
>
> This is a feature, not a bug. Terminals ask to be resized in certain
> increments. In columns, this results in unsightly gaps between windows, so
> wmii tries to fill the extra space by giving windows extra increments. The
> problem with this is that, in certain circumstances, some windows wind up
> being favored over others, and wierd things happen with window heights in
> columns. So, when you try to resize windows with the mouse, wmii (now)
> first gives all windows the size that they would have if it didn't try to
> squeeze out the increment gaps. It's a necessary annoyance. Sorry.
>

This doesn't really bother me, I believe the reason I reported it was
because of the combination of that, and the resize bug which resizes
other windows in the same column. It seems to be happening a bit more
extreme than it did in the revision I was previously using. However this
has already been reported. Sorry to leave that part out.

>> Second is a problem I'm having with URxvt and the current tip. When
>> selecting any window in a column (using mouse over) which contains
>> URxvt terminals, every URxvt terminal in the column seem to redraw
>> causing the URxvt terminals to flash. If you place any other
>> application over top of that terminal (in float mode), then select a
>> window in that column with mouse over, the area in which the terminal
>> occupies seems to be redrawn, redrawing the section of the application
>> you placed over it.
>
> That's probably because we indiscriminantly reset certain EWMH properties.
> I've noticed that urxvt responds to this in annoying ways, which caused
> annoying problems before the aforementioned adaptations were in place. I'll
> look into it. I've never (ever) seen urxvt flash, though.
>
>> Third is another problem with URxvt. When resizing or moving a window,
>> or spawning/moving a window to the float layer, every URxvt window on
>> the screen flashes. Characteristics are the same as the previous
>> problem where all applications overlapping those terminals have
>> portions of their window redrawn.
>
> It's the same issue. What urxvt settings do you use?
>

Just to make sure I don't waste too much of your time I disabled
everything in my configuration then started enabling things one after
another. I found that I had enabled urxvt.inheritPixmap. With wmii I
don't use background images as much anymore so I had forgotten about it,
but with inheritPixmap on the terminal flashes when no background image
is set. Setting a background image eliminates the flashing on column
selection, as well as the flashing on window move and spawning/moving
windows to float mode.

I'm not sure whether that's supposed to happen though, so I'll leave
that up to you to decide. Here's my URxvt config anyway (after I
disabled inheritPixmap).

*SNIP*

#urxvt.background: rgba:0000/0000/0000/eeee
#urxvt.depth: 32
urxvt.font: xft:Terminus-9
urxvt.imFont: xft:mikachan-9
#urxvt.inheritPixmap: True

# Configure perl extensions.
urxvt.perl-ext-common: default,matcher

# Configure the matcher.
urxvt.matcher.button: 1
urxvt.matcher.pattern.1: \\bwww\\.[\\w-]\\.[\\w./?&@#-]*[\\w/-]

# Configure the tabbed mode.
#URxvt.tabbed.tabbar-fg: 7
#URxvt.tabbed.tabbar-bg: 4
#URxvt.tabbed.tab-fg: 15
#URxvt.tabbed.tab-bg: 12

urxvt.scrollBar: 0
urxvt.shading: 10
urxvt.underlineColor: #888888
urxvt.urlLauncher: /usr/users/kyon/.sandbox/src/swiftfox/swiftfox
urxvt.background: #000000
urxvt.foreground: #eeeeee
urxvt.tintColor: #ffffff
urxvt.color0: #000000
urxvt.color1: #a40000
urxvt.color2: #4e9a06
urxvt.color3: #c4a000
urxvt.color4: #204a87
urxvt.color5: #ce5c00
urxvt.color6: #038e82
urxvt.color7: #babdb6
urxvt.color8: #555753
urxvt.color9: #cc0000
urxvt.color10: #73d216
urxvt.color11: #edd400
urxvt.color12: #3465a4
urxvt.color13: #f57900
urxvt.color14: #05d2c1
urxvt.color15: #d3d7cf

*SNIP*

>> Fourth and final is the crash, I can reproduce it every time with the
>> following conditions:
>> ...
>> Given the above, it crashes for me after trying to spawn (I believe it
>> is) the main GIMP tool window and doesn't get farther than that.
>> ...
>> If it's something in my environment causing the crash or any of the
>> other problems I'll provide what I can.
>
> I'll see if I can duplicate it. It's nothing in your environment. wmii
> should never crash. If it does, it's its own fault, not yours.
>

Thanks, if there's anything else you need I still have the core sitting
around if you want it.

Thanks again,
Thomas

> --
> Kris Maglione
>
> For a long time it puzzled me how something so expensive, so leading
> edge, could be so useless, and then it occurred to me that a computer
> is a stupid machine with the ability to do incredibly smart things,
> while computer programmers are smart people with the ability to do
> incredibly stupid things. They are, in short, a perfect match.
> --Bill Bryson
>
>
>
> --===============0525232703==--
>
Received on Sun Jun 01 2008 - 00:49:49 UTC