Re: [dev] dmenu-4.5

From: Rob <>
Date: Wed, 11 Jan 2012 12:45:40 +0000

On 11 January 2012 10:55, D┼żen <> wrote:
> Hey Connor
> I've discovered a little imperfection when running dmenu with the -f
> flag (note that this is really a tiny issue and maybe it would be better
> to just ignore it).
> Due to the fact that dmenu locks up the keyboard before reading data
> from stdin, the user isn't able to exit dmenu while it is waiting for
> (or reading) data from stdin. As far as I know the only solution would
> be to switch over to a tty outside of X, then send a kill signal to
> dmenu. This can be annoying if dmenu has to wait for data for a long
> time or no data is coming at all, and the user simply wants to exit
> dmenu.

This is a known bug, we decided to leave it as it is, for the time
being, because we couldn't think of a simple way to solve it, and I
think there's a note somewhere about only using -f if dmenu is reading
from a non-tty. I think I did have dmenu set to print a warning if stdin
was a tty and -f was given, but I don't know what happened to it.

> IMO, dmenu should always exit if XK_Escape or Ctrl-C is pressed. This
> could be solved by select()'ing through the stdin fd and X fd, in order
> to be able to handle KeyPress events from X.

I hadn't thought of this solution, it increases the complexity, so I
suppose it's up to Connor, I'm at work at the moment so I can't test it
out either.

> The attached patch works for me, however I'm not sure whether this is an
> elegant solution. A possible issue with this patch might be the loss of
> speed while reading data from stdin (due to the select() calls, etc).
> What's your opinion?

I wouldn't imagine a few extra select calls would matter. What if we
used select() until we got input on stdin, then just read all of stdin
at once, not bothering to select() again? Unless you're reading over a
network, I don't think there's that much of a delay.

Received on Wed Jan 11 2012 - 13:45:40 CET

This archive was generated by hypermail 2.3.0 : Wed Jan 11 2012 - 13:48:04 CET