Hi there, have a look at applyresizehints(), it is a side-effect of the treatment if the height or width becomes smaller than bh (bar height).
HTH, Anselm On 29 March 2013 17:15, Jente Hidskes <jthids...@outlook.com> wrote: > Stock DWM makes a new client float if there is too little space in the > stack. In this case, the new client appears floating in the top left of your > screen, right under the statusbar. I would like to have a client move there, > should we want to resize it too small. Does anyone know where the code is > that makes a new client float top left of the monitor? > > I was thinking it was in manage(), under /* geometry */, but I'm unsure. > > > ________________________________ > From: jthids...@outlook.com > To: dev@suckless.org > Subject: RE: [dev] [DWM] Patch: stack mfact > Date: Fri, 29 Mar 2013 16:38:02 +0100 > > > Hey Brian, > > Indeed, I use pertag2 myself. It's an easy fix though, glad you got it > working. We could get the floating clients in front of the stack by having a > call to XRaiseWindow under c->isfloating = True. > > >> From: bbenn...@gmail.com >> Date: Fri, 29 Mar 2013 09:06:28 -0400 >> Subject: Re: [dev] [DWM] Patch: stack mfact >> To: dev@suckless.org >> >> Jente / Unia - >> I just had a go at applying this, but it appears that it expects >> pertag (or something else) to also be applied. I'll respond shortly >> when I've removed that. >> Changing all instances of "selmon->smfacts[selmon->curtag]" to >> "selmon->mfact" made this apply just fine. >> >> Opening a bunch of st windows didn't result in a crash, but the >> floated windows do get pushed behind the rest of the stack. This isn't >> a problem for me at all, but it might confuse some. (Then again...stop >> pulling 30+ windows into view >_>) >> >> On Thu, Mar 28, 2013 at 12:43 PM, Jente Hidskes <jthids...@outlook.com> >> wrote: >> > Hm, seems like there was still a crash in the previous version which I >> > also >> > forgot to actually attach. I do think this is the cleanest way to >> > circumvent >> > the crashing. Let me know what you think! >> > >> > >> > ________________________________ >> > From: jthids...@outlook.com >> > To: dev@suckless.org >> > Subject: RE: [dev] [DWM] Patch: stack mfact >> > Date: Thu, 28 Mar 2013 15:25:12 +0100 >> > >> > >> > I just noticed that if we open too much clients in a vanilla dwm.c, they >> > will be floating by default. This could be the best way to handle this. >> > Attached is the patch that does just that: if(h < minwsz) then float. >> > minwsz >> > should be declared in config.h, like so: >> > >> > static const unsigned int minwsz = 10; /* Minimal heigt of a >> > client for smfact */ >> > >> > Let me know what you think of this approach! >> > >> > >> > ________________________________ >> > From: jthids...@outlook.com >> > To: dev@suckless.org >> > Subject: RE: [dev] [DWM] Patch: stack mfact >> > Date: Thu, 28 Mar 2013 15:13:37 +0100 >> > >> > I went ahead and tried hiding the client a la deck layout when its >> > height is >> > getting too small. It doesn't work. Are there any other ideas? I could >> > just >> > add another if line to setsmfact, which will set smfact's limit even >> > lower >> > when there is more than 30 clients. >> > >> > I tried disabling html email, but I can't find anything in the settings. >> > I'll do a search later today to see if I missed something. Sorry guys! >> > >> >> Date: Thu, 28 Mar 2013 13:21:42 +0000 >> >> Subject: Re: [dev] [DWM] Patch: stack mfact >> >> From: raphla...@gmail.com >> >> To: dev@suckless.org >> >> >> >> On Thu, Mar 28, 2013 at 1:01 PM, Jente Hidskes <jthids...@outlook.com> >> >> wrote: >> >> > I meant that once we would resize clients too much (which causes the >> >> > crash) >> >> > we could simply 'hide' them 'underneath' the stack, like the deck >> >> > layout >> >> > does. Could you elaborate on the nstack approach? I'm not fully >> >> > understanding where you're coming from. >> >> >> >> The approach of hiding the clients that would cause the crash is a good >> >> idea. >> >> >> >> The approach with nstack would be to have a variable somewhere that >> >> indicates >> >> the maximal number of clients that can be shown in the stack area. Thus >> >> one >> >> would set this limit in their conf.h (and possibly a couple of entries >> >> in >> >> their key array to tweak the value) and when the number of clients in >> >> the >> >> stack area grows over nstack, the additional ones would simply not be >> >> shown. >> >> Like your deck approach but with a custom number of clients rather than >> >> just >> >> one. >> >> >> >> >> >> Cheers, >> >> -- >> >> ______________ >> >> Raphaël Proust >> >> >>