goomwwm: Get out of my way, window manager!

aerosuidae · 2012-07-21 15:34:20

Someone here asked about having a way to hide all windows not in the current tag, and I didn't want to do it. But, the same request has arrived by email several times since, therefore I'm capitulating so I can stop writing the same email response

In the latest git revision, mod-o shows only the windows in the current tag, hiding everything else. All new code so treat with care and watch for bugs.

sime · 2012-07-21 17:05:13

Mod-w stopped working for me. Titles show up fine in popup window switcher, however.

aerosuidae · 2012-07-22 01:41:10

@sime, thanks. Bug fix committed.

aerosuidae · 2012-07-22 02:46:18

I've tagged 1.0-rc1 and started a non-git package: https://aur.archlinux.org/packages.php?ID=61093

Release candidate functionality will stay as defined right now on the manual page. Bug fixes only.

Last edited by aerosuidae (2012-07-22 02:46:29)

aerosuidae · 2012-07-22 05:49:33

@mikezackles, that full screen issue: Are you using a compositor like xcompmgr?

I've been testing with xcompmgr today which works fine with goomwwm for the most part. But, when resizing a window to fullscreen, then back down, it loses its border and stops refreshing until I resize it once more. Sound like what you were seeing?

ma · 2012-07-22 07:23:47

aerosuidae wrote:

In the latest git revision, mod-o shows only the windows in the current tag, hiding everything else. All new code so treat with care and watch for bugs.

Nice! Now, if only there was an option to do this automatically when switching tags… ;-)

ma · 2012-07-22 07:40:36

Looks like a bug: For transient windows, goomwwm does not take into account the space reserved at the edge of the screen. I opened the preferences window from a small Thunar window placed against the bottom edge, and it ended up below my conky panel.

aerosuidae · 2012-07-22 08:22:29

@ma, interesting. There was indeed a transient window centering bug, which I've now fixed.

But, some testing here shows that the Thunar preferences window is not a true transient window and appears to be specifically calculating and requesting co-ordinates that center it over the main window...

In this case I'm not quite sure what to do. Windows under panels is quite legal; after all we can drag windows there. Should windows be allowed to initially display under panels? What about if a window saves and restores its position and the user specifically placed it there?

Last edited by aerosuidae (2012-07-22 08:23:14)

ma · 2012-07-22 10:03:42

@aerosuidae: Wow, that's more complicated than I thought. And, yeah, I can see now: Thunar's Preferences window does not have WM_TRANSIENT_FOR set, so it was a bad example, sorry. The Open Location window has that property set, and while it may still map itself in reserved space, at least it appears on top.

Anyway, I do not think it makes much sense to disregard the reserved space, especially if normal windows end up obscured by a panel/dock/whatever-that-reserves-space. It's one thing to drag windows there, and quite another to map them there (even if they just restore their saved position). When I open a window, I definitely want it to be visible; I do not want to move it and/or raise it to make it so.

Or maybe I'm just used to the way Openbox works. So, for example, Thunar's dialog windows never open extending into the screen margin, and while Sylpheed can restore the position of its window at startup, Openbox adjusts it if necessary.

sime · 2012-07-22 10:50:32

I don't use dmenu with goomwwm, I don't even have it installed. I use number keys for launching few apps and invoke others via xterm when needed.

It would be nice if window switcher served dual purpose. Since it already allows entering text for narrowing down window choices, I think it would be great if it allowed launching apps too, if entered text doesn't match any already opened windows. Just a thought.

aerosuidae · 2012-07-22 13:09:21

ma wrote:

When I open a window, I definitely want it to be visible; I do not want to move it and/or raise it to make it so.

Yes, I agree. Bug, then.

sime wrote:

It would be nice if window switcher served dual purpose. Since it already allows entering text for narrowing down window choices, I think it would be great if it allowed launching apps too, if entered text doesn't match any already opened windows.

My initial thought was: "install dmenu already" But, I had a coffee and I can see your idea makes sense for a certain type of work habit.

I personally never open the switcher unless to find a window I know is already open. But, if I was in the habit of using the switcher to remember whether a window is open, and it turns out not to be, then having to close the switcher and start a launcher instead would be annoying.

Since I've tagged an RC, and most people do just install their preferred launcher (no offence), this is a feature that I'll leave until after v1.0. I'll definitely keep it on the list though.

chneukirchen · 2012-07-22 16:29:08

ma wrote:

aerosuidae wrote:
In the latest git revision, mod-o shows only the windows in the current tag, hiding everything else. All new code so treat with care and watch for bugs.
Nice! Now, if only there was an option to do this automatically when switching tags… ;-)

I approve this.

ismaelvc · 2012-07-22 17:33:03

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.

I'm interested in this option, but upon reinstall from git I don't have this functionality nor the dark theme, just recompiled a while ago, thanks!

You are doing an awesome job, but I still don't get how to use tags, I think awesome way is more convenient for me, but still goomwwm idea is superb, can't wait for it to mature even more!

mikezackles · 2012-07-22 17:42:08

@mikezackles, that full screen issue: Are you using a compositor like xcompmgr?

Duh, I knew I forgot to mention something important. Yes, I am using xcompmgr -- in xmonad I make all my inactive windows slightly transparent instead of using borders.

sime · 2012-07-22 18:15:49

Minimized windows are no longer listed in window switcher.

aerosuidae · 2012-07-23 00:54:34

ismaelvc wrote:

I'm interested in this option, but upon reinstall from git I don't have this functionality nor the dark theme, just recompiled a while ago, thanks!

To see cycling in action, open one full screen window, then two xterms the same size and position. Use mod-h to tile the xterms. Then use mod-c to cycle. You should find that the xterms only ever raise as a pair.

The dark theme was just a snippet for .goomwwmrc. It's not part of the code.

mikezackles wrote:

Duh, I knew I forgot to mention something important. Yes, I am using xcompmgr -- in xmonad I make all my inactive windows slightly transparent instead of using borders.

Both xcompmgr and compton seem to stumble when a window has its border removed then reapplied. For compton, running in X synchronous mode with -S fixes the problem, which makes me suspect it has a race condition somewhere.

cairo-compmgr seems to work ok, though it has some window alignment glitches, even with the silly shadows turned off.

sime wrote:

Minimized windows are no longer listed in window switcher.

Thank you. Bug fix committed.

aerosuidae · 2012-07-23 01:04:26

chneukirchen wrote:

ma wrote:
Nice! Now, if only there was an option to do this automatically when switching tags… ;-)
I approve this.

You're all hecklers!

I suppose adding an option to turn on already existing functionality wouldn't be breaking my RC rule too much... As you may have guessed, having the formal RC is meant to stop me wildly adding new features and breaking stuff.

Edit: See -onlyauto in git.

Last edited by aerosuidae (2012-07-23 01:15:54)

sime · 2012-07-23 12:14:59

TITLEBC and MENUBC are the same in goomwwm.h and yet border color differs in flash title and window switcher. I prefer the lighter one as in the switcher.

bgc1954 · 2012-07-23 15:14:08

Seems I stumbled upon a little bug. I was using goomwwm-1.0-rc1 and this AM doing some work in gnucash. When I closed the window, my keyboard became unresponsive to goomwwm key commands. Ctrl+Alt+Backspace still worked to exit goomwwm so the keyboard is still fine. I was able to use modkey+close to close the window but once gnucash quits, no keyboard response. I switched to goomwwm-git and it has the same problem. It seemed to work once or twice with git when I was testing it but now it's showing consistant behavior of gnucash killing the keyboard for goomwwm. I don't have to enter anything into gnucash, just open and close it and the goomwwm keys don't work.

aerosuidae · 2012-07-23 15:54:32

@sime, thanks, bug fix comitted.

@bgc1954, odd problem there. A quick test with gnucash here doesn't show the behaviour, so we'll have to look deeper. Some ideas:

Does this occur on both your desktop and netbook?
Does the problem occur if you use gnucash's File > Quit?
Double check your num/scroll/caps lock keys; to my knowledge these should not affect goomwwm key binding now, but who knows...
If you close gnucash and Ctrl-Alt-2 out to another tty without killing X, then check the process list: is gnucash process definitely gone?
How about goomwwm process? Still running? Not using 100% cpu or anything?

dublindan · 2012-07-23 17:17:53

Hi,

Love the tiling ruleset - very cool and a good starting point to experimenting more with rulesets. Awesome!

I like mod-o as well, but I'm wondering if there's a way to show all windows again? If not, that's my next feature request (post 1.0 I guess..): show all.

Mapping AltGr does not work for me. If I map, eg, í to grow ( "grow mod4-mod5-iacute", though "grow mod5-iacute" doesn't work either) then pressing mod4-mod5-e prints out é and pressing mod4-mod5-i doesn't print anything but also doesn't grow the window... that is, the key event does seem to be handled by goomwwm and not passed to the focused application, but it doesn't trigger the mapped command for me.

Finally, I just did a git pull and rebuilt (after not having updated since late last week) and now it seems that mod-h/v doesn't work for me anymore.. any ideas??

EDIT: mod-shift-i/j/k/l seems to no longer work for me either, although it was working perfectly previously... don't think there's anything in my setup that has changed...

EDIT 2: seems mod-shift-i/j/k/l does work with ijkl but not with the keys I bound to use instead (unei) though this did work before. Are these mapped independently now and I just didn't notice or is it a bug?

Last edited by dublindan (2012-07-23 18:13:43)

aerosuidae · 2012-07-24 02:03:18

@dublindan

I'm a little unsure how to proceed with the AltGr debugging, short of buying a such a keyboard on ebay and experimenting with different maps... which I may just do sometime anyway

One possibility: If you're feeling bold, you could try looking at grab.c > grab_key(). In there I did something a little experimental that may also be plain wrong in some situations; see the comment on walking the keycode map. You could try removing everything after the comment and see if you get better behaviour from your key bindings.

mod-shift-i/j/k/l now have their own config options, in case people want to bind them separately from the focus keys. See -snapleft and similar.

I think you're referring to the split behaviour of mod-h/v that triggered when no other windows were available to tile. This was removed to allow predictable h/v tiling for use in rules where unknown numbers of windows would be in play. As a consolation prize, one can now resize in finer increments with mod-shift-pageup/down. I have some other tiling ideas that I'll explore shortly, once 1.0 is stable, and h/v splitting features again there. So it's not gone, just on hiatus for a while until it can be done a little more elegantly

Last edited by aerosuidae (2012-07-24 02:04:35)

aerosuidae · 2012-07-24 02:07:47

dublindan wrote:

I like mod-o as well, but I'm wondering if there's a way to show all windows again? If not, that's my next feature request (post 1.0 I guess..): show all.

Oops, missed this one. Feature request noted.

Last edited by aerosuidae (2012-07-24 02:08:00)

ma · 2012-07-24 08:37:24

dublindan wrote:

Mapping AltGr does not work for me. If I map, eg, í to grow ( "grow mod4-mod5-iacute", though "grow mod5-iacute" doesn't work either) then pressing mod4-mod5-e prints out é and pressing mod4-mod5-i doesn't print anything but also doesn't grow the window... that is, the key event does seem to be handled by goomwwm and not passed to the focused application, but it doesn't trigger the mapped command for me.

Have you tried mapping to the base symbol instead of the final shifted one? So if í is produced by pressing AltGr+i, then mod4-mod5-i should work.

@aerosuidae: Thanks for -onlyauto! And one more question: Is goomwwm supposed to work with non-ASCII text? Right now it can not display it; the text gets truncated at the first non-ASCII character.

aerosuidae · 2012-07-24 11:24:22

@ma, thanks, that was a character set bug. A fix is committed which should suit ISO8859-1. I was trying to go straight to UTF-8 support originally but that was the cause of this bug and will have to wait.

Arch Linux

#151 2012-07-21 15:34:20

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

#152 2012-07-21 17:05:13

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

#153 2012-07-22 01:41:10

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

#154 2012-07-22 02:46:18

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

#155 2012-07-22 05:49:33

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

#156 2012-07-22 07:23:47

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

#157 2012-07-22 07:40:36

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

#158 2012-07-22 08:22:29

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

#159 2012-07-22 10:03:42

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

#160 2012-07-22 10:50:32

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

#161 2012-07-22 13:09:21

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

#162 2012-07-22 16:29:08

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

#163 2012-07-22 17:33:03

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

#164 2012-07-22 17:42:08

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

#165 2012-07-22 18:15:49

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

#166 2012-07-23 00:54:34

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

#167 2012-07-23 01:04:26

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

#168 2012-07-23 12:14:59

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

#169 2012-07-23 15:14:08

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

#170 2012-07-23 15:54:32

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

#171 2012-07-23 17:17:53

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

#172 2012-07-24 02:03:18

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

#173 2012-07-24 02:07:47

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

#174 2012-07-24 08:37:24

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

#175 2012-07-24 11:24:22

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

Board footer