You can now use --xkb-repeat-rate/delay to configure the Xkb key-repeat
settings instead of using the default 25/250.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
Two new helpers which are needed to implement copy-support. They create
data-sources and set the current selection-source. This allows widgets to
copy data for others to paste.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
Input offers are used to implement pasting data from other applications.
This adds the infrastructure to operate on data-managers and allows
applications to retrieve the currently active selection-data via a
file-descriptor.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
This is useful to get access to input devices from the display when only a
widget or window is available.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
If zero is passed as new size, we now simply use the current size. This
allows widgets to schedule a resize round without having to specify the
current size explicitely.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
If *_toggle_maximized() is called while in fullscreen, we still change our
internal state, but we do not modify the application behavior in regard to
wl_shell_surface state. Instead, we stay fullscreen until it is
deactivated again.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
All keyboard-cbs have to return whether they handled a key now.
Furthermore, they get as parameter a flag that notifies them whether a
previous handled already handled the key.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
Add helper to make a window fullscreen. Also forward the flags to all
resize and redraw handlers so widgets can changed behavior while being
fullscreen.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
If a window is maximized, fullscreen or should be drawn without
decorations, then the widgets must be notified about it. Hence, this adds
a flags argument to resize and redraw callbacks.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
We really need to clean this up and allow parsing of grabs in conf.c
again. xkbcommon is now mandatory so we can fix all the input layers to
use it.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
A widget may have different constraints regarding minimal sizes and the
size it occupies. Therefore, we need to pass a hint with the minimal size
together with the prepare-resize round.
The catch-all user can then decide to resize the catch-all field until it
is big enough to hold all minimal-sizes.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
Instead of scheduling for redraw, we have to schedule for resize as the
new widget might want to change the size constraints.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
If we resize the buffers, we skip redrawing as resizing implies this.
However, if the resize-handler skips resizing because the size didn't
change, it also skips redrawing.
Hence, we add a new flag to force redrawing even if the resize-operation
is skipped. This fixes a bug where we didn't redraw during stalling resize
operations by the user.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
This changes the prepare-resize logic to allow widgets full control of the
new size. The initial size starts at 0 and each widget can increase it.
The last widget should be a catch-all that uses all size that is available
and computes a good new size based on the requirements that the previous
widgets provided.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
When enabling the printf() logic for the logging subsystem, several
warnings were produced about missing or wrong specifiers. This fixes all
those occurrences.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
Use wl_shell_surface_set_maximized() to notify the compositor that we
support being maximized now. The server actually decides whether it
resizes our window.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
This adds a timer that automatically repeats key-events while pressed. In
the XKB-1 protocol embedded in wayland, key-repeates are not sent for
performance reason so we have to emulate them.
It is currently unclear where to take key-repeat rates from. This will be
solved in the future, though.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
We need to keep dp_fd alive for all calls to wl_display_*(). Otherwise,
the callback will use it and access invalid memory.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
The need_frame and idle_frame logic was slightly wrong. We ended up not
correctly requesting the frame-cb after a _real_ frame-cb. Hence, the
idle-cb did simply send the next attach() request.
This fixes this small race and adds a comment how all this is supposed to
work.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
This implements the wl_keyboard client-side of the wayland protocol and
takes care of pushing keyboard events to the correct window.
A new callback is added to all widgets which is called when keyboard input
is sent to the specific window.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
This helper allows widgets to retrieve the eloop that is used by the
window. Otherwise, we couldn't dispatch events there.
No refcounting is needed as all widgets are destroyed before the window is
destroyed. Other users need to perform ref-counting by themself.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
Sorry for the big commit, but I was working on the wlterm application and
then thought I can rework the whole configure-logic again. This mainly
renames all build-defines to BUILD_DEFINE_* and BUILD_HAVE_* and allows
specifying which applications to build via --enable-kmscon/--enable-wlterm
and similar.
wlterm is a new application which is a native wayland client with no
external dependencies. It serves several purposes:
* It uses TSM (not yet implemented, but will come soon) to create a
console independent from kmscon. This shows how TSM can easily be used
to create independent terminal emulators.
* It is a native wayland application (probably the first independent
wayland app so far?) and is used to test how well the wayland API
works. As wayland is still under heavy development, we need more
application-writers who report back whether the wayland-API makes
sense to them and whether it works correctly.
* A proper terminal-emulator for wayland! There is currently no proper
emulator so we really need something that we can work with.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
