Re: [dev] [dwm] default window attaching behaviour
On Wed, Dec 01, 2021 at 12:26:22AM +1000, dther wrote: > and only launch new "temporary" terminals when I need to run and see > the output of a command. If I need an TUI volume mixer or something, > I'd launch it as a tmux window or in floating mode to avoid disturbing > my layout. Hi, You should consider using a "scratchpad" for this purpose. There's a couple scratchpad patches it in the wiki. I personally didn't like them though, I don't remember why exactly but it had something to do with messing up my tag-based workflow. - NRK
Re: [dev] [dwm] default window attaching behaviour
Hi,
> My tendency is to launch a few "big" programs, most of which can't
> easily run in a terminal (a browser, a terminal running tmux and/or an
> image editor), and only launch new "temporary" terminals when I need
> to run and see the output of a command. If I need an TUI volume mixer
> or something, I'd launch it as a tmux window or in floating mode to
> avoid disturbing my layout.
I do something pretty similar with dwm, under the (usually correct)
assumptions that windows made earlier stick around for less time. I
found I really like unilaterally opening windows floating and centered
by default and then popping them into the tiled layout if I need them to
stick around. It's a pretty simple modification, but I've attached the
patch I use just in case you or anyone on this list would find it helpful!
--
lincoln auster
they/them
From 10f3e8380ee4d1c8acbf7f2da97a47dada93f03e Mon Sep 17 00:00:00 2001
From: elm auster
Date: Thu, 16 Sep 2021 21:51:40 -0600
Subject: [PATCH] center and float windows by default
---
dwm.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/dwm.c b/dwm.c
index 5e4d494..77dea02 100644
--- a/dwm.c
+++ b/dwm.c
@@ -286,7 +286,7 @@ applyrules(Client *c)
XClassHint ch = { NULL, NULL };
/* rule matching */
- c->isfloating = 0;
+ c->isfloating = 1;
c->tags = 0;
XGetClassHint(dpy, c->win, );
class= ch.res_class ? ch.res_class : broken;
@@ -1040,11 +1040,13 @@ manage(Window w, XWindowAttributes *wa)
applyrules(c);
}
- if (c->x + WIDTH(c) > c->mon->mx + c->mon->mw)
- c->x = c->mon->mx + c->mon->mw - WIDTH(c);
- if (c->y + HEIGHT(c) > c->mon->my + c->mon->mh)
- c->y = c->mon->my + c->mon->mh - HEIGHT(c);
+ /* center the window */
+ c->x = c->mon->mx + c->mon->mw / 2 - c->w / 2;
+ c->y = c->mon->my + c->mon->mh / 2 - c->h / 2;
+
c->x = MAX(c->x, c->mon->mx);
+ c->y = MAX(c->y, c->mon->my);
+
/* only fix client y-offset, if the client center might cover the bar */
c->y = MAX(c->y, ((c->mon->by == c->mon->my) && (c->x + (c->w / 2) >=
c->mon->wx)
&& (c->x + (c->w / 2) < c->mon->wx + c->mon->ww)) ? bh :
c->mon->my);
--
2.31.1
Re: [dev] [dwm] default window attaching behaviour
On 21/11/29 01:23PM, Mateusz Okulus wrote: > On 21/11/29 06:25PM, dther wrote: > > I've been thinking about dwm's default behaviours, ,,, > > As you say you launch new programs as you need them. This means the > launched program should have highest priority because you want to use it > right now. <...> > so you want to open it, do something with it, then close it. I see- I'd made an assumption here that I now realise doesn't apply to all users. My tendency is to launch a few "big" programs, most of which can't easily run in a terminal (a browser, a terminal running tmux and/or an image editor), and only launch new "temporary" terminals when I need to run and see the output of a command. If I need an TUI volume mixer or something, I'd launch it as a tmux window or in floating mode to avoid disturbing my layout. > I'm not quite sure what do you mean by displacing the entire stack. > <...> > This might be confusing, but only if you open the window for later use. Realised this is my personal preference- since most of my windows are long running, I find it useful for them to occupy the same visual area at all times, in case I need to look at them for reference. > You'd need to be more specific about your use cases. > <...> If my assumptions are correct, I'd reconsider if you really need that > many programs opened in one view. I'd split programs between tags and > use solutions like tmux or built-in windows. You're probably right, honestly. My windows are tagged by "purpose" (e.g. document paging, editing, etc), and rather than using them like workspaces, I use a heavily modified version of the old workspaces patch, with each "workspace" being like its own dwm instance. I'm realising now that my ad-hoc tmux implementation is hiding the fact that I'm using way too many windows at once. Thanks for the explanation. Made me rethink how I use my windows, and that I could probably do with a major rework of my dwm instance. > All that being said, it was probably just for consistency. You'd > expect new windows to go on the top of the stack, not the bottom. > Whether it'd be better for most workflows probably wasn't even > considered. This makes sense ._.
Re: [dev] [dwm] default window attaching behaviour
On 21/11/29 06:25PM, dther wrote: > I've been thinking about dwm's default behaviours, and one of them > that's always confused me is how newly attached windows, by default, > launch as the "master". Why is this the case? Intuitively, when I begin > working, I launch the most important program first, and launch new > programs as I need them. I'd imagine at least 50% of people follow this > strategy of launching new windows as well. In general, older windows > are more "important". Why displace not only the master client, > but the *entire stack*, for the window least likely to remain useful? > > I realise that this is a problem that can be easily solved with a patch > (and, in fact, I use attachbelow for this reason), but given how common > (I imagine) the above strategy is, my question is- > would it be reasonable for dwm's master branch include some way to toggle > an alternative "attachbottom" strategy? > > I'd also like to know if I'm correct about my assumptions. > Do give thoughts if your "window initialisation" > thought process is completely different from mine. As you say you launch new programs as you need them. This means the launched program should have highest priority because you want to use it right now. Older windows are more long lived and important, but in the moment you want your attention on the new window. It'll be probably a short lived one too, so you want to open it, do something with it, then close it. I'm not quite sure what do you mean by displacing the entire stack. I'd assume you mean the fact that windows are displayed from to bottom of the stack, so when you add a new windows all windows shift by one place. This might be confusing, but only if you open the window for later use. You'd need to be more specific about your use cases. The way I use it is to launch long lived windows first, and then when I need to change volume or change music I have a hotkey that opens a terminal with appropriate program. I want it to be the master, so I can make some quick changes and close it, and get back to what I was doing. If it launched at the bottom I'd need to switch to it, make it fullscreen or new master manually and shortly after close it. If you mean instead the process of initial initialization of several long lived programs then attaching to bottom might be helpful. If I wanted to have a terminal with vim and some other application always opened I'd probably do it in this order and then I'd need to swap them. I personally treat tags as workspaces and rarely have more than one window per tag. I prefer to use tmux, vim windows etc. If I didn't use tmux, I'd need to have ~6 terminals opened in one "workspace". I'd probably open them from first to last, but then dwm would place them from last to first. It would probably get annoying quickly, and I'd switch it as you did. If I wanted to launch a short lived program I wouldn't have a problem with additional key chord to go from master to last window. Even with a bigger screen I'd probably need to make it a new master or fullscreen it, but it wouldn't be so bad, if done rarely. I'd guess most people don't start that many windows per view, so the benefit of new programs being new masters outweighs the reversed order when launching many programs at once initially. If my assumptions are correct, I'd reconsider if you really need that many programs opened in one view. I'd split programs between tags and use solutions like tmux or built-in windows. All that being said, it was probably just for consistency. You'd expect new windows to go on the top of the stack, not the bottom. Whether it'd be better for most workflows probably wasn't even considered. Regards, mokulus signature.asc Description: PGP signature
[dev] [dwm] default window attaching behaviour
I've been thinking about dwm's default behaviours, and one of them that's always confused me is how newly attached windows, by default, launch as the "master". Why is this the case? Intuitively, when I begin working, I launch the most important program first, and launch new programs as I need them. I'd imagine at least 50% of people follow this strategy of launching new windows as well. In general, older windows are more "important". Why displace not only the master client, but the *entire stack*, for the window least likely to remain useful? I realise that this is a problem that can be easily solved with a patch (and, in fact, I use attachbelow for this reason), but given how common (I imagine) the above strategy is, my question is- would it be reasonable for dwm's master branch include some way to toggle an alternative "attachbottom" strategy? I'd also like to know if I'm correct about my assumptions. Do give thoughts if your "window initialisation" thought process is completely different from mine.
