On X11, not all programs offer this target, e.g. some terminals like
XTerm. The target "UTF8_STRING" has worked fine for many years and it is
what dmenu uses.
On Wayland, wl-paste supports the special type "text", which attempts to
autodetect a suitable type (in case there is no exact match for
"text/plain").
Previously, C-y pasted the "primary" selection on X11 and the
"clipboard" selection on Wayland. That's inconsistent and confusing,
especially when you're switching back and forth between the two.
This commit does two things:
1. It makes C-y always paste the "clipboard" selection.
2. It adds a key bind C-Y to paste the "primary" selection.
I suspect that most bemenu users are on Wayland, so this commit tries to
not break things for them. It does, however, change the behavior on X11.
Fix many issues with styling related to bemenu and the upwards list
mode. In addition to this, fix/modify some behavior to improve
this(ex: border_size and border_radius are now a double).
popen() returns NULL if the underlying fork() or pipe() fails, not if
the called program didn't run properly. The old code didn't actually
fall back to xclip on X11, it was never called.
To fix this, inspect the exit code of the programs that we run. We use
the output of the first program that exited cleanly.
CC #363.
Add parameters to the password flag, add an option in this flag to
enable indicator mode(display asterisks instead of hiding or
displaying the filter text).
Man page and help flag fix
Add password flag details to the man page, fix the help flag slightly
for better password flag details.
If an unexpected error was returned from a Wayland API during rendering (e.g.
from wl_display_flush), the code did set input.sym = XKB_KEY_Escape, so that
the next call to poll_key would return BM_KEY_ESCAPE and bemenu would quit.
However, this has been broken since #135, because input.key_pending was not
set, so the "fake" XKB_KEY_Escape is just ignored, bemenu doesn't quit, but
instead, it enters an infinite loop and keeps a CPU core at 100% usage.
The "quick fix" would be to just set input.key_pending wherever input.sym was
set to XKB_KEY_Escape. However, to make error handling less error-prone,
decouple it from input handling and add an error flag to (bm_menu_)render.
If the pointer suddenly enters a window but moves no further, we may only get
a POINTER_EVENT_ENTER but no further POINTER_EVENT_MOTION events, so we also
need to handle this event to properly update the selected item.
The issue can be reproduced by moving the mouse programatically, e.g. on Sway:
swaymsg seat - cursor set 200 200
Currently, on the Wayland backend, the following command:
{ echo one; sleep 1; echo two; } | BEMENU_BACKEND=wayland bemenu --grab
Will keep showing the 'Loading...' text even after all items are available.
The items will only be shown after some input, e.g. a key press, happens.
This was a regression introduced by 5a095705d2
(versions 0.6.5+). A dirty flag was added to avoid unnecessary redraws,
however, this flag is not reset between the renders before/after the items are
loaded, so the bm_menu_render call after the items are loaded is ignored
(on Wayland, which is the only renderer that currently uses the dirty flag).
Fix the issue by setting the dirty flag when the filter changes, so it will be
reset when changing from "Loading..." to empty and cause a redraw.
We add a dirty flag on the menu to track if the menu actually need a
redraw. With it, we will not redraw if the touch is hold on the same
entry by example.
It works on Wayland and X11 and acts as a complement to margin. Exact
behavior is as follows:
- If width factor is 0, width minus margin is used.
- If width multiplied by factor is greater than width minus margin,
width minus is used. (so margin may be used to make sure that bemenu
is at least N pixels away from the view border)
- Otherwise width multiplied by factor is used.
I think it's fine to disable warnings about floating point numbers
comparision. We don't do any arithmetics on them anyway, so we can't
suffer from inaccuracy.
With dmenu, monitor indices start at 0 and a value of -1 (the default)
is used to spawn dmenu on the current monitor. While bemenu strives to
be compatible with dmenu, bemenu monitor indices previously started at 1
and a value of 0 (the default) was used to spawn on the current monitor.
This commit aligns the behaviour of bemenu's x11 backend with dmenu. For
this purposes, the affected code in the x11 backend is synced with the
current dmenu implementation. While doing so the monitor type has also
been switched from a uint32_t to a int32_t.
