Re: [dev] hotkey (1) - a suckless global keybinder
Calvin Morrison: > On 9 February 2014 01:07, Chris Down wrote: > > - You are using system(), which is highly unportable and extremely > > fragile; > > I'm not so sure. What's a better solution? http://lubutu.com/code/spawning-in-unix
[dev] [dmenu:stest] [patch] Add an option to reverse matches
>From 23cc463e6e52d0ca975ee077c91f06bb9a2748f0 Mon Sep 17 00:00:00 2001 From: Bastien Dejean Date: Wed, 24 Apr 2013 12:06:52 +0200 Subject: [PATCH] Add an option to select non-matching files --- stest.1 | 3 +++ stest.c | 8 +--- 2 files changed, 8 insertions(+), 3 deletions(-) diff --git a/stest.1 b/stest.1 index bb48f45..18a1ba2 100644 --- a/stest.1 +++ b/stest.1 @@ -67,6 +67,9 @@ Test that files are not empty. .B \-u Test that files have their set-user-ID flag set. .TP +.B \-v +Inverse the sense of matching, to select non-matching files. +.TP .B \-w Test that files are writable. .TP diff --git a/stest.c b/stest.c index e1dcf36..813bd2b 100644 --- a/stest.c +++ b/stest.c @@ -22,7 +22,7 @@ main(int argc, char *argv[]) { DIR *dir; int opt; - while((opt = getopt(argc, argv, "abcdefghln:o:pqrsuwx")) != -1) + while((opt = getopt(argc, argv, "abcdefghln:o:pqrsuwxv")) != -1) switch(opt) { case 'n': /* newer than file */ case 'o': /* older than file */ @@ -59,8 +59,9 @@ main(int argc, char *argv[]) { void test(const char *path, const char *name) { struct stat st, ln; + bool m; - if(!stat(path, &st) && (FLAG('a') || name[0] != '.') /* hidden files */ + m = !stat(path, &st) && (FLAG('a') || name[0] != '.') /* hidden files */ && (!FLAG('b') || S_ISBLK(st.st_mode))/* block special */ && (!FLAG('c') || S_ISCHR(st.st_mode))/* character special */ && (!FLAG('d') || S_ISDIR(st.st_mode))/* directory */ @@ -75,7 +76,8 @@ test(const char *path, const char *name) { && (!FLAG('s') || st.st_size > 0) /* not empty */ && (!FLAG('u') || st.st_mode & S_ISUID) /* set-user-id flag */ && (!FLAG('w') || access(path, W_OK) == 0)/* writable */ - && (!FLAG('x') || access(path, X_OK) == 0)) { /* executable*/ + && (!FLAG('x') || access(path, X_OK) == 0); /* executable*/ + if((!FLAG('v') && m) || (FLAG('v') && !m)) { if(FLAG('q')) exit(0); match = true; -- 1.8.2.1
Re: [dev] [st] New feature idea
Raphaël Proust: > I don't see how sxhkd can deal with $PWD. My bad: I misread you.
Re: [dev] [st] New feature idea
Raphaël Proust: > The problem is: xbindkeysrc has now idea about $PWD so it doesn't work > with relative path. https://github.com/baskerville/sxhkd
Re: [dev] bspwm 0.1
Daniel Pettersson: > On 09/23/2012 12:58 PM, hiro wrote: > >what is that at 1:40 for where suddenly the border is bigger than the window? > a feature Yes, more precisely, the window_gap setting is modified in real-time.
Re: [dev] bspwm 0.1
Hugues Moretto-Viry: > Even if I saw you README and your cast, could you do a little presentation > of it (aim, how many SLOC, ...)? I wanted to write a simple tiling window manager solely based on the concept of BSP with exactly one window per leaf. SLOC count is around 2500.
[dev] bspwm 0.1
Hi, I'm glad to announce the first release of bspwm, a tiling window manager I've been working on for the past two months: https://github.com/baskerville/bspwm Quick screencast: https://vimeo.com/4396 Greetings, -- b.d (| |) ^ ^
Re: [dev] Binary Space Partitioning Window Manager
Nick: > Two potentiial > issues I see: > > - It wouldn't interact too well with tagging. Presumably. Either > whole container nodes and their leaves would have to be assigned > tags, or each tag would have its own tree structure. The former > might actually not be a bad outcome. I'm afraid I don't see how it could support tagging. Having one tree per *desktop* seems to be the only option. > - I can't imagine how the interface would work in a non-annoying > way. How would one choose the container to replace/pair to? Maybe > just doing it on whatever window was focused would be fine. It is how I intend to do it (the '^' character in my ASCII drawings indicates the focused window). Thanks for your feedback, -- b.d (| |) ^ ^
Re: [dev] Binary Space Partitioning Window Manager
Brandon Invergo: > You should look at herbstluftwm as it already imlements a binary tree > method for window management (manual tiling only). I'm actually an herbstluftwm contributor. The problems I have with herbstluftwm's concepts should be easy to deduce from the first message of this thread. Cheers, -- b.d (| |) ^ ^
Re: [dev] Binary Space Partitioning Window Manager
Christoph Lohmann: > What are the practical and productivity gains you expect from such fea‐ > tures? What is your reallife example where such features would be need‐ > ed? Hyphenated plain text is... a catastrophe.
[dev] Binary Space Partitioning Window Manager
Hi, I'm planning on writing a window manager with the following characteristics: - Windows are represented as the leaves of a binary tree. - To each leaf corresponds exactly one window. - The only nodes which can be focused are the leaves. - The leaves are called *window nodes*. - The other nodes are called *container nodes*. - Only two methods of node insertion will be provided: *replace* and *pair*. Example: insertion of a new node (number 4) into the given tree with the *replace* method: b c / \ / \ 3 a --> 4 b ^ / \ ^ / \ 2 1 3 a / \ 2 1 +-+ +-+ ||| ||| || 2 | || 3 | ||| ||| | 3 || --> | 4 || | ^ || | ^ | | | || 1 | || 2 | 1 | ||| || | | +-+ +-+ And with the *pair* method: b b / \ / \ 3 a --> c a ^ / \ / \ / \ 2 1 4 3 2 1 ^ +-+ +-+ ||| ||| || 2 | | 4 | 2 | ||| | ^ || | 3 || --> ||| | ^ || ||| || 1 | | 3 | 1 | ||| ||| +-+ +-+ - Each container node is a split rectangle. - The splitting method of a container node is either *automatic* or *manual*. - In the *automatic* splitting mode, the split type is vertical if the width of the rectangle of the node is greater that its height and horizontal otherwise. - Several tree transformations will be provided: directional leaf swap, node pulling, rotation, contraction, dilatation... Greetings, -- b.d (| |) ^ ^
[dev] [dmenu-hg] stest.c: getopt
Hi, I had to change the CPPFLAGS in config.mk, by appending -D_POSIX_C_SOURCE="2" Otherwise, the build process fails (because of 'getopt'). Greetings, -- b.d (| |) ^ ^
[dev] [haiku] Real World Examples of Bad Error Messages [1]
Dilemma: The project file "e:\ws\foo" may have been modified on disk by the preceding Source Control operation. However, you also have made changes to this project which have not been saved. If you reload the project you will lose your current changes, but if you don't, you risk overwriting the new changes on disk, which is usually much worse. Do you want to reload it now? [Yes] [No] [1] http://api.haiku-os.org/HIG/apas02.html -- b.d (| |) ^ ^
Re: [dev] One Border is Not Enough
Connor Lane Smith: > On 15 January 2012 10:55, Bastien Dejean wrote: > > Solution: add a separation border between the window boundary and the > > focus border. The contrast between the separation border and the focus > > border should be high and constant. My solution is incomplete: a third border is needed to /protect/ the focus border from the outside. Thanks for the references, -- b.d (| |) ^ ^
Re: [dev] One Border is Not Enough
Florian Limberger: > This is more likely a problem of your colorscheme, for example my > active border is #ff9900, which is very unlikely to be the background > color of any window. No: this is more likely a general design problem as stated in my original message. I don't want to choose my active border color based on some design flaw and “very unlikely” is not enough. -- b.d (| |) ^ ^
Re: [dev] One Border is Not Enough
Bjartur Thorlacius: > Just draw the second border on the root window. Will it work with floating windows? -- b.d (| |) ^ ^
[dev] One Border is Not Enough
Hi, There's a problem with the current single border logic of all the minimal tiling X wm I'm aware of: It might happen that the background color of the active window is very close to the color of the active border. In so, the active border become nearly invisible and useless. Solution: add a separation border between the window boundary and the focus border. The contrast between the separation border and the focus border should be high and constant. Cheers, -- b.d (| |) ^ ^
Re: [dev] dmenu-4.5
Connor Lane Smith: > * M-[Gghjkl] restored for vi-like navigation. When lines > 1, I would expect M-j to select the next item (because it's below the current one), but I have to press M-l instead. -- b.d (| |) ^ ^
Re: [dev] [dmenu] No x, y, w options?
Bjartur Thorlacius: > grabbing the whole keyboard rendering it temporarily unusable for > anything but typing text into dmenu or escaping out of it. Yes, it's extremely annoying and alas, it's not just dmenu, many programs have the *input black hole* feature. Cheers, -- Bastien
Re: [dev] [dmenu] No x, y, w options?
Connor Lane Smith: > I also didn't find it at all useful, and some of the code was a bit > ugly. What would be the use case for this? Well, it's useful when one wants to (properly) place dmenu at the optical center of the screen and eventually add some incredibly necessary margins. dmenu's default position make it looks like a status bar. Of course, I'm using a patched x, y, w version. (But I failed to add *inner margins*, any help?) Greetings, -- Bastien
[dev] [dwm] Useless Gaps Are Useful
Hi, In my opinion, the concept of gap between frames should be part of dwm. The existing patches are not solid enough. Having no gaps (the current situation) is just a particular case. Try removing margins from a book: it certainly will destroy readability. Greetings, -- Bastien
[dev] [dmenu] No x, y, w options?
Hi, (Of course I'm referring to the options of the same name already available in dzen2.) Greetings, -- Bastien
Re: [dev] [dwm] [PATCH] spawn_cwd - spawn from current client's cwd
Troels Henriksen a écrit : > Alternative/additional idea: look for the process indicated by the > _NET_WM_PID property, then use the working directory of that process. It seems the value of _NET_WM_PID is not always useful: For urxvtc clients, it is equal to the pid of urxvtd. -- Bastien
[dev] [dmenu] Keyboard Bindings
Hi, Why aren't all the available keyboard bindings documented in the manual? I don't see any word movement bindings. I discovered, by accident, that the following input 'foo bar' is interpreted as the following regex: '.*foo.*bar.*', that's very nice but I'm not sure that it is mentioned in the manual. Greetings, -- Bastien
Re: [dev] [dmenu] Readline Bindings
Connor Lane Smith a écrit : > On 14/11/2011, Bastien Dejean wrote: > > This is only true when the search string is empty which is extremely > > rare: most of the times the first thing the user do is to type a few > > characters to filter the results and hence, the cursor is then at the > > end of the search string, C-f will move down in the search results and > > C-b backward in the search string. > > ... No. So long as you are not on the first item in the list, C-b will > move back through the selected items, regardless of the length of the > input. And so long as the cursor is at the end of the input, C-f will > move forward through the selected items. The cursor basically > continues from where the selector ends. Now I understand what you're trying to do. Since C-b doesn't behave like that in my experience, I wondered what particular option I might be using that you're not: and I though about the number of lines. So... we have a bug: just try with 'dmenu -l 2' or any number > 1. Greetings, -- Bastien
Re: [dev] [dmenu] Readline Bindings
Connor Lane Smith a écrit : > On 14/11/2011, Bastien Dejean wrote: > > Well, suppose you're using C-f to move down in the list of matches, then > > you want to move up, you hit C-b because it's the natural symmetric of > > C-f and you end up moving the cursor backward in the search string. > > No, if you're part-way through the results and you hit C-b you just > move back through the results. Only if you cannot go back do you begin > to move the cursor; dmenu is a menu first, an input field second. (And > C-n / C-p don't move the cursor at all.) This is only true when the search string is empty which is extremely rare: most of the times the first thing the user do is to type a few characters to filter the results and hence, the cursor is then at the end of the search string, C-f will move down in the search results and C-b backward in the search string. Cheers, -- Bastien
Re: [dev] [dmenu] Readline Bindings
Connor Lane Smith a écrit : > On 14/11/2011, Bastien Dejean wrote: > > C-w is not extremely useful as it considers that anything except > > 'space' is a word character. > > I actually find this more useful. A lot of implementations zip through > all your non-alnum symbols when you hit C-w, which I just find > irritating. I happen to use dmenu to move image files around from within sxiv and, in this context, I found the default C-w behavior to be inappropriate. > > I find the behavior of C-f and C-b to be counter intuitive in the > > 'fallthrough' cases. > > Why do you find it counterintuitive? I find it very intuitive. :p Well, suppose you're using C-f to move down in the list of matches, then you want to move up, you hit C-b because it's the natural symmetric of C-f and you end up moving the cursor backward in the search string. Greetings, -- Bastien
[dev] [dmenu] Readline Bindings
Hi, A few problems with the current 'readline' bindings: C-w is not extremely useful as it considers that anything except 'space' is a word character. #| That's now the default bash behavior and it can be overcome by appending the following lines to your .inputrc: set bind-tty-special-chars off C-w: backward-kill-word |# I find the behavior of C-f and C-b to be counter intuitive in the 'fallthrough' cases. Besides, 'C-p' and 'C-n' are inverted: case XK_n: ksym = XK_Up;break; case XK_p: ksym = XK_Down; break; Has a vim style path completion (C-x C-f) been considered? Greetings, -- Bastien
Re: [dev] Focusing on windows by name
Manolo Martínez a écrit : > Is using xdotool's search option slower or otherwise > worse than this? I can't tell. > (btw, i'm not sure I know what lsw is) http://tools.suckless.org/lsw Greetings, -- Bastien
Re: [dev] Focusing on windows by name
Patrick Haller a écrit : > On 2011-10-26 11:48, Manolo Martínez wrote: > > > > In openbox I have a key bound to the following:"wmctrl -xa mutt || > > urxvt -name mutt -e mutt" > > xlsclients | grep -q mutt || urxvt -e mutt No, this is not equivalent because the following command: wmctrl -xa mutt activates the first client matching the given 'title'. You could rather do: #! /bin/sh wid=$(lsw -l | grep -m 1 "$@" | cut -d ' ' -f 1) if [ -n "$wid" ]; then xdotool windowactivate "$wid" else case "$@" in mutt) urxvt -title mutt -e mutt;; MOC) urxvt -e mocp;; *) echo "don't know how to raise '$@'" >&2 exit 1;; esac fi
Re: [dev] List of tools for a CLI environment
mikshaw a écrit : > What about > ls /usr/{,local}/bin ls /usr{,/local}/bin
Re: [dev] Simple made Easy (Rich Hickey at StrangeLoop)
b...@methodlogic.net a écrit : > Is there a downloadable version of this, or something that I can point > mplayer to? Flashplayer == fail for me. rtmpdump -r 'rtmpe://video.infoq.com/cfx/st/presentations/11-sep-simplemadeeasy.mp4' -o simple_made_easy.mp4
Re: [dev] hidcur: Utility for hiding the mouse cursor in X11
Rob a écrit : > I find unclutter sometimes locks my focus to a window, I try to shift focus > (dwm), it just jumps back. You probably need to launch unclutter with the -noevents option. -- Bastien
[dev] [dwm] Rotate the list of clients
Hi, Is there any patch to rotate the list of clients? E.g. 0 becomes 1, 1 becomes 2, ..., n - 1 becomes 0. (Same principle in the opposite direction.) Sayonara, -- Bastien
Re: [dev] [dwm] Crazy Window Behavior
Bogdan Ionuț a écrit : > > > I can bet that it's uselessgap patch related. > > Indeed. > > Is there a rock solid version of that patch floating around? > Try the patch attached. In fact, I'm using this vesion. To fix the aforementioned problem I had to change this line: unsigned int gap = c->isfloating ? 0 : c->mon->lt[c->mon->sellt]->addgaps ? gappx : 0; to: unsigned int gap = (c->isfloating || !c->mon->lt[c->mon->sellt]->arrange) ? 0 : c->mon->lt[c->mon->sellt]->addgaps ? gappx : 0;
Re: [dev] [dwm] Crazy Window Behavior
Bogdan Ionuț a écrit : > On Mon, Sep 5, 2011 at 17:10, Bastien Dejean wrote: > > don't know if it's a known bug, but I stumble upon this crazy window > > behavior happening in floating layout. > > > > In the following video, I try to move and resize the window, then I hit > > MODKEY+space which is bound, in my config.h, to togglefloating, at this > > > I can bet that it's uselessgap patch related. Indeed. Is there a rock solid version of that patch floating around? -- Bastien
[dev] [dwm] Crazy Window Behavior
Hi, I don't know if it's a known bug, but I stumble upon this crazy window behavior happening in floating layout. In the following video, I try to move and resize the window, then I hit MODKEY+space which is bound, in my config.h, to togglefloating, at this point I can move and resize the window normally, then I hit MODKEY+space again and the window the craziness reappears: http://cl.ly/9tnu Cheers, -- Bastien
[dev] [lsw] List only visible windows
Hi, Maybe it would be convenient to add an option similar to the --onlyvisible's xdotool option. Cheers, -- Bastien
[dev] [dmenu] An x, y, w patch for dmenu 4.4
https://bbs.archlinux.org/viewtopic.php?id=124915 diff -u dmenu-4.4/dmenu.1 dmenu/dmenu.1 --- dmenu-4.4/dmenu.1 2011-07-19 22:31:28.0 +0200 +++ dmenu/dmenu.1 2011-08-06 23:18:20.0 +0200 @@ -41,6 +41,9 @@ .B \-b dmenu appears at the bottom of the screen. .TP +.B \-q +dmenu will not show any items if the search string is empty. +.TP .B \-f dmenu grabs the keyboard before reading stdin. This is faster, but may lock up X if stdin is from a terminal. @@ -57,6 +60,15 @@ .BI \-fn " font" defines the font or font set used. .TP +.BI \-x " xoffset" +defines the offset from the left border of the screen. +.TP +.BI \-y " yoffset" +defines the offset from the top border of the screen. +.TP +.BI \-w " width" +defines the desired menu window width. +.TP .BI \-nb " color" defines the normal background color. .IR #RGB , diff -u dmenu-4.4/dmenu.c dmenu/dmenu.c --- dmenu-4.4/dmenu.c 2011-07-19 22:31:28.0 +0200 +++ dmenu/dmenu.c 2011-08-06 23:17:53.0 +0200 @@ -42,6 +42,9 @@ static int bh, mw, mh; static int inputw, promptw; static int lines = 0; +static int xoffset = 0; +static int yoffset = 0; +static int width = 0; static size_t cursor = 0; static const char *font = NULL; static const char *prompt = NULL; @@ -53,6 +56,7 @@ static unsigned long selcol[ColLast]; static Atom utf8; static Bool topbar = True; +static Bool quiet = False; static DC *dc; static Item *items = NULL; static Item *matches, *matchend; @@ -75,6 +79,8 @@ } else if(!strcmp(argv[i], "-b")) topbar = False; + else if(!strcmp(argv[i], "-q")) + quiet = True; else if(!strcmp(argv[i], "-f")) fast = True; else if(!strcmp(argv[i], "-i")) { @@ -84,6 +90,12 @@ else if(i+1 == argc) usage(); /* double flags */ + else if(!strcmp(argv[i], "-x")) + xoffset = atoi(argv[++i]); + else if(!strcmp(argv[i], "-y")) + yoffset = atoi(argv[++i]); + else if(!strcmp(argv[i], "-w")) + width = atoi(argv[++i]); else if(!strcmp(argv[i], "-l")) lines = atoi(argv[++i]); else if(!strcmp(argv[i], "-p")) @@ -177,28 +189,30 @@ if((curpos = textnw(dc, text, cursor) + dc->h/2 - 2) < dc->w) drawrect(dc, curpos, 2, 1, dc->h - 4, True, FG(dc, normcol)); - if(lines > 0) { - dc->w = mw - dc->x; - for(item = curr; item != next; item = item->right) { - dc->y += dc->h; - drawtext(dc, item->text, (item == sel) ? selcol : normcol); - } - } - else if(matches) { - dc->x += inputw; - dc->w = textw(dc, "<"); - if(curr->left) - drawtext(dc, "<", normcol); - for(item = curr; item != next; item = item->right) { - dc->x += dc->w; - dc->w = MIN(textw(dc, item->text), mw - dc->x - textw(dc, ">")); - drawtext(dc, item->text, (item == sel) ? selcol : normcol); - } - dc->w = textw(dc, ">"); - dc->x = mw - dc->w; - if(next) - drawtext(dc, ">", normcol); - } +if(!quiet || strlen(text) > 0) { +if(lines > 0) { +dc->w = mw - dc->x; +for(item = curr; item != next; item = item->right) { +dc->y += dc->h; +drawtext(dc, item->text, (item == sel) ? selcol : normcol); +} +} +else if(matches) { +dc->x += inputw; +dc->w = textw(dc, "<"); +if(curr->left) +drawtext(dc, "<", normcol); +for(item = curr; item != next; item = item->right) { +dc->x += dc->w; +dc->w = MIN(textw(dc, item->text), mw - dc->x - textw(dc, ">")); +drawtext(dc, item->text, (item == sel) ? selcol : normcol); +} +dc->w = textw(dc, ">"); +dc->x = mw - dc->w; +if(next) +drawtext(dc, ">", normcol); +} +} mapdc(dc, win, mw, mh); } @@ -501,7 +515,7 @@ if(INRECT(x, y, info[i].x_org, info[i].y_org, info[i].width, info[i].height)) break; x = info[i].x_org; - y = info[i].y_org + (topbar ? 0 : info[i].height - mh); + y = info[i].y_org + (topbar ? yoffset : info[i].height - mh - yoffset); mw = info[i].width; XFree(info); } @@ -509,9 +523,13 @@ #endif { x = 0; - y = topbar ? 0 : DisplayHeight(dc->dpy, screen) - mh; +
Re: [dev] [dwm] Handling Function Keys
Bryan Bennett a écrit : > You can also just use the raw keycode over the XF86 mapping and you wouldn't > need to include the separate header. I've been doing this since ~5.6. I was using NULL instead of 0 in the /modifier/ column of the /keys/ array. My bad. -- Bastien
[dev] [dwm] Handling Function Keys
Hi, I'm using a keyboard with extra function keys and since those keys are not defined in keysym.h, I inserted the following line in dwm.c: #include It works, but it produces warnings: warning: initialization makes integer from pointer without a cast How can I get rid of those warnings? -- Bastien
Re: [dev] [dwm] scrot -s fails
Steven Blatchford a écrit : > An IRC discussion on Jul 03, 2011 suggested to use 'import'. What is the equivalent in import to the -s argument in scrot? -- Bastien
[dev] [dwm] scrot -s fails
Hi, The following command don't work (i.e. I can't select the region of the screen I'm willing to capture) when it's spawn from dwm: static const char *partialshotcmd[] = { "scrot", "-s", NULL }; Any idea why? -- Bastien
[dev] [dwm] Setting Initial Geometry for Floating Windows
Hi, Is there any patch to make dwm handles a ruled based user specified initial geometry for floating windows? Thanks, -- Bastien
[dev] [dwm] Fullscreen Layout
Hi, Any idea on how to implement a fullscreen layout? Cheers, -- Bastien
Re: Re: [dev] [dwm] xev's window refuses to float
Eckehard Berns a écrit : > Dwm doesn't seem to apply rules to clients without a class hint. > A fix could be something like this: > > 8<---8<--- > [...] > 8<---8<--- Indeed, thanks. -- Bastien
[dev] [dwm] xev's window refuses to float
Hi, I have included the following line in the rules array of my config.h : { NULL, NULL,"Event Tester", 0,True, -1 }, But I don't get the expected result (xev's window stays tiled). Thanks, -- Bastien
[dev] [dmenu] a patch for the bloated quiet option
diff -u dmenu-4.4/dmenu.1 dmenu-quiet-4.4/dmenu.1 --- dmenu-4.4/dmenu.1 2011-07-19 22:31:28.0 +0200 +++ dmenu-quiet-4.4/dmenu.1 2011-08-05 19:39:31.0 +0200 @@ -41,6 +41,9 @@ .B \-b dmenu appears at the bottom of the screen. .TP +.B \-q +dmenu will not show any items if the search string is empty. +.TP .B \-f dmenu grabs the keyboard before reading stdin. This is faster, but may lock up X if stdin is from a terminal. diff -u dmenu-4.4/dmenu.c dmenu-quiet-4.4/dmenu.c --- dmenu-4.4/dmenu.c 2011-07-19 22:31:28.0 +0200 +++ dmenu-quiet-4.4/dmenu.c 2011-08-05 19:39:31.0 +0200 @@ -53,6 +53,7 @@ static unsigned long selcol[ColLast]; static Atom utf8; static Bool topbar = True; +static Bool quiet = False; static DC *dc; static Item *items = NULL; static Item *matches, *matchend; @@ -75,6 +76,8 @@ } else if(!strcmp(argv[i], "-b")) topbar = False; + else if(!strcmp(argv[i], "-q")) + quiet = True; else if(!strcmp(argv[i], "-f")) fast = True; else if(!strcmp(argv[i], "-i")) { @@ -177,28 +180,30 @@ if((curpos = textnw(dc, text, cursor) + dc->h/2 - 2) < dc->w) drawrect(dc, curpos, 2, 1, dc->h - 4, True, FG(dc, normcol)); - if(lines > 0) { - dc->w = mw - dc->x; - for(item = curr; item != next; item = item->right) { - dc->y += dc->h; - drawtext(dc, item->text, (item == sel) ? selcol : normcol); - } - } - else if(matches) { - dc->x += inputw; - dc->w = textw(dc, "<"); - if(curr->left) - drawtext(dc, "<", normcol); - for(item = curr; item != next; item = item->right) { - dc->x += dc->w; - dc->w = MIN(textw(dc, item->text), mw - dc->x - textw(dc, ">")); - drawtext(dc, item->text, (item == sel) ? selcol : normcol); - } - dc->w = textw(dc, ">"); - dc->x = mw - dc->w; - if(next) - drawtext(dc, ">", normcol); - } +if(!quiet || strlen(text) > 0) { +if(lines > 0) { +dc->w = mw - dc->x; +for(item = curr; item != next; item = item->right) { +dc->y += dc->h; +drawtext(dc, item->text, (item == sel) ? selcol : normcol); +} +} +else if(matches) { +dc->x += inputw; +dc->w = textw(dc, "<"); +if(curr->left) +drawtext(dc, "<", normcol); +for(item = curr; item != next; item = item->right) { +dc->x += dc->w; +dc->w = MIN(textw(dc, item->text), mw - dc->x - textw(dc, ">")); +drawtext(dc, item->text, (item == sel) ? selcol : normcol); +} +dc->w = textw(dc, ">"); +dc->x = mw - dc->w; +if(next) +drawtext(dc, ">", normcol); +} +} mapdc(dc, win, mw, mh); } @@ -532,7 +537,7 @@ void usage(void) { - fputs("usage: dmenu [-b] [-f] [-i] [-l lines] [-p prompt] [-fn font]\n" + fputs("usage: dmenu [-b] [-q] [-f] [-i] [-l lines] [-p prompt] [-fn font]\n" " [-nb color] [-nf color] [-sb color] [-sf color] [-v]\n", stderr); exit(EXIT_FAILURE); }
Re: [dev] [dmenu] Hide matching items if the search string is empty
Petr Sabata a écrit : > You could add yet another bloat option for this and use that in dmenu_run. I don't want to see the names of the first executables (in alphabetical order) among all the executables found on my path every time I launch a program through dmenu_run. So, yes, I'm gonna bloat the boat and I hope it won't sink. -- Bastien
[dev] [dmenu] Hide matching items if the search string is empty
Hi, I noticed that when dmenu is used as a program launcher (i.e. through dmenu_run) the initial display of all the items of stdin is kind of annoying. I'd prefer that the matching items appear only when a non empty search string exists. -- Bastien