We allow users to specify grabs on the command-line or in config-options.
We sometimes want multiple grabs to do the same. Therefore, this changes
the grab-parser and handlers to allow this.
Furthermore, this adds support for keysyms that are assembled of multiple
syms. This isn't needed by any keymap, yet, but might be used in the
future.
Last but not least, you can also specify modifiers only now. This might be
used by subsystems to use the default keysyms but let the user specify
what modifiers should be used.
However, be careful when specifying modifiers-only for normal grabs as
this means the grab is executed everytime the modifier is reported with
_any_ key.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
If a user has multiple active XKB layouts but only one of them has ASCII
keysyms on the base level, then ctrl+<XY> might actually never work,
because these keys aren't available in the current layout. This patch
tries to find a layout of the user that actually _has_ ascii keysyms on
the base level and passes this information along with the normal keysym
information.
The TSM layer can now use this ascii keysym instead of the normal unicode
keysym to handle ctrl+<XY> shortcuts. This is the same way xterm et. al.
handle this, so it seems to be a good idea to do this in TSM, too.
Reported (and mainly written) by Ran Benita.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
We need to subtract the allocation because we get absolute pointer data as
input. This doesn't matter for the theme as long as it is the root widget,
but this might change when we introduce shadows.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
When fullscreen mode is active, we should not draw any decorations.
Instead just skip every callback in the theme layer.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
This adds a --grab-fullscreen parameter which configures the key that
toggles fullscreen. This is handled in the theme widget as we consider it
the main window-handler.
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>
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>
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>
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>
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>
