Instead of associating the GdkWindow that created the GdkDrawingContext
we can directly bind the Cairo context to the GDK drawing context.
Cairo contexts created via gdk_cairo_create() go back to not having a
GdkWindow associated to them, like they did before we introduced the
gdk_window_begin_draw_frame() API.
https://bugzilla.gnome.org/show_bug.cgi?id=766675
Existing code drawing on a GDK window has to handle the direct drawing
and the buffered drawing by itself, by checking the window type and
whether or not the window is backed by a native windowing surface. After
that, the calling code has to create a Cairo context from the window and
keep an association between the context and the window itself.
This is completely unnecessary: GDK can determine whether or not it
should use a backing store to draw on a GdkWindow as well as create a
Cairo context, and keep track of it.
This allows to simplify the calling code, and enforce some of the
drawing behavior we want to guarantee to users.
https://bugzilla.gnome.org/show_bug.cgi?id=766675
In Wayland, surfaces get an enter/leave notification each time they
enter or leave an output.
Add an API to GdkWaylandWindow to retrieve the output the window has
last entered.
https://bugzilla.gnome.org/show_bug.cgi?id=766566
This has several benefits:
- Less code in GtkApplication. The accels handling is something
self-contained, and GtkApplication now delegates the work.
- For the accels functions, there is now a distinction between static
functions and functions in the gtkapplicationaccelsprivate.h header,
which makes the code easier to understand, because we have a good
overview just by reading the header.
- The struct _GtkApplicationPrivate is now easier to find instead of
being in the middle of the file.
https://bugzilla.gnome.org/show_bug.cgi?id=764879
Because there are multiple different types of styluses that can be used with
tablets, we have to have some sort of identifier for them attached to the
GdkDeviceTool, especially since knowing the actual tool type for a GdkDeviceTool
is necessary for matching up a GdkDeviceTool with it's appropriate
GdkInputSource in Wayland (eg. matching up a GdkDeviceTool eraser with the
GDK_SOURCE_ERASER GdkInputSource of a wayland tablet).
Signed-off-by: Stephen Chandler Paul <thatslyude@gmail.com>
GdkDeviceTool is an opaque object that can be used to identify a given
tool (eg. pens on tablets) during the app/device lifetime. Tools are only
set on non-master devices, and are owned by these.
The accounting functions are made private, the only public call on
GdkDeviceTool so far is gdk_device_tool_get_serial(), useful to identify
the tool across runs.
We should conform to a minimal set of reasons for the gtk side to emit
a better GtkDragResult than GTK_DRAG_RESULT_ERROR. This fixes the notebook
tab DnD feature, where we rely on GTK_DRAG_RESULT_NO_TARGET.
In the wayland side, unfortunately we can't honor either NO_TARGET nor
USER_CANCELLED, we don't know of the latter, so we could return false
positives on the former.
https://bugzilla.gnome.org/show_bug.cgi?id=761954
Make the preview command parse options properly, turn the ID into
an --id=ID option, and add a --css=FILE option that allows to
specify a css file to use for previewing.
This is useful for e.g. previewing the reftest .ui files with
their corresponding .css.
This lets us do fallback in case an image format is not
supported, and also lets us provide solid-color images.
We don't support image fragment notations.
See ttps://www.w3.org/TR/css3-images/#image-notation
https://bugzilla.gnome.org/show_bug.cgi?id=761318
The new function, gtk_render_background_get_clip answers the
question: what pixels are affected if I call gtk_render_background ?
The long-term goal is to have APIs that answer this question for
all rendering primitives.
Derived classes like GtkSourceView with their own ::key-event
handler need access to this, in order to make their keynav
as nice as the builtin one, wrt to caret visibility.
https://bugzilla.gnome.org/show_bug.cgi?id=760748
And use it to handle kinetic scrolling in the GtkScrolledWindow.
However, dropping the delta check causes the X11-based kinetic
scroll to break since we don't have the stop event here. Correct handling of
xf86-input-libinput-based scroll events is still being discussed.
https://bugzilla.gnome.org/show_bug.cgi?id=756729
Add a gtk_style_context_to_string function that can serialize
a CSS node or tree of nodes, optionally including CSS properties
as well.
This will be useful in writing tests.
Split the CSS docs off from the GtkCssProvider docs and
give them their own chapter. Among other things, this commit
introduces more or less complete definitions of the syntax for
the supported selectors, a complete list of all supported
properties, and definitions for their values. This includes
documentation for GTK+-specific properties such as -gtk-icon-source.
GdkWaylandDeviceData conceptually gathers the data that belongs to
a seat, so it's been renamed (although the old typedef stays, plenty
of refactoring is due here...).
The methods in GdkSeatClass have also been implemented, the most
remarkable is ::grab, which ensures the grab is performed on all
the relevant "master" devices.
https://bugzilla.gnome.org/show_bug.cgi?id=759309
Add a variant of gdk_drag_begin that takes the start position
in addition to the device. All backend implementation have been
updated to accept (and ignore) the new arguments.
Subsequent commits will make use of the data in some backends.
The name gtk_text_*_begins_* was used only for begins_tag(). All other
similar functions use "starts": starts_line(), starts_word(), etc.
So for consistency, add gtk_text_iter_starts_tag() and deprecate
gtk_text_iter_begins_tag().
Also change (allow-none) to (nullable), to use the new annotation.
https://bugzilla.gnome.org/show_bug.cgi?id=759092
The gesture functionality was taken over by GtkShortcutsShortcut,
so this widget is no longer needed, and it never was in a stable
release, so lets get rid of it.
Under X11, popovers are always constrained to the toplevel
window. Under Wayland, they aren't. This commit adds a
property that allows to explicitly constrain popovers to
the toplevel, giving them the same behavior under Wayland
as under X11.
https://bugzilla.gnome.org/show_bug.cgi?id=757474
Its very easy to get extra references to the NativeDialog so that
when you release your last reference any visible dialog is not
hidden. We handle this by adding a destroy method similar to how
you destroy regular toplevels.
This is a base class that essentially mirrors GtkDialog, but
it is not a GtkWindow, as the actual implemetation will be using
native code.
The base class has show and hide vfuncs, as well as a helper function
to run the dialog in a modal fashion.
This will be later used by the native file chooser dialog.
... and gtk_widget_path_iter_get_object_name(). This allows applications
that still use widget paths to use the new object names to get the
correct styling.
Mutter and webkit-gtk are examples here.
When the $(resource_prefix)/gtk/help-overlay.ui resource exists,
load a GtkShortcutsWindow from it for each GtkApplicationWindow,
and set up a win.show-help-overlay action with accels <Primary>F1
and <Primary>? to show it.
Each gesture type has its separate GdkEvent struct, and begin/update/
end/cancel event types.
There is support for multi-finger swipe (3-4 fingers), and 2-finger
rotate/pinch gestures.
This allows a widget to override global font_options, such as hinting and
subpixel order. The widget's PangoContext is updated when this is set.
Some update code from gtk_widget_update_pango_context was moved to
update_pango_context so that gtk_widget_update_pango_context runs it.
http://bugzilla.gnome.org/show_bug.cgi?id=751677
It is convenient to allow applications to show all the drop
targets at once. This improves the user experience with drag
an drop.
The new API allows the application to set the gtkplacessidebar
in a mode where invalid drop targets are insensitive and it
adds a "new bookmark" row. This mode is intended to be set
when the application is aware of a dnd operation and needs to
be stopped kwhen the application is aware that dnd operation
was cancelled or ended in a different part than gtkplacesisdebar.
The context parameter is unused in this patch, but will be
used in next patches when the sidebar will use a GtkListBox.
The reason of being unused now is just convenience.
https://bugzilla.gnome.org/show_bug.cgi?id=747793
Since nautilus merge, we were not showing 'Recent' in the sidebar
if GIO did not support the recent: scheme. But the file chooser
can show recent files independent of gvfs - it loads the recent
files manually. This is relevant on Windows and OS X, where gvfs
is typically not used.
This commit adds a show-recent property which can be used to override
the recent: scheme check. We use it in the file chooser.
https://bugzilla.gnome.org/show_bug.cgi?id=750068
Load themed cursors from the same places they are loaded on freedesktop systems,
but use W32 API functions to do so (works for .cur/.ani cursors instead of X
cursors).
Refactor the code for cursor handling. Prefer loading cursors by name.
Do not load actual cursors when loading the theme. Find the files and remember
the arguments/calls for loading them instead. Keeping HCURSOR instance in the
hashmap would result in multiple GdkCursors using the same HCURSOR. Given that
we use DestroyCursor() to off them, this would cause problems (at the very
least - DestroyCursor() would fail).
Store GdkCursor instances in a cache. Update cached cursors when theme changes.
Recognize "system" theme as a special (and default) case. When it is set,
prefer system cursors and fall back to Adwaita cursors and (as a last resort)
built-in X cursors. Otherwise prefer theme cursors and fall back to system and
X cursors.
Force GTK to use "left_ptr" cursor when no cursor is set. Using NULL makes
it use the system default "arrow", which is not the intended behaviour when
a non-system theme is selected.
Ignore cursor size setting and query the OS for the required cursor size, as
Windows (almost) does not allow setting cursors of arbitrary size.
https://bugzilla.gnome.org/show_bug.cgi?id=749287
Add a new API, gtk_popover_set_default_widget, that can be
used to make a widget act as default while the popover is
shown. This is useful in dialog-like popovers.
http://bugzilla.gnome.org/show_bug.cgi?id=747664
GdkKeymap already has support for _get_num_lock_state() and
_get_caps_lock_state(). Adding _get_scroll_lock_state() would be good
for completness and some backends (Windows?) could take advantage of
this.
The other Radio* widgets have this convenience method that removes the
memory management of the opaque GSList used to handle the group from the
API usable from language bindings (especially the ones not based on
introspection).
This commit adds gtk_radio_menu_item_join_group().
https://bugzilla.gnome.org/show_bug.cgi?id=671362
These have the same visual effect and timing than the gnome-shell ones.
During the hide animation, the popover has been made to take focus
elsewhere, and refuse to take any pointer/keyboard input until the popover
is shown again.
This has been based on work from Timm Bäder.
https://bugzilla.gnome.org/show_bug.cgi?id=741405
Also try and clarify a few things about event propagation. Move
input-handling.xml into gtk-doc’s expand_content_files variable so it
automatically links to widget documentation. Add links from
gtk_widget_add_events() and friends to the new documentation.
https://bugzilla.gnome.org/show_bug.cgi?id=744054
This is necessary to avoid unwanted drag cancel animations,
now that GtkNotebook is careful about cancelling a drag
when the dragged tab disappears unexpectedly.
The existence of OpenGL implementations that do not provide the full
core profile compatibility because of reasons beyond the technical, like
llvmpipe not implementing floating point buffers, makes the existence of
GdkGLProfile and documenting the fact that we use core profiles a bit
harder.
Since we do not have any existing profile except the default, we can
remove the GdkGLProfile and its related API from GDK and GTK+, and sweep
the whole thing under the carpet, while we wait for an extension that
lets us ask for the most compatible profile possible.
https://bugzilla.gnome.org/show_bug.cgi?id=744407
Store the OpenGL version when we first do the extensions check; this
allows client code to check the available GL version without requiring a
call to gdk_gl_context_make_current() and epoxy_gl_version().
