Hi.
On drw.c, in line #356[1], before we do the font matching, we
call FcConfigSubstitute(3) to (if I understand Xft correctly)
fill system configuration values into our search pattern, and
we call FcDefaultSubstitute(3) to fill some default configuration
it has for things we haven't set yet in t
On Sun, Jan 17, 2021 at 10:58:10AM +, Hritik Vijay wrote:
> > Are there window managers that do NOT behave this way with respect
> > to workspaces?
>
> I've seen i3 handle this case with a i3-exec binary. It basically
> launches the target application and signals the i3wm where it was
> execute
* Eric Pruitt [17.01.2021 07:55]:
Are there window managers that do NOT behave this way with respect to
workspaces?
I remember musca behaving that way, using dmenu. Does anyone remember musca? :-)
> I've seen i3 handle this case with a i3-exec binary. It basically launches
> the target application and signals the i3wm where it was executed. I guess
> something similar could be developed here.
> It could be used as a wrapper inside dmenu launcher.
See wihack (“The wmii window hack”).
On Sunday, January 17, 2021 11:55 AM, Eric Pruitt wrote:
> On Sat, Jan 16, 2021 at 10:13:11PM -0800, Spenser Truex wrote:
>
> > To me this seems like undesirable behaviour, since after opening a
> > program one has to wait for it to load before switching the current tag.
Yes! I'd love this to be
DWM behaves as I expect it to behave. It assigns the tag when the window is
created. Makes sense to me for a window manager. I doubt that a change as you
propose would be easy or simple, but prove me wrong. :>
On Sun, Jan 17, 2021, at 01:13, Spenser Truex wrote:
> To me this seems like undesi
On 21/01/16 10:13, Spenser Truex wrote:
> I can't imagine any way that this is desirable. I will try to patch a
> fix later, seems like low hanging fruit.
I think this should be a patch for dwm, in order to not increase the
complexity of the code. The idea of dwm and suckless programs is s
