Unlike what commit d01ea18dc3 says, X11 is
not a requirement for Wayland, so a Wayland-only build is possible. We
just use the same logic as other non-X11 platforms.
https://bugzilla.gnome.org/show_bug.cgi?id=784615
Signed-off-by: Quentin Glidic <sardemff7+git@sardemff7.net>
is_touchpad_device() for XI2 was hardcoded to look for libinput only.
Extend it slightly to correctly identify other Xorg touchpad drivers.
https://gitlab.gnome.org/GNOME/gtk/issues/97
This allows widget to attach their streams to GdkWindow(s)
The idea is to allow attaching a stream to windowing system(s) so the
stream can make use of its resources, in particular GL contexts.
I am however unsure what to attach to:
- GtkWindow
- GdkWindow
- GtkWidget
- GskRenderer
Each of these provide advantages and disadvantages.
So I'm very much open to better suggestions.
This way, we can support external libraries providing implementations of
GtkMediaFile.
We also add a media backend called 'nomedia' that can be enabled to not
compile any support for GtkMediaFile. This is useful when people want to
statically compile GTK into an application that does not use media.
For now, this option is the default.
We also support a new environment variable GTK_MEDIA that allows
selecting the implementation to use.
GTK_MEDIA=help can be used to get info about the available
implementations.
This is necessary so that bidnings work properly and don't make
gdk_gl_texture_release() a function on GdkTexture.
It also allows code to identify what type of texture they are dealing
with.
Finally, we can now decide to add getters later without screwing
anything up, if we want to allow people to access GL textures directly.
The logic for this in 3 got lost in the move from gadgets to widgets. We
must update the sensitivities when :wrap, :value, or the bounds change.
Close: https://gitlab.gnome.org/GNOME/gtk/issues/88
This used to test that "windowed widgets" and "non-windowed widgets"
handle alpha correctly, but none of the mentioned widgets are windowed
at all anymore. For the rest, this is more easily and dynamically
testable by simply using the inspector.
If @menu_label == NULL, we create a default page->menu_label. This took
@tab_label.get_label() and passed that to page->menu_label.set_text().
This is wrong because we set the plain text of the menu_label from the
rich text of @tab_label. So, if @tab_label used mnemonics or markup, our
menu_label got the raw underline or markup tags shown in it as raw text.
As we call set_text() on the menu Label, the fix is to be symmetric: use
@tab_label’s get_text() as source, as that strips underlines and markup.
It’s not worth making the default Label ‘inherit’ :use-underline/markup;
that’s a slippery slope, and users wanting such things can just create a
fully fledged GtkLabel to pass as @menu_label to suppress the default.
https://bugzilla.gnome.org/show_bug.cgi?id=705509
