Re: [dev] [dwm] Focus bug in 5.6 when using unclutter
On Mon, Aug 03, 2009 at 09:56:40AM +0100, Anselm R Garbe wrote: > Hi Eivind, > > thanks for your investigation. I looked through the code and > remembered that unfocus() sets the input focus to the root window in > order that clients are notified with FocusOut (in terminals this has > the effect that the cursor turns into unfocused state). > > So in general there is nothing wrong with setting the input focus to > the root window during unfocus() -- that's also usual practice in > other WM implementations. I suspect there is a side-effect with > unclutter though, haven't looked at its code, but it surely must do > some nasty trick to void the cursor, which might have some side-effect > if it receives FocusIn on the root window, which is why I propose to > look at unclutter next, since I bet the real fix is on that side... ;) > > But let's see. > > Kind regards, > Anselm > > > 2009/8/3 Eivind Uggedal : > > After updating from 5.5 to 5.6 I encountered a bug relating to unclutter[1]. > > Steps to reproduse: > > > > 1. Start dwm 5.6 with default config and unclutter with default params. > > 2. Open more than one window in the active tag. > > 3. Wait until unclutter hides the cursor. > > 4. Switch to a window not focused by the previously visible cursor using the > > keyboard. > > 5. The window border will start flickering (looking like it gets unfocused > > and focused rapidly in succession). > > 6. The cursor will also start to flicker. > > 7. Using the keboard to focus the window the cursor was focusing when > > visible will stop the flickering. Moving the cursor (so that unclutter > > displays it again) will also stop the flicker until unclutter hides it > > again. > > > > This bug was introduced in changeset 1418 37e3b2a40f6f [2]. The problem is > > that XSetInputFocus is called through the unfocus() function from focus(). > > As I'm not familiar with Xlib I'm not sure how to fix this bug, but I've > > been able to pinpoint the erroneous code and disable the XSetInputFocus call > > when unfocus() is called from focus(). > > > > I've attached a patch against changeset 1477 aefd753cfe9b which does exactly > > this. Note that this was made just to highlight which code path triggers the > > described behavior and is not meant as a patch for fixing the bug. > > > > [1]: http://www.ibiblio.org/pub/X11/contrib/utilities/unclutter-8.README > > [2]: http://code.suckless.org/hg/dwm/rev/37e3b2a40f6f > > > > -- > > Cheers, > > Eivind Uggedal > > > Have you looked at the man page for unclutter? There is an option (-noevents or some such thing) that makes unclutter not send any X11 signals. This should fix your bug.
Re: [dev] dmenu : auto confirm when only one item remains
On Wed, Aug 12, 2009 at 08:39:41PM +0200, Julien Steinhauser wrote: > Hello, > Sorry, I don't write to bring a patch. > I wander if someone has already patched dwm > to make it auto confirm when, (as said in the subject) > only one item remains. > > I've found something on the mailing list which is almost > what I wish but not exactly, it auto confirms on exact match. > > It could be something like : > > if number of Item == 1 or if firstItem == lastItem > > fprintf(stdout, "%s", text); > fflush(stdout); > running = False; > > As I'm not a developper, I miss the knowledge > to write the if condition in real code. > > This feature would be handy for a few scripts in which I use dmenu. > If someone has already done it or have ideas on how to do it, please let > me know :) . > Why not check if the number of items you are passing into dmenu is one and use that instead of making dmenu do the check? It seems to me pointless to call dmenu with only one value in stdin. -- Regards, Colin 'Evaryont' Shea
Re: [dev] [surf] next release
On Wed, Oct 21, 2009 at 1:08 PM, Dieter Plaetinck wrote: > On Wed, 21 Oct 2009 11:04:48 -0400 (EDT) > Peter John Hartman wrote: > > > > > > > On Wed, 21 Oct 2009, Anselm R Garbe wrote: > > > > > 2009/10/21 pancake : > > >> I always use shift+insert or middleclick for pasting, what's the > > >> unix way to paste? > > >> ^p is already supported in surf, and mozilla load pages if you > > >> paste them in the > > >> web canvas...so which is the 'correct' one? :) > > >> > > >> And yeah i didn't mention ^C^V because I never use them and can > > >> break other keybindings of the underlying app. Like the > > >> unix-editing for textentries on gtk > > >> apps, because ^W is the default keybinding for closing windows on > > >> Gnome apps. > > > > > > In dmenu we don't need to worry about other apps, because dmenu > > > grabs the keyboard and during the time until ungrabbing it we can > > > override any key combination we like. That's why I propose having a > > > Key interface in dmenu like in dwm that can be used to execute a > > > command to insert at current text position and good is. I prefer ^p > > > to Shift-Insert by default. > > > > > > Kind regards, > > > Anselm > > > > > > > Ctl-p is fine by me as long as it is established in config.h (i.e.\ > > as long as the user has an easy chance at over-riding it). > > > > Peter > > > > what about commandline flags? dmenu --bind ^p /path/to/script.sh --bind > shift-insert /path/to/other-script.sh > > i like the general idea, though i'm not sure if it's worth the hassle > (bloat?). > > Dieter > > A config.h approach seems best here, dmenu already does that for defaults and it could be inconsistent if the calling app chose demnu's bindings rather than dmenu choosing for itself.
Re: [dev] [dmenu] Putting key combinations in config.h
On Wed, Oct 21, 2009 at 1:15 PM, Peter John Hartman < peterjohnhart...@gmail.com> wrote: > Hi, > > In light of the parallel discussion re surf and dmenu, I thought I'd open > up > the following suggestion: Can we put the various keybindings used in dmenu > in config.h rather than dmenu.c? There is one case where I know this will > prove useful, namely, the keybinding to close dmenu, which currently is > XK_Escape. I launch dmenu with a keybinding to Shift_R and I like to be > able to close dmenu with the same keystroke, i.e.\ Shift_R. But more > generally most other suckless apps have the keybindings in config.h, so why > not dmenu? > > Yours, > Peter > > And I already posted to the previous discussion before reading this, great. As I stated, it would be better than a parameter passed to dmenu on the command line. While it would be excessive, could it also be possible to have the keybindings change the options available, not the input? Thinking something along the line of a dmenu-based clone of Google's Suggestions feature. Being able to type something then have dynamic results, rather than static. This would be a lot more complex I'd bet than what Anselm suggested.
Re: [dev] [dmenu] Putting key combinations in config.h
On Wed, Oct 21, 2009 at 2:48 PM, Peter John Hartman < peterjohnhart...@gmail.com> wrote: > > > On Wed, 21 Oct 2009, Colin Shea wrote: > > On Wed, Oct 21, 2009 at 1:15 PM, Peter John Hartman < >> peterjohnhart...@gmail.com> wrote: >> Hi, >> >> In light of the parallel discussion re surf and dmenu, I thought I'd >> open up >> the following suggestion: Can we put the various keybindings used in >> dmenu >> in config.h rather than dmenu.c? There is one case where I know this >> will >> prove useful, namely, the keybinding to close dmenu, which currently >> is >> XK_Escape. I launch dmenu with a keybinding to Shift_R and I like to >> be >> able to close dmenu with the same keystroke, i.e.\ Shift_R. But more >> generally most other suckless apps have the keybindings in config.h, >> so why >> not dmenu? >> >> Yours, >> Peter >> >> >> And I already posted to the previous discussion before reading this, >> great. >> >> As I stated, it would be better than a parameter passed to dmenu on the >> command line. >> >> While it would be excessive, could it also be possible to have the >> keybindings change the options available, not the input? Thinking >> something along the line of a dmenu-based clone of Google's >> Suggestions feature. Being able to type something then have dynamic >> results, rather than static. This would be a lot more complex I'd bet than >> what Anselm suggested. >> >> >> > Hi, > > 1. I'm glad we agree on the config.h vs. argument-from-commandline vs. > dmenu.c question. > > 2. I don't understand the subsequent request, although I've never used > "Google's Suggestions" either. What do you have in mind? > > Peter I don't know if Google enabled it for everyone, but if you log into your Google Account then start searching, it will provide possible completions of your search term. So if you typed "do" into the search box, the first option in the drop down would be "dog", but if you then typed "w" instead of selecting it, it would return "down", etc. It also ties in with your previous search history, so with "com" computer would rate higher than complete, for instance.
Re: [dev] [dmenu] Putting key combinations in config.h
On Wed, Oct 21, 2009 at 18:55, Peter John Hartman < peterjohnhart...@gmail.com> wrote: > I guess not! We agree at least on the first part: that it should be in > /either/ dmenu.c or config.h and not passed to it from the commandline. > Fair enough. > > Dwm is a very personal program which everyone tailors to his needs. >> Here configurable shortcuts are of much value and do not conflict much >> with other users/different systems. >> >> Dmenu, on the other hand, is a quite generic program which sould be the >> same everywhere. If people start configuring the key strokes, one needs >> different dmenus for different users on one system. Also, one may not be >> able to use dmenu on a different machine. That's to avoid, for sure. >> > > [snip] > > Dmenu should be seen like grep or sed -- a standard tool that works the >> same everywhere. >> > > I'm not convinced that dmenu shouldn't have keybindings right out in the > open and in config.h. I do, at least, see your point. (A better analogy > would be 'less'. Imagine instead of q quiting out of less someone hacked > up a variant that had r quit. O the pain!) > > However, I do see the real need to configure at least the keybinding I > mentioned before, namely, the Esc keybinding. In a lot of cases, it is > nice > to bind the exact same key which opens the menu to the close menu function, > e.g.\ in the case of the "Windows" key, or in my case, the Super_R key; and > in some cases Esc might not be the best guy for the job (although I prefer > having both Esc and the Super_R key precisely because other users will get > upset.) > > I'm not sure if I have a positive solution. If there aren't any other > cases > when it would be useful to fiddle with the default keybindings, then we > probably shouldn't bother. But maybe I'm not being creative enough? > Peter > Well dmenu should at least have the defaults in config.h, just like the default colors, etc. Then those who really want functionality X could patch it in themselves, just like any other tools. Just because, say, I add Ctrl-G to open a page in my browser with the current input as the URL doesn't mean (and that probably wouldn't ever) it should become mainstream, or even something widely used. It's my version of dmenu, hacked to what I want/need in a choice selection program. Just like I could have a `less' that does use O to quit rather than q. I don't know about anyone else, but having escape as the default kill key works out really well for me. Of course, I do have caps lock switched with escape, however. It also helps with editing in vim.
Re: [dev] [dmenu] pasting bug
On Tue, Dec 1, 2009 at 13:17, Evan Gates wrote: > Yep, definitely bugs. When I wrote the paste patch cursor wasn't a > part of dmenu, so as of right now paste assumes a cursorless dmenu. > I'll take a look at it tonight and see if I can rewrite paste to work > with cursor. Also what do people think about the sselp dependency? I > can always copy and paste the sselp code directly in instead, let me > know. > > -emg > > Personally, I'd rather a dependency on xclip rather than sselp. I think that is much more likely to be installed on someone's computer than sselp. Of course, xclip does a lot more than sselp.
Re: [dev] [dmenu] pasting bug
On Thu, Dec 3, 2009 at 18:17, Julien Steinhauser < julien.steinhau...@orange.fr> wrote: > On Thu, Dec 03, 2009 at 11:29:55AM -0500, Colin Shea wrote: > > Personally, I'd rather a dependency on xclip rather than sselp. I think > that is > > much more likely to be installed on someone's computer than sselp. Of > course, > > xclip does a lot more than sselp. > > As you said, xclip does a lot more than sselp and in this case sselp > perfectly fits the bill the suckless way. > > People who know where to find dmenu should be able to find sselp, > I believe most dmenu users are getting new dmenu version here, > > I don't know for others distros, but in debian for example, > dmenu and sselp are packaged together with a bunch of other tools. > > I meant that anywhere one could get dmenu, sselp is never far away. > You are right, it's not hard to get sselp, especially when, like in debian, it's bundled with other applications, such as dmenu. I just figure it's more common to have xclip installed rather than sselp. One less dependency to track down, as it is already installed, and all that. Of course, if you already have sselp installed, and not xclip, it would be annoying to have it already. It doesn't really matter. It's not like it's hard at all to get sselp, just either use your package manager or download and compile it. wget, make, done.
Re: [dev] Full quotes below
On Sun, Dec 13, 2009 at 09:30, Ammar James wrote: > wat? > > On Sat, Dec 12, 2009 at 3:36 AM, markus schnalke > wrote: > > Please refrain from adding full quotes a the end of your reply, it's > > such a pain to read. > > > > Either quote, the *relevant* parts, in a sane style, like: > > > >> > Please refrain from adding full quotes at the end of your > >> > reply. > >> > >> I agree, because then it's much easier to follow the > >> discussion. > > > >I also agree. Because there is one who writes the reply, but > >many who read it, thus the sender should care for an easy to > >message. Otherwise many will suffer from one who does not > >care. > > > > Or, if you don't need the context, then don't quote at all. > > > > > > meillo > > > > > Now look at what you've gone & done! You've just violated his rule! Stop putting full quotes at the bottom, sheesh.
