goomwwm: Get out of my way, window manager!

aerosuidae · 2012-07-19 00:33:32

mikezackles wrote:

So it's seeming to me like my issue happens every time XSetWindowBorderWidth is called with a width of 0. Swapping out for XConfigureWindow doesn't seem to help.

Interesting find. You can probably tell from the source comment those XSetWindowBorderWidth calls were a hack put in to get around a similar previous problem where only small gtk windows were not refreshing. As I recall, the box I was testing on at that time was also nvidia.

Your discovery, plus me sitting with a coffee for a while mulling stuff over, led me to recall a client_moveresize() patch I committed several days ago to fix a bug where border width was not taken into account when checking window min/max size hints. That bug also triggered a window refresh glitch, though only rarely and randomly. I have a hunch now that the original refresh problem described above was due to that client_moveresize() bug, and we could now remove the XSetWindowBorderWidth hack entirely...

Testing here seems to back up this idea, so I'm removing those XSetWindowBorderWidth calls from the master branch, but:

@bgc1954 - Was it you who previously had issues with windows not refreshing, or being greyed-out? Out of interest, are/were you using nvidia? Have they come back now?

mikezackles · 2012-07-19 00:54:06

Thanks! My windows display correctly when I open them with the latest master. But the fullscreen issue is still happening. I did a bunch of fiddling with client_review_border, but the only way I was able to make it work was to resize the window by a pixel and back, which seemed kinda slow and ugly.

Something else that's occurred to me: It seems like the border changes in client_review_border don't show up until the *next* resize. E.g., a window loses its border on the resize after it goes fullscreen, and gets it back on the resize after that.

kjwinchester · 2012-07-19 01:21:28

Hi - I've been using i3 for a while, but happened upon this thread and decided to give goomwwm a try. It seems to work well, but it has the same missing bit of functionality that I've seen with most WMs. I have two monitors, and what I would like is that when I start X, I get chromium running on the left monitor and lxterminal running on the right, automatically. I do not see anyway in the goomwwm man page for specifying the monitor of a launched application. Is that something that can be done?

aerosuidae · 2012-07-19 01:53:24

@mikezackles, the fullscreen issue: Are we still talking about all windows here, including Firefox, or is it now restricted to some terminals?

If I mod-pageup resize gnome-terminal to full screen here on one of my monitors, its bottom border ends up slightly off-screen, but on my other monitor with a different resolution, there are gaps on bottom and right. This is because GT is receiving our direction to go precisely full screen, but the app then immediately sends another ConfigureRequest of it's own to adjust size to the nearest multiple of columns and rows. Since goomwwm is not a true tiling window manager, it tries to be diplomatic and let apps resize when they want to.

Oddly, if I press mod-pageup on GT a second time, it will then surrender and go properly full screen without a border.

In contrast, xterm, urxvt, and konsole all go full screen immediately. lxterminal and gvim behave the same way as GT.

@kjwinchester, something like a monitor -rule? Yep, ok, I think we can add that...

aerosuidae · 2012-07-19 02:34:28

@kjwinchester, see new -rule flags: monitor1, monitor2, monitor3.

I realise amazingly cool people might need a monitor4 or higher, but I'm going to leave that for goomwwm v2 as I think it might deserve a more flexible way of defining rules

aerosuidae · 2012-07-19 07:43:00

Besides all the bug fixing here are some thoughts on recent changes that I'm finding useful:

mod-c window cycling now treats tiled windows as one, raising them all in one go. This makes the assumption that tiled windows are probably closely related -- valid guess, I think? -- so they should be treated as a mini tag group. It also allows faster cycling through deep stacks.

mod-shift-i,j,k,l tiled-window swapping as suggested by @dublindan is just the bee's knees, imho It recreates some of the warm-fuzzy feeling that Musca had. I often find myself creating a master area and stacking area and using the window-swapping for fast task switching every bit as efficiently as a true tiling WM.

The -flashtitle show option, turned off by default, is nice when using click-to-focus, but also when also using rules to place new windows on another tag as it shows what is happening.

mod-shift-F[1-9] toggles tags for the active window. This is more effective and less fiddly than mod-t when assigning a window to more than two tags.

Other opinions welcome.

Last edited by aerosuidae (2012-07-19 07:44:30)

mikezackles · 2012-07-19 11:46:43

@mikezackles, the fullscreen issue: Are we still talking about all windows here, including Firefox, or is it now restricted to some terminals?

Yeah, nothing has really changed too much as far as the fullscreen issue. It's still happening for all windows. They've all (usually) still got borders at fullscreen, then display glitchy behavior one resize after fullscreen, and then behave somewhat normally until the next fullscreen.

One other observation is that windows besides gnome-terminal shrink toward the center of the screen after a fullscreen using mod-pagedown, and gnome-terminal shrinks toward the upper left corner.

Unfortunately I think I've got to stop messing with it actively today, but I'll let you know if I see any changes.

kjwinchester · 2012-07-19 11:47:54

Thanks for the quick response! I'll give that a try this evening and let you know how it goes.

I did have one more question about the project in general. I see that you are using Xlib rather than XCB, which I understand to be newer and supposedly "better". I have noticed that other WMs like awesome and i3 use XCB, so I expected that it was the library of choice for new development. Is there a reason you stayed with Xlib for a new project other than familiarity?

aerosuidae · 2012-07-19 12:25:43

@mikezackles, ok, thanks for clarifying. I'll certainly keep your report in mind, but all I can really do at this stage is keep a look-out for possible causes because my own test boxes seem happy. If anyone else experiences anything like mikezackles' descriptions, please ping me.

@kjwinchester, yep, I already know the Xlib API and havn't got around to trying XCB But, fwiw, these days the Xlib vs XCB debate is just one about syntax because many distros use XlibXcb to provide Xlib anyway. Look at what I see on Arch:

$ ldd git/goomwwm/goomwwm
        linux-vdso.so.1 (0x00007fffc40b3000)
        libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0x00007f71bf95e000)
        libX11.so.6 => /usr/lib/libX11.so.6 (0x00007f71bf625000)
        libXft.so.2 => /usr/lib/libXft.so.2 (0x00007f71bf410000)
        libc.so.6 => /lib/libc.so.6 (0x00007f71bf06c000)
        libXext.so.6 => /usr/lib/libXext.so.6 (0x00007f71bee59000)
  --->  libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007f71bec3b000)
        libdl.so.2 => /lib/libdl.so.2 (0x00007f71bea37000)
        libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x00007f71be801000)
        libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x00007f71be563000)
        libXrender.so.1 => /usr/lib/libXrender.so.1 (0x00007f71be358000)
        /lib/ld-linux-x86-64.so.2 (0x00007f71bfb61000)
        libXau.so.6 => /usr/lib/libXau.so.6 (0x00007f71be154000)
        libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007f71bdf4e000)
        libz.so.1 => /usr/lib/libz.so.1 (0x00007f71bdd38000)
        libbz2.so.1.0 => /usr/lib/libbz2.so.1.0 (0x00007f71bdb28000)
        libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00007f71bd8fe000)

My goomwwm binary might be speaking Xlib on the client-side but calls to the X server are XCB. Six of one, half a dozen of the other...

mikezackles · 2012-07-19 12:37:58

@mikezackles, ok, thanks for clarifying. I'll certainly keep your report in mind, but all I can really do at this stage is keep a look-out for possible causes because my own test boxes seem happy. If anyone else experiences anything like mikezackles' descriptions, please ping me.

Totally understandable Feel free to ping me if there's ever something specific you'd like me to try.

kjwinchester · 2012-07-19 13:11:13

Thanks, that is nice that XCB is used automatically if its performance is truly better. I guess the only remaining reason to switch would be if the asynchronous nature of XCB could be used to enhance the WM by sending off multiple requests without waiting for them to complete. I haven't looked into the API differences (or the goomwwm code) enough to know if that would make much of a difference. goomwwm is already pretty near instant for all operations that I've tried, so I'm not sure there is much performance left to squeeze out of it!

aerosuidae · 2012-07-19 13:45:07

kjwinchester wrote:

I guess the only remaining reason to switch would be if the asynchronous nature of XCB could be used to enhance the WM by sending off multiple requests without waiting for them to complete.

A valid observation, definitely, and worthy of research. Memory usage is supposed to be a little lower too.

Although, it's worth noting that Xlib has always been asynchronous where it matters, using event queues and such. Sometimes too asynchronous in fact, like with error handling.

I treat goomwwm like this:

Get a feature working with a robust algorithm, no matter how slow it is.
Drop valgrind, callgrind, and kcachegrind on it and look for hot spots.
Figure out if some caching or plain old cheating can relieve the hot spot.
If so, do that and move on.
Otherwise, change the rules in #1.

If none of these steps work, then my algorithm is dodgy and changing the X library is not going to help anyway

bgc1954 · 2012-07-19 15:40:56

@aerosuidae - Yup it was me that had the greyed out windows back at the end of June. I believe you had me try a new git build July 1 and it did indeed solve the problem. And yes, my desktop has an nvidia video card using the newest nvidia-302.17-2 driver.

I just woke up to a new problem that I'm trying to track down but haven't spent too much time on it so far. Everything was fine yesterday and I believe I did a new git build before I shut my computer down so I believe everything was fine as of 20120717. This morning, none of my mod+key combos work? I tried today's git build 20120719-1 but the keyboard is still unresponsive. Ctrl+Alt+Backspace still works so my keyboard is fine and I'm doing this post from i3 at the moment. I'll check with my netbook now and see if it has any problems.

Edit: My netbook is working fine. I won't be able to tell you if the greyed out boxes appear now on nvidia until I get my keyboard working in goomwwm on my desktop. No luck so far.
Edit2: Sorry, aerosuidae, I'm giving up for today. My keyboard works fine with every other wm I have so I don't really know where to look?

Last edited by bgc1954 (2012-07-19 17:53:49)

teateawhy · 2012-07-19 17:30:25

What is the bar in the first screenshot on the left side of the monitor?
Is it part of the goomwwm or can i add it.

bgc1954 · 2012-07-19 19:28:31

@aerosuidae - Well, I couldn't just give up--could I? It turns out that something recent has made it so goomwwm doesn't like the numlock key and that's why my netbook was still ok. I use numlockx in my .xinitrc on my desktop so I can use the number pad in gnucash. As soon as I commented out numlockx, my keyboard responded properly in goomwwm, but as soon as you push the numlock key to use the number pad, your keyboard doesn't respond. IIRC, something like this happened to me while trying stumpwm--or maybe it was musca -- a long time ago. I'm glad I've got goomwwm back on my desktop but I'd sure like the numlock key to work, please.

Edit: Now that I have goomwwm back on my desktop I can report that I still have no greyed out boxes while using nvidia driver.

For some reason, I now have an X for a cursor outside any focused window. I even put xsetroot -cursor_name left_ptr in my .xinitrc, which I never had before, and it doesn't help. My cursor was fine a couple of days ago. Nevermind this last bit. I was using runlevel 3 and startx to see if I could get any clues as to what was happening with my keyboard. As soon as I reverted back to runlevel 5 with xdm I've got my pointer back.

Last edited by bgc1954 (2012-07-19 19:50:08)

aerosuidae · 2012-07-20 00:25:11

@teateawhy, that bar is lxpanel.

@bgc1954, Thanks for tracking that numlock bug down. Based on your report, I found a regression bug introduced around three days ago in the keyboard handler. Fix is committed.

Last edited by aerosuidae (2012-07-20 00:25:21)

kjwinchester · 2012-07-20 01:29:37

@aerosuidae - The monitor rule seems to work great - thanks again!

aerosuidae · 2012-07-20 05:17:06

Today, in the spirit of eating one's own dog food, I spent a while playing with .goomwwmrc. Here it is (less some -ruleset stuff I'm still messing with):

# general stuff
warpmode focus
flashtitle show

# app keys
1 class:kate
2 class:chromium
3 class:konsole
7 class:firefox
8 class:pcmanfm
9 class:pidgin

# dark-theme menu
menuwidth 900
menulines 30
menubg    #222222
menubgalt #1e1e1e
menufg    #bbbbbb
menuhlbg  #005577
menuhlfg  #f0f0f0
menubc    #444444
menufont  droidsansmono-16

# dark-theme titles
titlebg   #222222
titlefg   #f0f0f0
titlebc   #444444
titlefont droidsans-16

# default rules
rule class:xfce4-notifyd ignore
rule class:kate     monitor1,maximize_vert,maximize_horz
rule class:meme     monitor1,right,large,maximize_vert
rule class:chromium monitor2,large,top,expand
rule class:firefox  monitor2,large,top,expand
rule class:pidgin   monitor2,right,bottom,block

# start stuff
auto class:kate
auto class:chromium

exec pgrep pixelclock    || exec pixelclock -size 10 -left
exec pgrep lxpanel       || exec lxpanel
exec pgrep conky         || exec conky
exec pgrep yakuake       || exec yakuake
exec pgrep xfce4-notifyd || exec /usr/lib/xfce4/notifyd/xfce4-notifyd

I'll add it to the tutorial as an example, shortly.

The goomwwm menu, titles, and message boxes have a light theme by default, which is fairly boring but easily readable. Above I've resurrected the dark menu theme some may remember from early goomwwm versions, and tuned it a little more. Now looks like this:

One day I'd like to have a list of .goomwwmrc theme snippets in git that people can grab and apply. Maybe even try to match them to the names of popular gtk/kde themes which many apps will be using. One day...

Last edited by aerosuidae (2012-07-20 05:20:09)

sime · 2012-07-20 09:22:02

Wow, mine amounts to following:

1 xterm
2 xombrero
placement pointer

I'll add to it some more, but not much.

pomhg · 2012-07-20 11:06:17

Hi aerosuidae, nice work!

So far everything is good, something new I have to get used to though.

BTW is there a way to bind any key with any shell command? Such as binding 'XF86AudioRaiseVolume' with 'amixer set Master 5%+'. I didn't find the info in man page.

Procyon · 2012-07-20 11:39:19

@pomhg: use xbindkeys.

pomhg · 2012-07-20 11:56:39

Procyon wrote:

@pomhg: use xbindkeys.

Oops, I totally forgot xbindkeys.

Thanks Procyon.

aerosuidae · 2012-07-20 13:16:45

After some fiddling with -ruleset, I've figured out how to simulate the master/stacking areas of pure tiling WMs, like dwm and friends:

ruleset Master & Stack Right
rule class:.* reset,right,small,maximize_vert
rule class:.* once left,raise,expand
rule edge:right once vtile

ruleset Master & Stack Bottom
rule class:.* reset,bottom,small,maximize_horz
rule class:.* once top,raise,expand
rule edge:bottom once htile

With the latest git version, place the above rulesets in .goomwwmrc, at the end, after any global rules. Open three or more windows in a tag, then use mod-. (period) to execute a new rulesets from the popup menu. Windows should immediately jump into formation. Then, use mod-shift-i,j,k,l to swap windows in and out of the master area

The first ruleset above can generate a layout I had to build manually, earlier in the thread:

screenshot

I think it should be possible to use rulesets for almost any layout, of course not limited to tiling.

Last edited by aerosuidae (2012-07-20 13:18:30)

SanskritFritz · 2012-07-20 14:25:19

Simply amazing, thanks!

bgc1954 · 2012-07-21 15:06:52

Cool, your stacking ruleset works great. I rarely have more than a couple of windows open at a time so goomwwm works great out of the box for me, but it's nice to have the tiling options easily available. And thanks for getting the numlock key working again.

Arch Linux

#126 2012-07-19 00:33:32

Re: goomwwm: Get out of my way, window manager!

#127 2012-07-19 00:54:06

Re: goomwwm: Get out of my way, window manager!

#128 2012-07-19 01:21:28

Re: goomwwm: Get out of my way, window manager!

#129 2012-07-19 01:53:24

Re: goomwwm: Get out of my way, window manager!

#130 2012-07-19 02:34:28

Re: goomwwm: Get out of my way, window manager!

#131 2012-07-19 07:43:00

Re: goomwwm: Get out of my way, window manager!

#132 2012-07-19 11:46:43

Re: goomwwm: Get out of my way, window manager!

#133 2012-07-19 11:47:54

Re: goomwwm: Get out of my way, window manager!

#134 2012-07-19 12:25:43

Re: goomwwm: Get out of my way, window manager!

#135 2012-07-19 12:37:58

Re: goomwwm: Get out of my way, window manager!

#136 2012-07-19 13:11:13

Re: goomwwm: Get out of my way, window manager!

#137 2012-07-19 13:45:07

Re: goomwwm: Get out of my way, window manager!

#138 2012-07-19 15:40:56

Re: goomwwm: Get out of my way, window manager!

#139 2012-07-19 17:30:25

Re: goomwwm: Get out of my way, window manager!

#140 2012-07-19 19:28:31

Re: goomwwm: Get out of my way, window manager!

#141 2012-07-20 00:25:11

Re: goomwwm: Get out of my way, window manager!

#142 2012-07-20 01:29:37

Re: goomwwm: Get out of my way, window manager!

#143 2012-07-20 05:17:06

Re: goomwwm: Get out of my way, window manager!

#144 2012-07-20 09:22:02

Re: goomwwm: Get out of my way, window manager!

#145 2012-07-20 11:06:17

Re: goomwwm: Get out of my way, window manager!

#146 2012-07-20 11:39:19

Re: goomwwm: Get out of my way, window manager!

#147 2012-07-20 11:56:39

Re: goomwwm: Get out of my way, window manager!

#148 2012-07-20 13:16:45

Re: goomwwm: Get out of my way, window manager!

#149 2012-07-20 14:25:19

Re: goomwwm: Get out of my way, window manager!

#150 2012-07-21 15:06:52

Re: goomwwm: Get out of my way, window manager!

Board footer