bakkeby / dwm-flexipatch

A dwm build with preprocessor directives to decide which patches to include during build time
MIT License
1.18k stars 238 forks source link

stacker + awesomebar #117

Open kronikpillow opened 3 years ago

kronikpillow commented 3 years ago

I'v asked about this once here https://github.com/bakkeby/dwm-flexipatch/issues/75 and you'v told me about awesomebar that if i want to be able to focus hidden windows as well to modify the keybinding for focusstack like this:

You can already do this actually.

The default keybindings for focusstack is as follows:

    { MODKEY,                       XK_j,          focusstack,             {.i = +1 } },
    { MODKEY,                       XK_k,          focusstack,             {.i = -1 } },

If you pass +/- 2 rather than 1 then that will include hidden clients.

    { MODKEY,                       XK_?,          focusstack,             {.i = +2 } },
    { MODKEY,                       XK_?,          focusstack,             {.i = -2 } },

You'll have to decide on appropriate keybindings of course. It is fairly crammed in dwm-flexipatch hence I do not have these included by default.

problem is, with stacker, the focusstack keybinding is removed, and for some reason the stacker patch doesn't cycle the hidden windows even thou there is code for it ...

also when all windows are hidden, and you press the Mod+Control+Z to unhide a hidden window, dwm crashes and restarts

bakkeby commented 3 years ago

Do you have BAR_WINTITLEACTIONS_PATCH enabled?

kronikpillow commented 3 years ago

yes

#define BAR_WINTITLEACTIONS_PATCH 1 BAR_AWESOMEBAR_PATCH || BAR_TABGROUPS_PATCH || BAR_FLEXWINTITLE_PATCH

considering that i'm using only awesomebar of these 3 options, do i need the || BAR_TABGROUPS_PATCH || BAR_FLEXWINTITLE_PATCH part? does it make a difference if removed? as that's what i removed

this is how my line looks like #define BAR_WINTITLEACTIONS_PATCH 1 BAR_AWESOMEBAR_PATCH

bakkeby commented 3 years ago

Ah I forgot about that,

https://github.com/bakkeby/dwm-flexipatch/blob/23c76d13b5376e78c268006da57d132883d5df9b/patches.def.h#L363

You can replace all of that with 1 if you like, the BAR_AWESOMEBAR_PATCH || BAR_TABGROUPS_PATCH || BAR_FLEXWINTITLE_PATCH bit is just to enable wintitle actions automatically if you enable awesomebar, bartabgroups or flexwintitle.

problem is, with stacker, the focusstack keybinding is removed, and for some reason the stacker patch doesn't cycle the hidden windows even thou there is code for it ...

The stacker patch does not actually support cycling through hidden windows. The code you may have seen is to explicitly ignore windows that are hidden.

I would have to have a closer look to work out how to add support for cycling through hidden windows using the stacker patch (without causing any fires or explosions of course).

For now you may want to rename the original focusstack and call that with +/- 2 to cycle through hidden windows. Alternatively you can try changing every instance of #if BAR_WINTITLEACTIONS_PATCH to #if 0 && BAR_WINTITLEACTIONS_PATCH in patch/stacker.c.

also when all windows are hidden, and you press the Mod+Control+Z to unhide a hidden window, dwm crashes and restarts

That is interesting. I am having a hard time replicating this, do you need to do something special to reproduce this crash? Also you may want to sanity check if you also have some other bindings for XK_z that might interfere.

kronikpillow commented 3 years ago

it is possible that the Mod+Ctrl+Z was conflicting with some keybindings and that that is the reason it was crashing, I haven't been using flexipatch for a while, and just now i returned to it .. .I will see if i can replicate it ...

still, i remember that in the beggining (v1.0 of flexipatch) when stacker was enabled in combo with awesomebar, it did cycle hidden windows and I didn't need any special keybindings, renames of patches, or hacks to achieve it, but now that's gone, having a extra set of keybindings just to cycle hidden windows, sounds like a overkill, why not just have it cycle hidden windows by default? "you say that The code you may have seen is to explicitly ignore windows that are hidden." ... so if i remove that code, will stacker then cycle hidden windows?

bakkeby commented 3 years ago

It is pretty unintuitive to let focus drift to hidden windows, so it doesn't make much sense to have that as the default. Users can make it so that it does so by default if they want to. The part of having an extra set of keybindings for this is just if you want both options.

kronikpillow commented 3 years ago

one reason would be to be able to unhide hidden windows, with the keyboard instead of the mouse, considering that it's a keyboard driven window manager :)

bakkeby commented 3 years ago

That would be the only reason.