>> 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==-- >
