Re: [dev] [surf] [PATCH] A typo in SETPROP macro: should be ``printf '', not ``printf''.
Greetings. On Sat, 30 Mar 2013 06:50:26 +0100 Alexander Sedov wrote: > --- > I'm sorry I introduced this bug. > > config.def.h |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) The patch is applied. Sincerely, Christoph Lohmann
Re: [dev] [st] New feature idea
On Fri, Mar 29, 2013 at 6:58 PM, Christoph Lohmann <2...@r-36.net> wrote: > Greetings. > > On Fri, 29 Mar 2013 19:58:39 +0100 Raphaël Proust wrote: >> On Fri, Mar 29, 2013 at 6:36 PM, Calvin Morrison >> wrote: >> > On 29 March 2013 14:31, Nick wrote: >> >> […] >> > >> > While I find many of those features useless, some of them are plain >> > cool, and are innovative. Why are we stuck with a text terminal when >> > we aren't using a tty most of the time? Sure simple text modes should >> > always be supported but additional features are cool. I'd love to be >> > able do an easy ls and be able to see my picture previews, why not? >> > It' s not terribly complicated and it sure is useful. >> >> >> I also like the idea of not having a pure-text interaction with the >> computer, but Terminology is definitely pushing things too far. It's >> hard to have a good middle ground. >> >> Alternatively, you could set up plumber and have your terminal be as >> smart as acme: left-click on a .jpg/png/gif/whatever opens an image >> viewer. It separates the two concept (ls and preview) and is dead >> simple. Bonus points: because the two concepts are separate, you can >> have the plumbing rules independent of your terminal so you can set up >> different dispatching easily. > > That’s what I do, too. For now this is a script run on Mod + o in dwm, > which does some regexp parsing on the string and calls sxiv and surf‐ > open.sh accordingly. Anywhere on the intertubes where this script can be found? > > It would be nice to have some project to gather interesting regexp > parsers and opener scripts that make the suckless life more efficient. > > What are you guys using as a plumber in daily work? I sometime run the actual plumber (from plan9port) (whenever I'm in acme). Otherwise, my Mod+o is bound (via xbindkeys) to surf. (I haven't bothered setting up a full plumbing, but I probably should. And will.) -- __ Raphaël Proust
[dev] [surf] [PATCH] A typo in SETPROP macro: should be ``printf %b'', not ``printf''.
---
I'm sorry I introduced this bug.
config.def.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/config.def.h b/config.def.h
index 3ddfaf8..ed8fbbe 100644
--- a/config.def.h
+++ b/config.def.h
@@ -23,7 +23,7 @@ static Bool hidebackground = FALSE;
#define SETPROP(p, q) { \
.v = (char *[]){ "/bin/sh", "-c", \
- "prop=\"`xprop -id $2 $0 | cut -d '\"' -f 2 | xargs -0 printf |
dmenu`\" &&" \
+ "prop=\"`xprop -id $2 $0 | cut -d '\"' -f 2 | xargs -0 printf
%b | dmenu`\" &&" \
"xprop -id $2 -f $1 8s -set $1 \"$prop\"", \
p, q, winid, NULL \
} \
--
1.7.10.4
Re: [dev] [st] New feature idea
On 29/03/2013, Calvin Morrison wrote: > See opening images is not the same as having images on your buffer, namely > for the reason > of being able to look back in your buffer and see the images that have been > opened > > say I wanted all my photos in my collection from 2012, 3rd month, for > me this is now trivial, plus > I can easily scroll up and down my buffer to look at them. but st has no scrollback buffer.
Re: [dev] [st] New feature idea
On Fri, Mar 29, 2013 at 07:58:39PM +0100, Christoph Lohmann wrote: > What are you guys using as a plumber in daily work? A simple shell script with several lines of "grep -q && exec", with the most commonly used at the top. Previously, I had a system that reordered the entries based on frequency of use, but it had a bug, and it doesn't actually matter, so I got back to work. With tab-completion, I rarely need the plumber for anything but web links, as typing an image viewer command is much faster than fetching the mouse to highlight text. --Andrew Hills
Re: [dev] [st] New feature idea
On 29 March 2013 14:54, Raphaël Proust wrote: > On Fri, Mar 29, 2013 at 6:36 PM, Calvin Morrison > wrote: >> On 29 March 2013 14:31, Nick wrote: >>> […] >> >> While I find many of those features useless, some of them are plain >> cool, and are innovative. Why are we stuck with a text terminal when >> we aren't using a tty most of the time? Sure simple text modes should >> always be supported but additional features are cool. I'd love to be >> able do an easy ls and be able to see my picture previews, why not? >> It' s not terribly complicated and it sure is useful. > > > I also like the idea of not having a pure-text interaction with the > computer, but Terminology is definitely pushing things too far. It's > hard to have a good middle ground. > > Alternatively, you could set up plumber and have your terminal be as > smart as acme: left-click on a .jpg/png/gif/whatever opens an image > viewer. It separates the two concept (ls and preview) and is dead > simple. Bonus points: because the two concepts are separate, you can > have the plumbing rules independent of your terminal so you can set up > different dispatching easily. I'm actually really liking my idea I suggested earlier, having some time to think about it. It's an awesome idea in fact. See opening images is not the same as having images on your buffer, namely for the reason of being able to look back in your buffer and see the images that have been opened, plus it makes piping things very easy and doing image searching in a much easier fashion than using GUI's say I wanted all my photos in my collection from 2012, 3rd month, for me this is now trivial, plus I can easily scroll up and down my buffer to look at them. preview `find 2012-03*.jpg` | less Images are very useful for humans, but GUI's are not, I want an amalgam of images and text on my terminal Calvin
Re: [dev] [st] New feature idea
Greetings. On Fri, 29 Mar 2013 19:58:39 +0100 Raphaël Proust wrote: > On Fri, Mar 29, 2013 at 6:36 PM, Calvin Morrison > wrote: > > On 29 March 2013 14:31, Nick wrote: > >> […] > > > > While I find many of those features useless, some of them are plain > > cool, and are innovative. Why are we stuck with a text terminal when > > we aren't using a tty most of the time? Sure simple text modes should > > always be supported but additional features are cool. I'd love to be > > able do an easy ls and be able to see my picture previews, why not? > > It' s not terribly complicated and it sure is useful. > > > I also like the idea of not having a pure-text interaction with the > computer, but Terminology is definitely pushing things too far. It's > hard to have a good middle ground. > > Alternatively, you could set up plumber and have your terminal be as > smart as acme: left-click on a .jpg/png/gif/whatever opens an image > viewer. It separates the two concept (ls and preview) and is dead > simple. Bonus points: because the two concepts are separate, you can > have the plumbing rules independent of your terminal so you can set up > different dispatching easily. That’s what I do, too. For now this is a script run on Mod + o in dwm, which does some regexp parsing on the string and calls sxiv and surf‐ open.sh accordingly. It would be nice to have some project to gather interesting regexp parsers and opener scripts that make the suckless life more efficient. What are you guys using as a plumber in daily work? Sincerely, Christoph Lohmann
Re: [dev] [st] New feature idea
On Fri, Mar 29, 2013 at 6:36 PM, Calvin Morrison wrote: > On 29 March 2013 14:31, Nick wrote: >> […] > > While I find many of those features useless, some of them are plain > cool, and are innovative. Why are we stuck with a text terminal when > we aren't using a tty most of the time? Sure simple text modes should > always be supported but additional features are cool. I'd love to be > able do an easy ls and be able to see my picture previews, why not? > It' s not terribly complicated and it sure is useful. I also like the idea of not having a pure-text interaction with the computer, but Terminology is definitely pushing things too far. It's hard to have a good middle ground. Alternatively, you could set up plumber and have your terminal be as smart as acme: left-click on a .jpg/png/gif/whatever opens an image viewer. It separates the two concept (ls and preview) and is dead simple. Bonus points: because the two concepts are separate, you can have the plumbing rules independent of your terminal so you can set up different dispatching easily. -- __ Raphaël Proust
Re: [dev] [st] New feature idea
Greetings. On Fri, 29 Mar 2013 19:45:54 +0100 Calvin Morrison wrote: > On 29 March 2013 14:31, Nick wrote: > > So I came across Enlightenment's "Terminology" terminal emulator > > today, and they have many features we don't. > > > > I recommend skimming the ibPziLRGvkg youtube video. > > > > How long before we can set videos as the background to our > > terminals? I find modern life is definitely not distracting enough, > > and what I really want is to type white text onto a background of a > > moving snowscape. > > > > Christoph, is this something you're working on yet? Or is the plan > > still just the boring "make stuff work well" agenda? The agenda hasn’t changed yet. Maybe some money will help in changing my ideology. But I’m not religious. > While I find many of those features useless, some of them are plain > cool, and are innovative. Why are we stuck with a text terminal when > we aren't using a tty most of the time? Sure simple text modes should > always be supported but additional features are cool. I'd love to be > able do an easy ls and be able to see my picture previews, why not? > It' s not terribly complicated and it sure is useful. > > It doesn't follow the unix philosophy to have an embedded version of > ls, but it would make sense to be able to print an image to stdout, > using some escape-chars to start the block of data and to close it. > > It's definitely not all good, but that is how innovation is, some good > features will stick and most will fall into nothingness. What you want is not a vt100 emulation. The vt100 emulation is a differ‐ ent environment from what you want. I don’t think raping vt100 to sup‐ port those images is a good idea. If you see the timeline, then HTML is the successor of the terminals and it is going to support 3D games soon [0]. It’s not very efficient, solid and the cause of global warming, but it made this whole OS mess a bit more simpler by having one interface for everything. Of course using the web is like winning a war by burning your own motherland. > I'm still waiting for duke nukem... Duke Nukem Forever has been released a while ago [1]. Sincerely, Christoph Lohmann [0] http://blog.mozilla.org/blog/2013/03/27/mozilla-is-unlocking-the-power-of-the-web-as-a-platform-for-gaming/ [1] http://www.dukenukemforever.com/full/de/
Re: [dev] [dwm] [patch] allow no tags to be selected
On Fri, Mar 29, 2013 at 5:48 PM, Markus Teich wrote: > Heyho, > > i like my wallpapers, so i created a patch to allow no tag at all to be > selected. Also i found it kind of unintuitive that you can not toggle > the last tag out of view. > The attached patch (for v6.0) fixes that. Makes sense to me too. > dwm starts with no tag selected instead of the first tag beeing selected. > When no tag is selected and you start a client with no tagrule, it gets > opened in the first tag. > The patch should(!) be stable, i used it for a whole month without > problems now. > Do you think it is worth adding to the wiki? Yes. > > --Markus -- __ Raphaël Proust
[dev] [st] st 0.4 release
Greetings comrades, many changes have arrived in the st repository and it is time to release st 0.4. Thanks to all of the contributors of patches and suggestions! Please adapt your config.h to the config.def.h, because much has changed. Please update your terminfo of st too; there much has changed too. Changes and Features: * Rectangular selection * Reverse mode colors now work correctly * License change to MIT/X * New escape sequences: DECOM, VPR, SRM * The key[] array in config.h now has many more modes and supports more controversies in vt terminal history and is the main reason for the size increase of the st binary. * St now has support for up to the F35 key, which is a gimmick, but allows to define special keys per applications, which are then correctly sent by st. * Now st does send '\r' instead of '\n' in selection. This will fix many cases of not working selection. * Numlock handling can be toggled. * Standout is now reverse in terminfo, which makes BSD games work in st. * Xdbe has been removed. St now works in Xinerama again, but as fast as using Xdbe. * Back Color Erase has been implemented. This is a modern feature of terminals, but creates glitches on meta-terminals like tmux. There simply using the TERM=xterm will fix this by not assuming BCE commands. * The st title can now include UTF-8 and umlaut characters. * There is now an fps setting to regulate the CPU usage of st. It can be adapted for future time continuum changes and if humanity evolves in its time sensors. * Xterm palette swap support. * CSI parsing is now implemented. * Default colors for italic and underline can now be defined to have some extra highlighting. * The »primary« and the »clipboard« clipboard have shortcuts. The release file: http://dl.suckless.org/st/st-0.4.tar.gz Don’t forget to only report bugs against the git repository. Coporate laziness will not be tolerated. Sincerely, Christoph Lohmann
Re: [dev] [st] Crash on OpenBSD i386 with vim/mutt
Greetings. On Fri, 29 Mar 2013 19:08:21 +0100 haris wrote: > Hi @ all. First mail in this list and I'd like to thank the dev team for > all those quality suckless solutions. :) > > I'm having the following problem with st: when opening mutt, it > completely crashes. With vim/vi, it happens randomly. > > I'm on -current OpenBSD i386, builded on 12 Feb. Please retry with current from git, if this persists. Sincerely, Christoph Lohmann
Re: [dev] [st] Usage experience and patches
Greeting.s On Fri, 29 Mar 2013 19:02:40 +0100 stargr...@stargrave.org wrote: > * I very like to see italic strings more visible by colorizing them. > Italics are generated by grep, Ack, less, git diff (at least on my > computer). So > 0001-Highlight-italic-string-with-different-color-default.patch > is based on http://st.suckless.org/patches/boldcolor and do just > italics color highlighting. > * 0002-Missing-Ctrl-PgUp-PgDown-key-sequences.patch adds Ctrl-PgUp and > Ctrl-PgDown sequences. I used them to switch tabs inside tmux, so they > were necessarily at least for me. > * 0003-Missing-Shift-PageUp-key-sequence.patch adds Shift-PgUp sequence. > Shift-PgDown was already defined here, but PgUp now. Your patches were applied in a modified way to the st mainline. Thanks for the input. Sincerely, Christoph Lohmann
Re: [dev] [st] New feature idea
On 29 March 2013 14:31, Nick wrote: > So I came across Enlightenment's "Terminology" terminal emulator > today, and they have many features we don't. > > I recommend skimming the ibPziLRGvkg youtube video. > > How long before we can set videos as the background to our > terminals? I find modern life is definitely not distracting enough, > and what I really want is to type white text onto a background of a > moving snowscape. > > Christoph, is this something you're working on yet? Or is the plan > still just the boring "make stuff work well" agenda? > While I find many of those features useless, some of them are plain cool, and are innovative. Why are we stuck with a text terminal when we aren't using a tty most of the time? Sure simple text modes should always be supported but additional features are cool. I'd love to be able do an easy ls and be able to see my picture previews, why not? It' s not terribly complicated and it sure is useful. It doesn't follow the unix philosophy to have an embedded version of ls, but it would make sense to be able to print an image to stdout, using some escape-chars to start the block of data and to close it. It's definitely not all good, but that is how innovation is, some good features will stick and most will fall into nothingness. I'm still waiting for duke nukem... Calvin
[dev] [st] New feature idea
So I came across Enlightenment's "Terminology" terminal emulator today, and they have many features we don't. I recommend skimming the ibPziLRGvkg youtube video. How long before we can set videos as the background to our terminals? I find modern life is definitely not distracting enough, and what I really want is to type white text onto a background of a moving snowscape. Christoph, is this something you're working on yet? Or is the plan still just the boring "make stuff work well" agenda?
[dev] [dwm] [patch] allow no tags to be selected
Heyho,
i like my wallpapers, so i created a patch to allow no tag at all to be
selected. Also i found it kind of unintuitive that you can not toggle
the last tag out of view.
The attached patch (for v6.0) fixes that.
dwm starts with no tag selected instead of the first tag beeing selected.
When no tag is selected and you start a client with no tagrule, it gets
opened in the first tag.
The patch should(!) be stable, i used it for a whole month without
problems now.
Do you think it is worth adding to the wiki?
--Markus
>From b94b2ed03a635e8f1a62ebf968d996310ff7fa0b Mon Sep 17 00:00:00 2001
From: Markus Teich
Date: Fri, 29 Mar 2013 18:35:32 +0100
Subject: [PATCH] allow no tags to be selected
---
dwm.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/dwm.c b/dwm.c
index 1d78655..a526e57 100644
--- a/dwm.c
+++ b/dwm.c
@@ -322,7 +322,9 @@ applyrules(Client *c) {
XFree(ch.res_class);
if(ch.res_name)
XFree(ch.res_name);
- c->tags = c->tags & TAGMASK ? c->tags & TAGMASK : c->mon->tagset[c->mon->seltags];
+ if(c->tags & TAGMASK)c->tags = c->tags & TAGMASK;
+ else if(c->mon->tagset[c->mon->seltags]) c->tags = c->mon->tagset[c->mon->seltags];
+ else c->tags = 1;
}
Bool
@@ -649,7 +651,7 @@ createmon(void) {
if(!(m = (Monitor *)calloc(1, sizeof(Monitor
die("fatal: could not malloc() %u bytes\n", sizeof(Monitor));
- m->tagset[0] = m->tagset[1] = 1;
+ m->tagset[0] = m->tagset[1] = 0;
m->mfact = mfact;
m->nmaster = nmaster;
m->showbar = showbar;
@@ -1479,7 +1481,7 @@ sendmon(Client *c, Monitor *m) {
detach(c);
detachstack(c);
c->mon = m;
- c->tags = m->tagset[m->seltags]; /* assign tags of target monitor */
+ c->tags = (m->tagset[m->seltags] ? m->tagset[m->seltags] : 1);
attach(c);
attachstack(c);
focus(NULL);
@@ -1763,12 +1765,9 @@ toggletag(const Arg *arg) {
void
toggleview(const Arg *arg) {
unsigned int newtagset = selmon->tagset[selmon->seltags] ^ (arg->ui & TAGMASK);
-
- if(newtagset) {
- selmon->tagset[selmon->seltags] = newtagset;
- focus(NULL);
- arrange(selmon);
- }
+ selmon->tagset[selmon->seltags] = newtagset;
+ focus(NULL);
+ arrange(selmon);
}
void
@@ -2043,7 +2042,7 @@ updatewmhints(Client *c) {
void
view(const Arg *arg) {
- if((arg->ui & TAGMASK) == selmon->tagset[selmon->seltags])
+ if(arg->ui && (arg->ui & TAGMASK) == selmon->tagset[selmon->seltags])
return;
selmon->seltags ^= 1; /* toggle sel tagset */
if(arg->ui & TAGMASK)
--
1.8.2
RE: [dev] [DWM] Patch: stack mfact
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 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 + > >> 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 > >> 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 > >> >
RE: [dev] [DWM] Patch: stack mfact
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 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 + > >> 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 > >> 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 > >> >
Re: [dev] [DWM] Patch: stack mfact
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 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 + >> 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 >> 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 >>
