The default application for a content type is selected depending on
whether it matches the given content type or any of its sub-classes.
This means that we might end up showing a text editor for the
`text/calendar` MIME type because it matches the `text/*` super-class.
The recommended applications, on the other hand, match the exact content
type.
Fixes: #377
- Adjust the emoji picker appearance to be the same as gtk3's.
- Fix button.emoji-section margins in RTL.
- Prevent the .emoji hover effect from being applied to the entire
nested popover.
The signal handler that calls notify_child_cb() is disconnected
from a child widget before the child is removed from the header bar.
gtk_header_bar_dispose() chains up before destroying the start and end
boxes, thus avoiding calls to notify_child_cb() after start_box and
end_box have been cleared.
Fixes#2246
A GtkBox in a titlebar could have unwanted spacing.
This caused a glitch in split-header applications where
parts of the titlebar would be transparent or black.
This commit tweaks Adwaita to make sure no spacing is added for boxes when used as titlebars.
Fixes#2233
Some of the CSS API has been moved to a public namespace, so we need to
include it into the introspection data we build in order for people to
use it.
Fixes: #2230
GTK uses the Meson `buildtype` option to determine whether to enable or
disable debugging code and safeties. We should document our behaviour
and expectations.
This adds support using the GtkTextHistory helper for undo/redo to the
GtkText widget. It is similar in use to GtkTextView, but with a simplified
interface.
You can disable undo support using the GtkText:enable-undo property. By
default, it is enabled.
This changes the semantics of ::deleted-text to perform the removal of
text in the default handler. This means, that if you want the old behavior
where your signal handler is called after the text has been deleted, you
should connect with G_CONNECT_AFTER in your signal handler (or use
g_signal_connect_after).
Without this change, there was never a way to get the deleted-text before
the operation had completed and this is necessary to provide undo support
to the text widgets.
This builds upon the GtkTextHistory helper to provide undo and redo support
for the GtkTextView widget and GtkTextBuffer object.
You can undo/redo using familiar shortcuts such as Primary+Z,
Primary+Shift+Z, ad Primary+Y.
Developers that wish to disable undo, should set the
GtkTextBuffer:enable-undo property to FALSE.
You can wrap irreversible actions
gtk_text_buffer_begin_irreversible_action() and
gtk_text_buffer_end_irreversible_action(). This will cause the undo stack
to drop all undo/redo actions and the changes made between them will be
the "initial state" of the buffer.
Calling gtk_text_buffer_set_text() will do this automatically for you.
The GtkTextHistory helper provides the fundamental undo/redo stack that
can be integrated with other text widgets. It allows coalescing related
actions to reduce both the number of undo actions to the user as well as
the memory overhead.
A new istring helper is used by GtkTextHistory to allow for "inline
strings" that gracefully grow to using allocations with g_realloc(). This
ensure that most undo operations require no additional allocations other
than the struct for the action itself.
A queue of undoable and redoable actions are maintained and the link for
the queue is embedded in the undo action union. This allows again, for
reducing the number of allocations involved for undo operations.
The msys2 runner has started failing for internal reasons:
- gtk-3-24 times out
- master fails with a ld.exe assertion:
BFD (GNU Binutils) 2.33.1 assertion fail
../../binutils-2.33.1/bfd/cofflink.c:2348
Both seem related to some MSYS2 issue. Until the runner is updated, we
should not block on it.
Using gsettings for this information does not work
in sandboxed scenarios, where settings are per-app.
Since the Wayland protocol provides this information
nowadays, just drop the old code for reading
the gsettings.
set_active() is meant to set the state of the property, which happens
during setup.
The clicked signal is emitting events from user actions.
It is impossible to use Togglebuttons for MVC applications as long as it
does that.
Unrealize the GSK renderer before destroying children.
This makes the renderer drop any texture caches that
it might have, so that we don't needlessly download
them when releasing the widget-side holder objects.
As a fortunate side effect, this fixes crashes on
exit with GtkGLArea-containing windows under Wayland.
Add the margins to the menubutton and not the button inside the
menubutton. This way popovers properly point to the inner button again
instead to somewhere 6px off.
When attaching renderer-specific data, we need to
make sure that we key it off the renderer that is
in use, and cope with the absence of render data.
This fixes recording nodes in the inspector.
GtkIconInfo contains too much redundant data,
and it is hard to know which fields are to be
used when.
This commit starts to move towards dropping the
icon_file field - we prefer to work with the
filename directly, since it lets us avoid mime
sniffing and strdups.
This function is not useful. Every icon theme
on my system either does not have that field,
or has it as 'folder'. So, just use 'folder'
when you need an example icon.
When we are loading themed icons, we know if
we deal with an svg or png file, so it is
entirely unnecessarily to have gdk-pixbuf
use g_content_type guess to rediscover that
information.
Change the pixbuf utils apis we have to allow
passing format information down to where we
can use it when creating the pixbuf loader.
Return a pointer to the IconData struct. This is
closer to the glyph cache api, and will allow us
to add similar shortcuts. For now, just store
texture coords in the form we need, avoiding
converting them over and over.
This is a quick implementation that avoids many
glyph cache lookups. We keep an array of direct
pointers in the text render node, and throw those
cached pointers away whenever any atlases have
been dropped (since that may invalidate the cached
glyphs).
In many cases of the switch, we do not need the vertex data. This moves
the creation of the vertex_data array into a secondary function and only
calculates it the cases for which it is required.
... inside the default vfunc.
Instead, walk the children until we find the first widget that can be
focused. If no child can be focused, return FALSE from grab_focus.
The expander icon is renamed from "arrow" to "expander".
The expander widget itself is renamed from "expander" to
"expander-widget" (Better ideas welcome).
This makes it possible to have an "expander" icon in more places then
the GtkExpander widget (in particular in tree lists) and not
confuse it with arrows.
We were putting big glyphs in the cache, in their
own texture, but forgetting to mark the texture
as permanent, so it could be reused, leading to
occasional misrendering. Fix this by marking these
textures as permanent, and explicitly freeing them
when the cache entry gets old.
Every few frames, we do extra work for the
cache aging. Arrange for the glyph and icon
caches to not cause extra work on the same
frame, to smooth things out.
There is no need for us to be very precise about
aging the glyph entries. It is enough to check
occasionally and mark old entries. This reduces
the overhead of work we do every frame on the
caches, at the cost of letting glyphs linger
a bit longer in the cache.
Make this function more similar to the icon
cache equivalent, and simplify it a bit. We
don't use the boolean return, and we don't need
to look at the age of entry when marking it
used.
Remember which atlases were removed, and only
check those when looking for icons or glyphs
to remove. For most frames, we don't have to
check at all since no atlases were removed.
Instead of copying the (rather large) RenderOp to the GArray, we can
simply set the fields directly in the allocated space for the struct.
In most cases, there wont be any allocations to make as the array size
is kept in tact across frame renderings.
We can just use memcmp here because even in the use of lookup keys with
C99 initializers, we can rely on any space between fields added by the
compiler to be zeroed. So we might as well use wider memory cmopares.
Previously, with selection bounds, we could have a state where a line
display with selections set would eroniously stay in the cache. This
aggresively releases those at the boundary cases fixing deselection
drawing state.
The event may end up freed after delivery, ensure to keep a ref in order
to emit the matching emulated crossed event matching a proximity event.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/2157
We can avoid recreating a number of text nodes from render_para() on
sub-sequent runs if we cache the rendernode instead of just the
PangoLayout.
When used with GtkSourceMap, this can yield a ~7 FPS improvement during
smooth scrolling at the cost of some more memory.
The code managing this accounting mixed seat and tablet output lists,
can't bode well. Fixes invalid reads on list elements, as there are
dangling pointers.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/2157
This is the Vulkan version of eglSwapBuffersWithDamage(), and
it's always a good idea to limit the number of pixels we're
pushing to the GPU and/or swapping into the display.
UNDEFINED initial layouts may not preserve the contents
of the attachment after transitioning the layout. We want
them to be preserved because we do partial rendering.
Use GENERAL as the initial layout for render passes.
Multiple images in the before barrier array are defined with
VK_ACCESS_TRANSFER_WRITE_BIT and VK_ACCESS_TRANSFER_READ_BIT,
which requires passing VK_PIPELINE_STAGE_TRANSFER_BIT and
VK_PIPELINE_STAGE_HOST_BIT to vkCmdPipelineBarrier().
Pass these flags correctly.
This is a requirement for using VK_KHR_incremental_present.
Vulkan Wayland drivers translate the VkPresentRegionsKHR to
wl_surface.damage_buffer(), which a v4-only request.
This creates a new GtkTextViewChild that can manage overlay children at
given x,y offsets in buffer coordinates. This simplifies GtkTextView by
extracting this from GtkTextWindow as well as providing a real widget for
the borders.
With this change, we also rename gtk_text_view_add_child_in_window() to
gtk_text_view_add_overlay(). For those that were using
GTK_TEXT_WINDOW_WIDGET, they can use a GtkOverlay. It does not appear
that anyone was using GTK_TEXT_WINDOW_(LEFT|RIGHT|TOP|BOTTOM) for widgets
in this fashion, but that can be done by setting a gutter widget with
gtk_text_view_set_gutter(). We can make GtkTextViewChild public if
necessary to simplify this should it become necessary.
GtkTextViewChild will setup a CSS node of either "text" or "border"
depending on the GtkTextWindowType.
The old GtkTextViewChild has been renamed to AnchoredChild as it is only
used for widgets with anchors in the GtkTextBuffer. This also removes the
use of allocated GSList and instead embeds a GQueue and GList to save a
few extraneous allocations.
The renaming of this function doesn't make much since because the window
is the GtkTextWindowType, not GdkWindow specifically. So we can keep the
old name which is closer to the proper meaning and less code for consumers
to change when porting to 4.x.
It’s possible for code which uses a `GtkListBox` to reuse a single
header row, and move it around between rows. For example, this might
happen if the code has interactive widgets (like buttons) in the row,
and doesn’t want to continually recreate them and reattach signals to
them whenever the row headers change.
Unfortunately, this was broken, as the old header widget was
unconditionally unparented, even if it had just been set as the header
for a different row in the same `GtkListBox`. This left it assigned as
a child widget in the `GtkListBox` (so it was iterated over by
`forall`), but without its parent widget set.
Fix that by only unparenting the header if it hasn’t already been
assigned as the parent of a different row.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
G_ENABLE_DEBUG is tied to the meson builttype property, so building with "plain"
results in G_ENABLE_DEBUG not being defined and the GTK_DEBUG env var just gets ignored
for that build.
Since it can be confusing that GTK_DEBUG has no effect print a warning message instead.
See #2020. This is a port of !1109 to master
When calling gdk_wayland_surface_export_handle(), if we pass
some 'user_data' but no 'destroy_func', GTK4 crashes. That's
because in xdg_exported_handle() we are unconditionally calling
destroy_func -- even when it's NULL.
Fix that by checking if there's a destroy function before calling
it.
Fixes https://gitlab.gnome.org/GNOME/gtk/issues/2179
While the ::scroll signal always returns whether it handled the event,
the others do not, for example ::decelerate.
Previously, this caused the event to stop at a scroll controller with
CAPTURE phase, never emitting the ::decelerate signal on later
controllers with BUBBLE phase.
Fixes#2151
This currenly just wraps GMarkupParser, but the plan is to expose this
instead of GMarkup in the GtkBuildable interfaces, allowing us to
replace the parser with something that handles pre-parsed input
instead.
Note that we duplicate some of the features of GMarkup to implement
the APIs rather then call down to GMarkup, as we need to support these
in the pre-parsed case anyway.
We were converting the same colors over and over again to a string, just
to free them again at the end of the function. We know the colors at
compile time however, so don't convert them at all.
load_symbolic_svg was loading the pixbuf just to get its size via
gdk_pixbuf_get_{width,height}. However, this function is called in a
loop in gtk_make_symbolic_pixbuf_from_data.
So, do this only once and pass the icon size along to load_symbolic_svg.
Add a cache of icon infos that we keep around a little longer, to avoid
loading icons from disk that only exist for a short amount of time (e.g.
during one frame of a cell renderer snapshot).
We make sure recently used items are kept alive by just adding them to
the cache on lookup.
We were allocating IconThemeDir instances and then only later assign a
value to has_icons. In the !has_icons case, we were directly throwing
the IconThemeDir away again.
Delay allocating the IconThemeDirs until we know that it has icons.
This avoids allocating and then de-allocating around 1400 IconThemeDir
instances when opening the widget-factory.
The previous code was hiding the fact that the scan_resources function
almost always did nothing and just used g_resources_enumerate_children()
and then returned FALSE, leaving the caller with cleaning up the already
allocated IconThemeDir. By inlining this, we make sure that calling code
does not even need to allocate the IconThemeDir.
It doesn't really make sense to save the applications and groups in
recent infos as linked lists. We get them from glib as arrays, so we can
as well just save them as such.
Creating a recent manager can be fairly expensive and we won't use it if
the widget is not visible or the recent mode has not been entered. Code
other places can already handle a NULL recent manager, so just create it
when entering the recent mode. And shove 25ms of startup time off the
widget-factory this way.
Delaying this by one frame by putting it in an idle just makes the code
more complex for no gain. The actual slow part is reading the
recently-used.xbel, which happens when creating the recent manager.
We call this function *a lot* it's doing lots of unnecessary work inside
g_str_has_suffix. Get the icon name length only once instead and
open-code the suffix check.
The value returned by gtk_widget_get_settings() depends on the widget's
display, so watch for notify::display instead of using (un)root for
this.
Fixes the warnings seen when show a file chooser from the inspector.
This code is better because:
1) The coordinates translations are actually correct and not sometimes
wrong like before
2) We clip widgets that have overflow set
3) We honor the widget's transform
4) It is less code
The scale might be allocated at a height greater than requested, and in
that case y=0 is just too far away. Allocate the value directly next to
the slider instead.
It's almost never useful to have a bitmask here, since it's only used
for the intersection case in gtk_css_style_provider_lookup. However,
even if that returns true, we still need to check every single style
property for being set again in the look afterwards.
Just remove the bitmask.
The slowest part of that fuction is the type check for
GtkCssShorthandProperty. Subproperties of shorthand properties never
refer to more shorthand properties however, so we don't want to have the
type check for those.
When a popover menu has an open submenu,
delay activating another item until after
the pointer is stationary for a little
while. This avoids the need for precise
horizontal motion when moving towards the
submenu.
When GtkApplication starts listening to the screensaver's D-Bus
status, the screensaver-active property is not initialised and
applications making use of the property are out of sync until the
first state change. Any application starting when the screensaver is
active will think it's inactive.
To fix this, we set the property when we first start monitoring the
screensaver.
This tries to estimate the number of visible rows in a textview based on
the default text size and then tunes the GtkTextLineDisplayCache to keep
3*n_rows entries in the cache.
This was found imperically to be near the right cache size. In most cases,
this is less than the number of items we cache now. However, in some cases,
such as the "overview map" from GtkSourceView, it allows us to reach a
higher value such as 1000+. This is needed to keep scrolling smooth on
the larger view sizes.
With this patch, a HiDPI system with a GtkSourceView and GtkSourceMap
from the GTK 4 port can perform smooth scrolling simultaneously.
We do not need to create a GtkTextIter to perform the comparison here as
that will require a number of validation steps that are extra work
compared to just discovering the GtkTextLine number directly.
The xdg_output.done event is deprecated in xdg-output v3, so clients
need to rely on the wl_output.done event instead.
However, applying the changes on the fist wl_output.event when using
xdg-output v3 may lead to an incomplete change, as following xdg-output
updates may follow.
Make sure we apply xdg-output events on wl_output.done events with
xdg-output v3.
https://gitlab.gnome.org/GNOME/gtk/issues/2128
We're mainly using this for icons that will never change contents or
size, and we're using a GtkScaler per such icon when on a hidpi setup,
so just avoid the two signal connections per icon.
Because otherwise when the file list is sorted "by name"
and the new name causes the file to be re-sorted to another
row, the selection stays in the old row which is now
occupied by a different file.
Fixed by keeping track of the renamed file and revealing
it in the "row-changed" signal handler, which gets emitted
after a file is renamed.
Fixes issue #948
This CSS snippet was supposed to only recolor the popover arrow but
ended up also recoloring the > arrow on modelbuttons that show a
submenu. Make the selector more specific.
We can't just assume that the pointer we'se using as a cache key will
stay unique forever. The texture might be freed, and a later allocated
texture might have the same addres now, causing the cache to return
incorrect results.
The cairo pattern in use was simple enough, so just use a 2×1 or 1×2
texture to draw horizontal and vertical grid lines. This avoids a bunch
of cairo nodes (that can't be cached by the renderers).
Just queue_resize()ing the range itself doesn't work as it will just
re-allocate all the child widgets (i.e. just the trough) to its old
position and size.
We want to ensure all of the display cache entries are released in the
normal fashion before releasing the structures so that we can maintain
the invariant that cache_iter will always exist while in the cache.
This is happening for me when snapshotting small thumbnails in the file
chooser. The GtkScaler will scale the 1px height/width by 2, resulting
in nothing being drawn at all.
There is no reason for this to be a signal, since multiple handlers
don't make sense anyway. It was also broken because the scale needs to
know when a signal handler is added so it can update the value
representation.
Replace the signal with a set_format_value_func function which allows us
to do that.
Fixes#113
When loading a SVG icon from a gresource file only containing SVG icons,
but without having a SVG loader available in gdk-pixbuf, we would crash
when trying to eventually load the resource. Fix this by gracefully
handling this by simply failing to load the icon, while the first time
it happens, log a warning.
Fixes: https://gitlab.gnome.org/GNOME/gtk/issues/2084
- use even sides for the titlebuttons so the result is a circle and not an ellipse
- add maximum border radius
- set min width/height to 0
- adjust margin and padding to match the previous look
Previously, the manufacturer property of the GdkMonitor was NULL,
and having at least PNP id at GdkMonitor.manufacturer makes it
possible to distinguish between different monitors programmatically.
GtkFileChooserNativeWin32 is created and shown on a secondary thread.
This thread initializes COM support with CoInitializeEx but does not
finalize it, so we have a leak. Fix that by calling CoUninitialize()
before thread terminates.
See Merge Request !1043
Although slightly less efficient, keeping the order in the choices
list makes it easier for GtkFileChooserNative implementations to
add widgets in the order specified by the application.
See Merge Request !1043
When processing the list of icons for a window to add them to
_NET_WM_ICON gdk_x11_surface_set_icon_list only adds as many
icon sizes as will fit within X protocol limits.
It achieves this by keeping a running total of the number of
bytes taken up by icons already processed and bails as soon
as it goes over the limit.
The problem is, one 512x512 icon is already over the limit,
and so no icons will get added at all if the first icon in
list is 512x512.
Indeed, the code seems to assume the list is sorted from smallest
icon to biggest icon.
This commit changes the caller to sort the list.
The `name` and `description` events were added to `xdg-output` protocol
in version 2 which is part of wayland-protocols 1.14.
In xdg-output-v1 version 3, the `xdg-output.done` event was deprecated
and the `xdg-output.description` event was made mutable, but that
doesn't change the actual events so we do not actually need to require
that version of xdg-output from wayland-protocols 1.18.
Update the wayland-protocols requirement to the bare minimum version,
which is 1.14.
https://gitlab.gnome.org/GNOME/gtk/issues/2057
Pass the glyph position into the glyph caching functions,
not just the glyph index. This allows us to cache different
images for different subpixel positions.
Pass the glyph position into the glyph caching functions,
not just the glyph index. This allows us to cache different
images for different subpixel positions.
This adds a GtkTextLineDisplayCache which can be used to cache a number
of GtkTextLineDisplay (and thus, PangoLayout) while displaying a view.
It uses a GSequence to track the position of the GtkTextLineDisplay
relative to each other, a MRU to cull the least recently used display,
and and a direct hashtable to lookup display by GtkTextLine.
We only cache lines that are to be displayed (!size_only). We may want to
either create a second collection of "size_only" lines to speed that up,
or determine that it is unnecessary (which is likely the case).
We are currently using a weird mix of pango and cairo,
but there is no need for us to go through a pango
renderer here; we can just use cairo directly.
These are too sensitive to rendering differences
between renderers to run reliably in ci, but we
still want to keep them around. In particular,
the big glyph tests are useful to exercise the
GL glyph cache.
The documentation stated:
GTK is a library.… GTK depends on the following libraries:
GTK The GTK library itself contains widgets, that is, GUI
components such as GtkButton or GtkTextView.
There is no point in stating, that the GTK library
depends on the GTK library.
xdg-output v3 marks xdg-output.done as deprecated and compositors are
not required to send that event anymore.
So if the xdg-output version is 3 or higher, simply set the initial
value `xdg_output_done` to TRUE so we don't wait/expect that event
from the compositor.
https://gitlab.gnome.org/GNOME/gtk/issues/2053
This renders a magnified version of the text,
to make the effect of various font rendering options
more visible.
It also shows the phases of subpixel rendering,
if you have a recent pango and cairo.
Windows/surface's aren't supposed to be explicitly moved by any external
part, so don't provide API for doing so. Usage throughout Gdk is
replaced by the corresponding backend variants.
The generic layer still does the heavy lifting, leaving the backends
more or less just act as thin wrappers, dealing a bit with global
coordinate transformations. The end goal is to remove explicit surface
moving from the generic gdk layer.
To separate how toplevels and popups are configured, a first step is to
introduce a resize-only vfunc for backends to implement. It's meant to
only configure toplevel windows, i.e. popups. Currently it's used for
both types, but introducing the resize-only API is a first step.
Don't insert text attributes if the font, or scale
or fallback did not actually change. This helps
Pango avoid excessive item breaks, which in turn
helps shaping to work across things like color
changes.
Related: https://gitlab.gnome.org/GNOME/pango/issues/28
Configuration should happen in response to the xdg_surface.configure
event, not in the events that preceeds it. Do this by making all
configured state pending until the committing "configure" event. Also
split up toplevel vs popup configuration in a more clear way.
This makes GtkTextLineDisplay use GRcBox instead of g_slice_*
directly. By using reference counting for this structure, we
can ensure that we hold an extra ref for one_display_cache as
well as caching additional GtkTextLineDisplay for the visible
range in the future.
Update the cached text style when a css change affects
content or background. This fixes text views drawing
black-on-dark when switching to the dark theme.
This removes the use of GtkTextDisplay (a PangoRenderer) to use
the GskPangoRender which generates render nodes. Part of this means
improving the GskPangoRenderer to support the necessary features for
displaying a GtkTextView.
Primarily, this is a merging of GtkTextDisplay features into
GskPangoRender. Additionally, GtkTextDisplay was removed to allow for
gtk_text_layout_snapshot() to be implemented elsewhere.
This was previously removed because it changes the minimum and natural
size of the entry when the icons are shown/hidden at runtime. Just not
measuring them does not work however, so reintroduce this.
This reverts commit 2ed533c3e1.
This also made the filechooser dialog not save the window size anymore,
which does not depend on the gtk_window_get_position() removal.
... when going between recent and browse. It just looks weird to have
this transition while the treeview model is just cleared/repopulated
without any transition.
GMountOperation now supports options to unlock TCRYPT volumes. This
patch sets these options if they are returned by AskPassword() of a
GtkMountOperationHandlerProxy.
This avoids "overlinking". These libraries are an implementation detail
of particular backends, so they only need to appear on library consumers'
linker command-lines if the dependency cannot be picked up from the
shared library automatically (when linking statically, or when building
on a deficient OS that doesn't support transitive dependencies between
shared libraries, in which case pkg-config should be built with
--enable-indirect-deps).
Signed-off-by: Simon McVittie <smcv@debian.org>
When unreffing the stream from a different thread, the close function
will schedule its cleanup asynchornously in the main thread.
We need to make sure the stream object stays alive for as long as
that hasn't happened, so ref() it.
Fixes#2003
This allows custom titles to use the vertical alignment of their choice
without having to set it manually after it has been added to the header
bar, hence allowing them to define their preferred alignment from a UI
template.
This is useful for widgets like the view switcher which requires filling
the header bar's whole height.
Instead of the toplevel driving popups, have the popups listen to the
frame clock themselves. Otherwise, if the toplevel for some reason isn't
drawn by the compositor and stops drawing new frames, popups wouldn't
get painted either.
To make a frame clock tick as long as any of the associated surfaces
expect to receive ticks, make the surfaces inhibit freezing the clock,
instead of directly tell the frame clock to freeze itself.
This makes it so that as long as any surface using a certain frame clock
is not frozen (e.g. just received a frame event from the display
server), the frame clock will not be frozen.
With this, the frame clock is initiated as frozen, and won't be thawed
until any surface inhibits freeze. It will be frozen again, when every
surface has that previously inhibited freeze uninhibited freeze.
The code previously forgot to include the left child of the model's
node. Which of course only happened if that child wasn't NULL, which is
a common case.
Found and test provided by Matthias Clasen.
We were looking for the cups headers and the cups lib in the default locations
which for example breaks with OpenBSD where the cups headers are under /usr/local/include/
Instead just use the "cups" dependency type from meson which internally uses cups-config.
See #1967
Ported to master from !963
httpGetAuthString() was added with cups 1.3 and we depend on a newer version
now. The direct field access was a fallback in case httpGetAuthString()
was missing, so this can also be dropped.
Ported to master from !938
Instead of playing games with mapping negative symbolic values to
positive ones, let's use the appropriate constants everywhere. This
allows us to use:
GTK_CONSTRAINT_STRENGTH_WEAK * 2
Or
GTK_CONSTRAINT_STRENGTH_STRONG + 1
In code using the public API.
We also store the strength values as integers, so we can compare them
properly, and only turn them into doubles when they are inserted into
the solver, just like every other variable.
The strength for the natural width can be used
as a tie-breaker to make instable systems behave
in a more predictable way. This can be seen
in the simple constraints demo in gtk-demo.
Only constraint the opposite direction if we
actually have a for_size, and measure natural
size after removing the edit constraints. With
these changes, the test that compares constraint
layout to grid layout passes.
It makes more sense to treat the natural size
of both children and guides as stays, since
we want to meet these values as closely as we
can, under the circumstances.
Set up all constraints for minimum + natural
width + height when measuring, regardless
of the orientation we're measuring. Anything
else will lead to incorrect answers when
there are constraints that cut across
dimensions.
Make the 'repeat edit' test make more than to
suggestions in a single edit phase. It turns out
that this does not work, whereas just doing
two in a row does.
This commit moves GtkConstraintGuide into its own
source files to avoid gtkconstraintlayout.c turning
too messy, adds max size properties and implements
getters and setters.
GtkPopoverMenus should mimic menus. Commit d936967b7a introduced
some CSS related to menu popovers, however, it hardcodes 'white'
as the background color. That is problematic for the dark theme.
Use '$menu_color' instead of 'white', since $menu_color both
guarantees menu popovers and menus match, and already handles
different colors for dark and light theme variants.
We cannot use the given "for size" when querying our children, because
the constraint layout has no idea about the opposite size of its
children until the layout is complete.
Additionally, we should only suggest an opposite size for the layout if
we have one, instead of suggesting a weak zero size.
The size constraints are transient to measurement and allocation, so
they don't really need to be stored inside the GtkLayoutChild subclass
created by a GtkConstraintLayout.
The relations between left, right, width
and top, bottom, height are required for
internal consistency. It doesn't make sense
to ever drop these.
Changing the strength of these relations makes
my systems behave much more stable.
When the solver is finalized with existing
constraints, we end up with criticals when
the constraints ref finalize code calls
back into the hash table. Avoid that by
emptying the hash table beforehand.
We don't expect out of tree implementations of GtkRoot, and having the
interface structure private to the GTK code allows us to add virtual
functions involving private types.
GtkConstraintSolver is an implementation of the Cassowary constraint
solving algorithm:
http://constraints.cs.washington.edu/cassowary/
The Cassowary method allows to incrementally solve a tableau of linear
equations, in the form of:
x = y × coefficient + constant
with different weights, or strengths, applied to each one.
These equations can be used to describe constraints applied to a layout
of UI elements, which allows layout managers using the Cassowary method
to quickly, and efficiently, lay out widgets in complex relations
between themselves and their parent container.
I've seen a crash when the action muxer gets
disposed during widget destroy, and tries to
disconnect from widget signals too late.
There is no real need to disconnect, since the
only time an action muxer is going away is when
its widget is destroyed, so just don't do it.
E.g. anything involving a scale. This is important when e.g. scrolling
in the node list in the recorder, which scales every recorded node down
to fit in the list.
I recently turned gtk_widget_activate_action()
into a varargs function. That is more convenient
from C, but we need a non-varargs variant for
bindings. So add the old API back, under the
name gtk_widget_activate_action_variant(),
with a rename-to annotation.
The xdg_output v2 interface has a `name` property that reflects the
output name coming from the compositor.
This is the closest thing we can get to a connector name.
The migration from GdkScreen's monitor API to GdkMonitor left out a way
to get the connector's name of a monitor.
While there's no real guarantee coming from the underlying graphics
system that the connector's name is stable, some system components may
use it to uniquely identify a monitor until the next plug in/out event.
We need to create a muxer eagerly for every
widget that has class actions, since those
are otherwise missed in the action lookup
on the muxer side. But otherwise, there is
no reason to create parent muxers aggressively,
as long as we update the parent muxers on
root/unroot.
This reduces the number of muxers we create
in widget-factory from 210 to around 50.
Previously, we would not look any further for
an action once we found a match for the prefix,
defining inheritance by groups. Change this to
inheritance for individual actions, since we
are moving towards individual actions as the
main ingredient in GTKs action support.
The only cases of stateful actions we've seen
so far have been boolean properties, and we
don't really want to add much state handling
API, so lets just go with property actions
for now.
Adapt the only user in GtkText.
along with a new 'type-format' setting that allows
to choose the output format for the "Type" column.
The options implemented for this setting are:
'mime' : Output from g_content_type_get_mime_type().
'description' : Output from g_content_type_get_description().
'category' : It uses the corresponding generic icon
of the mime type to group by categories (aka basic types).
This produces a more compact output than previous options,
and allows for type families to be grouped together, so eg.
after sorting by "Type" column, jpeg and png images will
be placed together, or the various types of archiver files
will also be grouped together.
This format was copied from and currently used by Nautilus
list view, so we also improve consistency with Nautilus.
Bugzilla entry for Nautilus implementation is:
https://bugzilla.gnome.org/show_bug.cgi?id=683722
The list of type families or categories can be checked on:
https://developer.gnome.org/icon-naming-spec/#mimetypes
This 'category' format is set as default.
Issue #362
Some users expect that the Overlay will automatically request enough
size for its overlay children as well as its main child. It doesn't,
because it's just a GtkBin. Add a short paragraph pointing that out.
Close https://gitlab.gnome.org/GNOME/gtk/issues/1939
The only glancing mention of this we had was that GtkButton mentioned it
in passing when discussing how `button` could get contextual classes,
and even that's not relevant in master anymore... so drop it from there.
Port GtkColorChooserWidget to use widget class actions.
Note that this also changes the names of
the GtkColorChooserWidget actions away from a generic
"context" prefix.
Port GtkLinkButton to use widget class actions.
Note that this also changes the names of
the GtkLinkButton actions away from a generic
"context" prefix.
Add a facility to register and install actions
at class init time. The intended use for these
actions is for
a) context and other model-based menus
b) key bindings
Most of these actions are going to be stateless,
so add separate apis for the simple and stateful
cases.
We avoid creating an action group for these by
teaching the action muxer about these actions.
The action muxer also maintains the enabled
state for these actions.
Instead of iterating action groups manually,
just show what the action muxer provides. This
gives an accurate view of what actions are
available in a widgets context, and saves us
the trouble of juggling prefixes manually.
Instead of duplicating this code in multiple places,
add an api to look up an action group for a prefixed
name, and return the unprefixed name at the same time.
This gives us marks to track the duration of processing certain types of
GdkEvent. It also provides some basic struct information in cases where
having that information would likely be useful for debugging.
Page ranges entry can now be focused directly, and will automatically
select the page ranges button when doing so.
This avoids the sometimes counter-intuitive previous behavior where the
entry was automatically focused when toggling the radio button, but the
user may still find themselves clicking uselessly in the text entry
because they scheduled it in their mental model.
Instead, use a new title style class to let
themes influence title formatting. Note that
the theme style will be overridden if the
application uses markup for presentation,
such as <b> or <i>.
Port this from ::populate-popup to the new context
menu api. At the same time, fix some parts of the demo
that were broken since it was changed to use GtkStearchEntry.
Drop the ::populate-popup signal and implement
the new context menu api. Things are a bit more
complicated here, since we have different menus
on links and selectable text.
Menus traditionally don't have separate
hover and focus locations. Make the same
change here that we already did for
popover menubars: Track the active item
and set its selected state. Both keynav
and mouse change the active item.
The Wayland backend has a hack to work around
a race with popover mapping: If the surface size
changes before the initial configure, we hide and
show the surface. Unfortunately, the code was doing
this in a way that is externally observable (by
listening for surface state changes), and popovers
were observing it and hiding themselves in response.
Avoid this by not going through the GDK frontend
code for this.
This solves issues with parent widgets, like combobox
or entry, installing their own bindings for these
keys, overriding the activation behavior that
is implemented in gtkwindow.
This solves issues with parent widgets, like textview
or scrolled window or combobox installing their own
bindings for these keys, overriding the focus behavior
that is implemented in gtkwindow.
Add a convenience api to skip children
that should not be included in the layout,
and call gtk_native_check_resize on all
native children outside of the vfunc.
We can't call gtk_widget_destroy on something
that wasn't added as a child to a container -
it ends up calling gtk_container_remove, which
asserts if it doesn't find the child.
Make gtk_widget_real_focus do the right
thing for focusable widgets with children.
A case where this is (now) relevant is
an entry with a context popover.
Differentiate between wrapping around and
stopping at the end of the focus chain.
Update the existing tests, and add two
new ones where the difference matters.
Add a test that enumerates the focus chain by
emitting move-focus repeatedly, and compares
the result to expected output.
The test expects a ui file and a reference
file as input. The reference file can be created
using the --generate option.
The new rule for focus events from the windowing
system is: We only want them for toplevels. If you
put focus on popups, we don't want to know about
it, and you still need to deliver key events to
the toplevel.
This is expected menu keynav behavior: If the
focused item has a submenu, open it on right
arrow press. And if we are in a submenu title,
make left arrow press close it.
Widgets are supposed to call gtk_widget_child_focus.
Calling internal focus_move function directly makes
us skip the childs ::focus() implementation, which
is where the magic happens.
Make left/right cycle the active item
among the bars children. Separate the styling
for the active item from :hover, since it is
a separate state, and only mixed up in menus
for historical reasons.
Make gtk_popover_new_from_model() return a GtkPopoverMenu,
rename it to gtk_popover_menu_new_from_model() and add
a relative_to argument to gtk_popover_menu_new().
Update all callers.
We can't improve popover menus as long as we
have to be able to work with any old popover
we're given. Remove this, so we can make
gtk_popover_new_from_model return a subclass.
These need to be skipped in measuring,
and we need to call gtk_native_check_resize
on them during allocation.
This was showing up as the new-style
context menu in widget-factory forcing
its relative-to box to grow when its
shown.
We only want to reserve indicator size if
there are any checks or radios in the popover.
Unfortunately, GtkIcon has a hardcoded min-size
of 16, defeating this use. Work around by
wrapping each indicator in a box, and showing/
hiding the actual indicator.
When we are not given an explicit accel (as is
the case when the popover is constructed from
a model), then look it up from the GtkApplication
at map time.
Move checks to the left, and introduce a size group
to align things. The size group is provided by the
parent, using the new ::indicator-size-group property.
This gets us out of using direct presentational
markup like 'inverted' and 'centered' and will
make it easier to play with different layout.
Use the new role when creating popover
menus from models.
We don't need to cover every case with a va_marshaller, but there are a
number of them that are useful because they will often only be connected
to by a single signal handler.
Generally speaking, if I opened into a file to add a va_marshaller, I just
set all of them.
Use the same texture atlases to back both
the glyph and icon caches, and unify their
sizes and management. Store big glyphs
in separate textures, so all atlases have
the same size. Tweak some of the eviction
parameters.
We share the caches across all GL contexts
on a display, unless the GSK_NO_SHARED_CACHES
env var is set.
The logic here seems faulty. We want to keep
a timestamp that tells us when the glyph was
last used, so always update the timestamp.
And whenever we use a glyph, it turns 'young'
again, so remove it from the old pixels
accounting.
The (MAX_AGE, MAX_AGE+CHECK_INTERVAL) interval
is only relevant to prevent us from turning
a cached glyph old more than once, and that
is already taken care of.
It was not copying the terminating \0 in the string, breaking output
in spinbutton (didn't try scale). Fixes#3452.
(cherry picked from commit ae2ef1472c)
This adds specific marshallers for all of the locations where a generic
marshaller is being used. It also provides va_marshallers to reduce the
chances that we get stack traces from perf going through ffi_call_unix64.
This is forward ported from gtk-3-24.
# Conflicts:
# gtk/gtkeventcontrollerkey.c
# gtk/gtkeventcontrollermotion.c
# gtk/gtkgesture.c
# gtk/gtkgesturemultipress.c
If somebody does a transform like
scale(5) scale(10) translate(1,1) translate(5,0)
store it instead as
scale(50) translate(6,1)
This way, less memory is consumed and transforms are easier to read.
In particular, this simplifies the typical transforms we do in GTK,
which are just one translation after another.
We don't need to just look at the scale of the new modelview matrix, but
at the one we get when multiplying the new one with the current one.
Test case attached.
1) In the SetWindowPos() function (and the WINDOWPOS struct) the
"hWndInsertAfter" argument/field means the window that will be
directly above after the change, not the window that will be
directly below. MSDN says "precedes" for SetWindowPos(), but
WINDOWPOS documentation is more precise: this is the window
behind which the affected window will be placed. Apparently,
Z-axis goes back-to-front.
Therefore, logging should be reworded correctly.
2) When we switch away from the application and then switch back
to a transient window, we need to bring up its transient-owner
(and its transient-owner's owner and so forth) as well,
otherwise our transient (modal) window might be transient for
something that might not be visible.
3) When we bring up a window, we should bring all of its children
(popup windows) on top of it.
Because Windows doesn't provide a function to bring one window
on top of the other, we have to work around this by calling
SetWindowPos() twice, swapping the windows between the calls.
Make GtkMenuBar use a box as well,
and let GtkMenuShell get the items
from GtkMenuBar and GtkMenu via
a vfunc. Use that to fix the keynav
implementation in GtkMenuShell.
Similar to previous removals of g_cclosure_marshal_VOID__VOID we can remove
other marshallers for which are a simple G_TYPE_NONE with single parameter.
In those cases, GLib will setup both a c_marshaller and va_marshaller for
us. Before this commit, we would not get a va_marshaller because the
c_marshaller is set.
Related to GNOME/Initiatives#10
The CSS transform should operate on the border-box, not the margin box.
So we need to shrink the bounds by the margin before we apply the CSS
transform.
Use cairo-script-interpreter to parse the scripts that generate cairo
nodes.
This requires libcairoscriptinterpreter.so to work properly, but if
it isn't found we disable this (unimportant for normal functioning)
code and just emits a parser warning.
The testsuite requires it however or it will fail.
A new test is included that tests all of this.
This uses the new sysprof-3 ABI to implement the capture writer. It also
uses the statically linked libsysprof-capture-3.a that is provided with
Sysprof for the capture writing to ensure that we do not leak any symbols
nor depend on any additional libraries.
The GTK_TRACE_FD can be used to pass a FD for tracing into Gtk. Sysprof
uses this when the Gtk instrument is selected for recording.
We were deferring the reflow until map, but this
leads to the section initially having an enormous
height and the window picks up that size before
we have a chance to reflow, This could be seen
in the "Builder" demo in gtk4-demo.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/11
If we set c_marshaller manually, then g_signal_newv() will not setup a
va_marshaller for us. However, if we provide c_marshaller as NULL, it will
setup both the c_marshaller (to g_cclosure_marshal_VOID__VOID) and
va_marshaller (to g_cclosure_marshal_VOID__VOIDv) for us.
With gtk_window_set_position gone, we should never
come up with a new position to set in this code.
Leave a warning in place and remove the gdk_surface_move
calls.
Root coordinates are going away, so this
api does not make sense anymore. Use
gdk_surface_get_device_position instead.
We still keep this as internal api for
root-coordinate using backends.
The X backend was storing global coordinates
in surface->x/y, and keeping the parent-relative
positions in its own fields. Switch this around
to store the relative position in x/y, as is
expected by the frontend.
This function returns the position relative to
the surface parent, so will always return 0 for
non-popups. The out arguments don't need to
allow-none either - nobody passes NULL for these.
We maintain offsets for popups, so we can translate
coordinates between surfaces that are attached directly
or indirectly to the same toplevel. Add an api for that.
Make the transform (transfer full).
1. This makes sure we actually reference the transform. Previously we
did not.
2. Most callers create a new transform to pass to us. Now they don't
have to uref it anymore.
CSS does not do exponents, so printing numbers close to 0 as 1.234e-15
does not work.
Also up the accuracy to 17 digits because that's what everyone else
uses.
GTK4 doesn't have WS_CHILD windows anymore, so hWndParent argument
to CreateWindowEx() is always interpreted as the owner window,
not the parent window.
A window with an owner:
* is above the owner in Z-order
* is destroyed when the owner is destroyed
* is hidden when the owner is minimized
This is enforced by the OS.
GTK can only allow this for popup windows.
Desktop window must never[0] be an owner.
[0]: https://devblogs.microsoft.com/oldnewthing/20040224-00/?p=40493
On Windows that call resizes the native window immediately,
and the corresponding GDK event is emitted and processed
before the control is returned to gtk_window_move_resize().
Therefore, update freeze and configure_request_count increment
must happen before the call, not after it.
Popups can't be active or inactive, so emitting GDK events
in response to WM_ACTIVATE makes no sense for these kinds
of GDK surfaces.
The jury is still out on whether we should block (return 0)
or ignore (don't return anything) this message.
Blocking WM_NCACTIVATE (which we currently ignore) is definitely
not an option - it completely breaks input somehow.
1) Handle GDK_SURFACE_POPUP in RegisterGdkClass()
(for now pretend it's the same as GDK_SURFACE_TOPLEVEL)
2) Remove useless code from GDK_SURFACE_TOPLEVEL case in _gdk_win32_display_create_surface()
(now there's just GDK_SURFACE_TOPLEVEL there, no need for a type check)
3) Have a separate case for GDK_SURFACE_POPUP and ensure that
it doesn't get WS_CHILDWINDOW (and neither should GDK_SURFACE_TEMP).
We were queuing an allocation whenever
the popover is flipped over, unnecessarily,
since we don't change the size of the surface.
This was showing up as popovers being invisible
when flipped over, under X.
There is no need for popups to connect to the frame
clock to pause and unpause events on the display -
the toplevel already does it.
And don't connect to paint either - handle paint
on popups recursively.
Somewhat change the order of initialization (to be closer
to what Wayland backend does).
Also remove the wrapper field that is no longer needed -
it used to hold a pointer to the main GdkWindow instance,
which wrapped GdkWin32ImplWindow. Since impls are gone,
nothing is wrapping anything anymore.
Fix a substitution error, where wrong pointer was added
to the hash table. Added a comment to ensure that future readers
(including myself) won't be confused by the fact that we're
inserting a pointer instead of the handle itself.
Since we are now sharing frame clocks with multiple
surfaces, we can no longer dispose them unconditionally
when a surface goes away. Only do it if we are a
toplevel (without parent).
This was showing up as criticals on exit when opening
and closing any popover in widget factory.
Now that popups share the frame clock of their
parent, we have to be much more careful about
freezing the clock, since that may stop updates
for another surface.
This commit makes two changes that make the
X11 handling of the frame clock more similar
to the Wayland backend:
- Use gdk_surface_freeze_updates instead of
gdk_surface_freeze_toplevel_updates to avoid
affecting the frame clock
- Bail out early in before_paint/after_paint
if the surface is frozen, to avoid affecting
the frame clock
Together, these two make the X11 popup surface
type work without freezing updates for the toplevel.
With separate clocks, the phases are not coordinated,
which messes with GTKs size allocation machinery treating
the entire widget tree as a whole, and causes us to
run into assertion where popups get drawn before they
are allocated.
Call gtk_native_check_resize() from size_allocate,
as is required now. This gets volume buttons closer
to working again (dragging the slider still doesn't
work).
I can't think of a case where this is the desired
behavior. So, instead of setting an explicit cursor
on all popups, just stop walking the parents at
surface boundaries.
When a GtkNative widget is marked as resize_needed,
we need a current position for its parent and we need
the parent to be allocated (so we can position our
surface), but we don't need the parent to be marked
as resize_needed, since the parent size is entirely
independent of the popup size.
When we print warnings about a widget, using
gtk_widget_get_name() is slightly better than
G_OBJECT_TYPE_NAME(), since it will give us
the widgets unique name when available.
This api is meant to mimic xdg-popover.grab - we
show the surface, and dismiss it when we get events
on other surfaces. For foreign surfaces, the compositor
handles that for us; for our own, we check outselves
before delivering events to GTK.
Make them use o-r windows, and move
with their parent.
We do a sort-of ok job on stacking order
here - whenever the parent window gets a
ConfigureNotify, we just restack all popups
directly on top of their parent. This is good
enough to keep popups on top of their parent
while we drag it around, and it gets the popup
to disappear when raising another window on
top of the parent.
Store popup parents separately from transient-for
parents, since these are separate concepts with
different behaviors. And we need the parent in
the frontend, so we can use it in the fallback
move-to-rect implementation.
We don't need the complicated wrapper system anymore,
since client-side windows are gone. This commit moves
all the vfuncs to GtkSurfaceClass, and changes the
backends to just derive their surface implementation
from GdkSurface.
We want to use a gdk_surface_new_popup for popups,
and align the constructor names with the surface
types, so rename
gdk_surface_new_popup -> gdk_surface_new_temp
gdk_surface_new_popup_full -> gdk_surface_new_popup
The temp surface type will disappear eventually.
All the information in it is already contained
in the surface object we pass along, and none
of the backend implementations were using the
attributes at all.
We are not creating such surfaces anymore, and
they were only ever meaningfully implemented
on X11. Drop the concept, and the api for determining
if a surface is input-only.
We still need to keep the vfunc around, since the
fallback implementation of gdk_display_get_monitor_at_surface
uses it. So, a GDK backend must either have root coordinates
or always return a monitor from monitor_at_surface.
We still need to keep the vfunc around, since the
fallback implementation for move_to_rect uses it.
So, a GDK backend must either have root coordinates
or implement move_to_rect.
This lets us remove a use of GTK_WINDOW_POPUP,
which should eventually be going away.
We need to disable treeview search, since it
creates a toplevel that will disrupt our grabbing
popup, causing it to be dismissed.
We don't need to grab ourselves, since the popover
code does it for us. We don't need to reposition our
window, since the popover takes care of that too.
Start by adding a constructor. We have to call it
gdk_surface_new_popup_full for now, since gdk_surface_new_popup
is taken. This may be reshuffled later.
Now that roots can have parent widgets, we need to
carefully examine all calls of gtk_widget_get_toplevel,
and replace them with gtk_widget_get_root if we want
the nearest root, and not the ultimate end of the parent
chain.
... when a window gets hidden and later reshown.
The code now properly cleans up a window when it gets unmapped instead
of trying to retain previous updates information.
The 'documentation' option also guarded the man page build. Instead
if skipping the whole docs subdir skip the specific gtkdoc calls, so that the
man page build still works.
This brings it in line with the gtk3 meson build.
The “xdg-output” protocol provides clients with the outputs size and
position in compositor coordinates, and does not provide the output
scale which is already provided by the core “wl_output” protocol.
So when receiving the wl_output scale event, we should update the scale
regardless of “xdg-output” support, otherwise the scale will remain to
its default value of 1 and the surface will be scaled up by the
compositor to match the actual output scale, which causes blurry fonts
and widgets.
Fixes: https://gitlab.gnome.org/GNOME/gtk/issues/1901
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
The code interprets NULL to mean 'create a new Adjustment and use that,
deposing the old one', but we neither documented nor annotated that
ability, so users could be unsure how to "unlink" a specific Adjustment.
While users could pass their own Adjustment in if this wasn't nullable,
we already support NULL in the code, and it doesn't hurt to document
that this is available as a convenience while retaining the behaviour.
GdkAtom is a typedef to a pointer to an opaque structure. We need to
tell GTK-Doc how to override it, so that the documentation is accurate.
Fixes: #302
We blindly assume everywhere that a single glyph will definitely fit on
one atlas, but that's not always the case.
For now, don't crash or produce GL errors.
The GTK_DISPLAY_DEBUG_CHECK macro will cleverly only call the function
if any of the display debug flags are set, so in the common case it
won't even be executed.
Test that rendering empty nodes succees. For a lot of nodes the
resulting rendering isn't clearly defined, in those cases we overdraw
those regions (sometimes the whole image) with black.
- Remove remains of g_test_*() functions
We're not a glib test, we're a simple binary.
- Handle nonexistence of reference image properly
Don't assert, but create the output image and the error out.
Instead of only allowing for glyph indexes, allow ASCII characters as
replacements. So this glyph sequence
glyphs: 65 8, 66 8, 67 8
Can be replaced by
glyphs: "ABC"
provided that the glyph for "A", "B" and "C" are 65, 66 and 67
respectively and their advance is exactly 8.
x offset and y offset must always be 0 and every glyph must start a
cluster.
Update to the docs outlined in #1887.
In particular, the changes do:
1. Require no property, have a working default for everything
2. Be clear about what gets printed and how.
Tests ahve been adapted to still pass.
Base the rewrite on testsuite/css/parser/test-css-parser - we now
require the node file to match a reference node and track the errors it
triggers.
We also no longer use gtester.
When printing, behave the same way as when parsing:
Magically skip a container node if there is one - just like the
parser magically creates a container node to hold all the nodes
it parses.
We can't just pretend we have an identity matrix when we are actually
scaling. This fixes the node editor sometimes not drawing things when
rendering to a texture. We were mistakenly discaring render nodes
because the bounds transformation was wrong.
Ensure that the class structs of all subclassable
types have sufficient padding (standardizing on 8
slots, here).
GtkBox
GtkButton
GtkDrawingArea
GtkFixed
GtkFrame
Ensure that the class structs of all subclassable
types have sufficient padding (standardizing on 8
slots, here).
GtkApplication
GtkWidget
GtkContainer
GtkWindow
GtkDialog
GtkApplicationWindow
GtkToolItem
GtkBin
The change to keep some server resources around
until destroy was causing us to not recreate
the right things when a surface is hidden and
then shown again. Make sure to recreate everything.
The Wayland backend was dropping _all_ serverside
resources on hide, which is too early e.g. for
GtkGLArea which wants to use egl resources to
unload textures on unrealize.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1485
This is not an api we want to propagate anymore.
If you need to, you can still emit the "clicked"
action signal on a button using g_signal_emit_by_name.
We need to store the region *before* adding our own damage area, because
we want to only store the changes of this frame, not the whole history.
So do it in the same place Vulkan does it.
Fixes#1900
Make GtkMenuButton a widget that has a
toggle button, instead of deriving from it.
We give it icon-name and label properties,
to let people do what they expect to do
with menu buttons.
We stuff both gl-drawn and cairo-drawn textures into the same cache, so
we can't really assume that we need to draw any of them flipped or not.
Fix this by drawing fallback stuff upside down and then using
upside-down vertex data for everything.
Fixes#1897
I don't want to install a new set of bindings every time someone
attaches a reproducer to a bug. I also don't want to rewrite sait
reproducer in C every time just to eliminate the possibility of broken
bindings.
We were adding incomplete frame timings to the
profile, which lead to occasional nonsense
numbers. Instead, only add timings to the profile
once we marked them as complete. This also
gives us an opportunity to add the presentation
time as a marker.
If we want the model items to be listmodels, we don't need to do a ==
comparison. We need to do g_type_is_a(). Implementations of listmodels
are obviously fine.
Besides requiring it at build time, require that the server the client
is running against exposes the XInput2 protocol. We no longer fallback
on a device manager for core events.
XInput2 is more than a decade old already, and the input improvements
there (and in every other backend really) make it untenable to have
support for X11 core input events dragging things behind.
This fixes a long standing bug in pid_get_parent on OpenBSD (which was mine
so... my fault). kp wasn't properly allocated and the function could return
random failures.
The key controller was consuming key events
for modifier keys, for no entirely convincing
reason, which leads to problems when somebody
actually listens for those, such as the simple
input method does for C-S-u processing.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1884
There are two ways GTK can add a headerbar to a dialog:
- the dialog is constructed with the :use-header-bar property
- all windows should use client-side decorations
In the first case, the headerbar is added by GtkDialog with no
dedicated style class, and in the latter by GtkWindow with the
"default-decoration" style.
As a result, dialogs with plain titlebars can end up with clearly
distinct and inconsistent styles.
To address this, allow headerbars to track whether they should use
the "default-decoration" style and enable it for dialogs.
https://gitlab.gnome.org/GNOME/gtk/merge_requests/836
We don't want to return a GFile because GFile can't handle can't deal
with data: urls.
That makes the code a bit more complicated that doesn't deal with those
URLs, but it makes the other code actually work.
GtkCssImageUrl also now decodes data urls immediately instead of only at
the first load. So don't use data urls if you care about performance.
When we're at the end of a block and gtk_css_parser_get_token() returns
NULL, gtk_css_parser_commit_token() still consumed the next token.
It does not anymore.
This does not affect the CSS parser, but it exposes issues with the
render parser, which previously just consumed too many closing } tokens
in the past.
The calls used old bugzilla URLs and nobody cared about that.
So apparently they are very unused.
There's also a potential conflict between gitlab and bugzilla URLs and
what base bug to use there.
The old usages have been converted to comments.
Instead of encoding the raw data, encode the full image to a PNG.
And instead of stuffing that encoding into a string, use a full
data: url.
And then remove the width and height properties, because they're now
implicitly included in the data.
And then change the parser to match.
And because the parser now parses regular urls on top of data: urls, we
can now load any random file.
When looking for versioned theme files, we were
looking for directories names gtk-4.x for x
bigger than 14, which mades sense for GTK 3,
but we are starting out at 0 again, so remove
this check.
GdkSurface::set_startup_id() is NULL on Win32 and would cause a segfault
if called.
While the documentation of the main caller of set_startup_id(),
gtk_window_set_startup_id(), mentions that it's not implemented on
Windows it can still be automatically called via Glade and simply doing
nothing on Win32 is going to be less disruptive than a segfault.
If SYSPROF_TRACE_FD is set in the environment,
interpret it as an fd to write profiling data
to.
If GTK_TRACE is set, write profiling data
to a file with name gtk.$PID.syscap.
This is writing data in the capture format of sysprof,
using the SpCaptureWriter. For now, this is using a
vendored copy of libsysprof. Eventually, we want to
use the static library that sysprof provides.
The http* family of functions was deprecated after CUPS 1.7. We can
conditionally use it when built against a newer version of CUPS. The
additional parameters are taken directly from the fallback values
inside CUPS itself.
The inspector, and other tools introspecting the widget structure like
gtk-builder-tool and Glade, may very well want to access the default
layout manager used by a class, especially if there are layout
properties involved, without having a whitelist of widget/layout manager
associations.
Some widgets have a well-defined layout manager created alongside their
own instance; if they do, we can handle the layout manager creation at
the GtkWidget instantiation.
The default value of GtkWidget::visible changed
from FALSE to TRUE from GTK 3 to 4. Make --3to4
deal with this by ensuring the visible property
is explicitly set, before simplifying.
This adds a test tool gsk/node-parser that takes node files and parses
them.
A few of these node files have been added, for crashes I encountered while
developing the new parsing code.
Instead of the previous approach using GVariant, this new approach uses
human-readable text files as the serialization format for render nodes.
The format is a custom one, but it is inspired by QML and conforms to
the CSS syntax. Because of that, we can use the CSS machinery from GTK
to parse it, and in particular share code to parse properties that GTK's
CSS machinery also supports, such as colors.
This commit breaks all existing usages of node files - such as the
testsuite and various test tools - they will be fixed in further
commits.
We were using one Emoji chooser when triggered
via the context menu, and another one when
triggered via the icon.
Change things to always use the same Emoji
chooser instance.
We had code in gtkwindow.c that generated duplicate,
and defective, focus-change events, in the following
way:
- gtkmain.c generates a chain of focus-change events
for moving focus from one window to another
- gtkwindow.c catches a focus-in event in the middle
of this chain and sets itself as 'active'
- and then it proceeds to generate focus-change
events towards its own focus widget without a
related target
This is not necessary since we gtkmain.c already
generates a complete sequence of focus-change events.
So stop doing it.
This property has a 'smart' default that depends
on the class of the object we're creating. Take
that into account when deciding whether to omit
properties that are set to their default value.
If the recent section is empty, we want to hide
it, make its button insensitive, and select the
next section, initially. This was not working
properly, since nothing was ever setting the
section box to invisible.
It takes half a second on my system to initially
populate the Emoji chooser. That is too long. Do
the work in 8 millisecond chunks to give GTK a
chance to get some frames done.
Change the way we compute border color cutoffs to the same method that
browsers use. This method does not consider the corner sizes at all and
only looks at border-width.
Previously, when borders were too big - ie when a 100x100 rect had only
one 100x100 border, like the black part of ◔ - and then shrinking this
rect by 25px on either side, we'd end up with a 50x50 rect with a 75x75
border, and that's obviously not correct.
We were hardcoding that GtkApplicationWindow only
has a single action group with prefix 'win', but
that is no longer the case. Simply use the code
for the general widget case that can handle multiple
action groups.
I was a little overzealous when going
for the new default handling here. We
can't switch to gtk_widget_activate_default
before we actually handle the default.activate
action.
Display changes now happen exclusively through
the ::root and ::unroot vfuncs. Third parties
can observe display changes by listening
for notify::root.
Export gtk_widget_root/unroot privately,
make them work on roots, and use them in
gtk_window_set_display. This gets us to a
single way to listen for display changes,
the root property.
Currently, we sometimes emit display-changed
when the display changed, and sometimes we don't
since the display is changed via gtk_widget_root.
Listen for notify::root as well and update our
display. This is a temporary fix - all display
changes should go through gtk_widget_root,
eventually.
apis that takes multiple display-relative objects
should make sure that they are all from the same
display, or hard-to-track-down badness will happen
later on.
Add such a check for the surface and device arguments
of gdk_seat_grab. This helped in tracking down
critical warnings from combo boxes in the inspector.
The specification for border-radius goes
top-left top-right bottom-right bottom-left.
The css for the add button in the color
chooser got this wrong, and was showing
a broken top-right corner.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1856
We are now getting focus-out and focus-in events
when the Emoji chooser is shown and hidden, and
this is causing the text to select-on-entry before
inserting the Emoji, which then deletes the selection.
Avoid this by saving and restoring the selection
when presenting the Emoji chooser.
That a property can't be set does not mean
its value can't change. This was showing up
as the cursor-position and selection-bound
properties in GtkText not showing their
current value in the inspector.
When a modal dialog is smaller than its parent,
we were keeping the resize cursor from the dialogs
edge all over the parent window, which looks
really irritating, since the resize cursors are
closely associated with the window edge. Fix
this by falling back to the default cursor
outside the grab widgets surface.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/23
We don't support that setting life-updating anyway. So, instead of
getting the value *every time we format a time*, get it once for the
filechooserwidget and reuse that value.
The spinbutton>button>image is currently blue when the image is clicked
and dark-ish when the button is clicked(but not the image). This was not
the case before since we didn't even propagate :active down to the image
child. Fix this by only applying the blue color to direct image children
of entries.
The old default of 148px doesn't work everywhere. Instead, pick a
default value of -1 and measure() the sidebar widget in the
filechooserwidget in that case. Other values >= 0 are still handled as
before.
Leave it to the ::hits-added handler to switch to the list of search
hits. This way we don't get a weird transition when the current search
didn't have any hits and the next one doesn't either.
Searches with hits still feel good.
Now that GdkSurface has properties, it makes
sense to turn the frame clock into one too.
This will make it easier to reshuffle some
of the surface constructors later.
Set the cursor on the surface of the target
widget, not the surface of some of its parents.
This does not make a difference currently.
But it will in the future, when we have
parented widgets with surfaces.
Make find_grab_input_seat return a GdkWaylandSeat
instead of a struct wl_seat, so we can use it and
avoid calling gdk_display_get_default_seat when
we need to get a serial later.
Floating point values cannot ever be compared for equality. GLib has a
G_APPROX_VALUE macro that lets us compare two value within a provided
precision, so we should use that instead.
Artisanal, homegrown, locally sourced, vegan reference counting has been
replaced by the appropriate API in GLib, which does small things like
saturation and type checking.
The default widget is mostly a dialog concept,
and does not really need this generic api.
If you need to mark a widget as default,
use gtk_window_set_default() directly.
We used to handle has-default specially in ui
files. It was awkward, so stop doing that. If you
need to influence the default widget in a window,
you can just set the default-widget property.
Instead, use the new way of activating default.
I think most of the default handling in
GtkFileChooserDialog should be dropped, but
for now this keeps things working.
Activating this action will replace other
activate_default apis. It is more flexible,
since intermediate widgets can intercept the
action and do their own handling.
This api wasn't used anywhere in GTK. And since
we've dropped the variant for the default widget,
this one should go too. If it is needed, it should
become and action too.
We used to handle has-focus in ui files specially.
It was awkward, so stop doing that. If you need
to influence the initial focus of a window, you
can just set the focus-widget property.
When hitting Escape in the location entry,
we were not moving the focus anywhere,
causing focus to be NULL, and key bindings
to stop working. The visible effect was
that Ctrl-L / Escape / Ctrl-L would not
get back to the location entry, as expected.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1851
When hitting Escape, the file chooser will go
into search mode, because the search entry
consumes the key to emit the ::search-stopped
signal. Recognize this situation and avoid
switching to search mode in this case.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1850
The primary icon is on the right in RTL, so don't offset the text child
to the right for it.
Fixes the text and icon overlapping in the second entry
in tests/testentryicons
It doesn't make sense to keep track of all the last_* values anymore now
that widgets only get allocated when their size changes anyway.
Remove all the associated (and thus now unused) flags as well.
We were forwarding key events to the search entry
and unconditionally considered search started
afterwards. That is not correct, since things
like a Ctrl key press should not trigger search.
Fix this by only switching to search mode when
the event was actually consumed.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1829
The key capture was interfering with other
entries in the dialog, so be smarter about
when we want to capture keys and when we
don't.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1842
Apparently genTextures and friends only "reserves names", initializing
them will actually create them. Using glObjectLabel on textures before
initializing them will throw a GL_INVALID_VALUE error.
Previously, the GDK backend for Wayland would deduce the logical size
of the monitors from the wl_output size and scale.
With the addition of fractional scaling which advertises a larger scale
value and then scale down the client surface, the computed logical size
of the monitors in GDK would be wrong and confuse applications which
insist on using the monitor size and position (like Firefox).
The xdg-output protocol aims at describing outputs in a way which is more
in line with the concept of an output on desktop oriented systems by
presenting the outputs using their logical size and position appropriately
transformed.
Add support for the optional xdg-output protocol so that the size and
position of the monitors as reported by GDK is correct even when using
fractional scaling.
Fixes: https://gitlab.gnome.org/GNOME/gtk/issues/1828
Remove old fine-tune marks style, add margins for fine-tune marks to
compensate trough growth, prevent horizontal fine-tune trough growth in
horizontal direction, prevent vertical fine-tune trough growth in
vertical direction.
Closes https://gitlab.gnome.org/GNOME/gtk/issues/1799
We preiously did not apply the resizes and moves as they were previously
only done in the Cairo drawing context on Win32. Fix this by applying
this too in the GL drawing context.
Make gdk_win32_surface_get_queued_window_rect() and
gdk_win32_surface_apply_queued_move_resize() not static functions, as we
want to use them in gdkglcontext-win32.c, to fix resizing and moving.
2019-04-01 14:51:13 +08:00
1304 changed files with 170779 additions and 110318 deletions
GtkWidget*w=gtk_label_new("pLorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua.");
378|GTK+ and friends|GTKtoolkit|#GNUStep gets #GTK+ theming http://is.gd/95vHl more at http://is.gd/95wt8|1267029498|0||0|1
379|GTK+ and friends|GTKtoolkit|GTK+ 2.19.6 released: http://mail.gnome.org/archives/gtk-devel-list/2010-February/msg00050.html #gtk|1266966985|0||0|0
380|GTK+ and friends|GTKtoolkit|Did you know that #GTK+ is the official toolkit for the #LiMo software stack? http://bit.ly/cuEdHx|1266925406|0||0|0
381|GTK+ and friends|GTKtoolkit|@lmedinas publishes a #javascript #example on how to put an status icon with #Gtk+ http://bit.ly/9py1uC Thanks a lot Luis!|1266886644|0||1|1
381|GTK+ and friends|GTKtoolkit|@lmedinas publishes a #javascript #example on how to put a status icon with #Gtk+ http://bit.ly/9py1uC Thanks a lot Luis!|1266886644|0||1|1
382|GTK+ and friends|GTKtoolkit|♺ @ebassi: I should really finish up the GDom API as well|1266880653|0||0|0
383|GTK+ and friends|GTKtoolkit|♺ @ebassi: I hope to work on this for the next GIO release, and the GTK+ side for 3.0|1266880641|0||0|0
384|GTK+ and friends|GTKtoolkit|♺ @ebassi: just updated the ApplicationClass design wiki page with the stuff @Cwiiis did for Mx - http://bit.ly/cfAOJk|1266880559|0||0|0
<property name="label">Render using Cairo renderer</property>
<layout>
<property name="top-attach">1</property>
<property name="left-attach">0</property>
<property name="column-span">2</property>
</layout>
</object>
</child>
<child>
<object class="GtkLabel">
<property name="wrap">1</property>
<property name="label"><i>There will be a .node and a .png file placed in the testsuite/gsk/compare directory. <b>You need to add it to the meson.build yourself.</b></i></property>
controllers</link> that are attached with %GTK_PHASE_CAPTURE
get a chance to react to the event.
</para>
<para>
After the “capture” phase, the widget that was intended to be the
destination of the event will run gestures attached to it with
%GTK_PHASE_TARGET. This is known as the “target” phase, and only
happens on that widget.
destination of the event will run event controllers attached to
it with %GTK_PHASE_TARGET. This is known as the “target” phase,
and only happens on that widget.
</para>
<para>
Next, the #GtkWidget::event signal is emitted.
Handling these signals was the primary way to handle input in GTK widgets
before gestures were introduced. The signal is emitted from
the target widget up to the top-level, as part of the “bubble” phase.
In the last phase (the “bubble” phase), the event is delivered
to each widget from the target to the top-most, and event
controllers attached with %GTK_PHASE_BUBBLE are run.
</para>
<para>
The default handlers for the event signals send the event
to gestures that are attached with %GTK_PHASE_BUBBLE. Therefore,
gestures in the “bubble” phase are only used if the widget does
not have its own event handlers, or takes care to chain up to the
default #GtkWidget handlers.
Events are not delivered to a widget which is insensitive or
unmapped.
</para>
<para>
Events are not delivered to a widget which is insensitive or unmapped.
</para>
<para>
Any time during the propagation phase, a widget may indicate that a
received event was consumed and propagation should therefore be stopped.
In traditional event handlers, this is hinted by returning %GDK_EVENT_STOP.
If gestures are used, this may happen when the widget tells the gesture
to claim the event touch sequence (or the pointer events) for its own. See the
"gesture states" section below to know more of the latter.
Any time during the propagation phase, a controller may indicate
that a received event was consumed and propagation should
therefore be stopped. If gestures are used, this may happen
when the gesture claims the event touch sequence (or the
pointer events) for its own. See the “gesture states” section
below to learn more about gestures and sequences.
</para>
</refsect2>
@@ -183,27 +175,10 @@
<title>Touch events</title>
<para>
Touch events are emitted as events of type %GDK_TOUCH_BEGIN, %GDK_TOUCH_UPDATE or
%GDK_TOUCH_END, those events contain an “event sequence” that univocally identifies
the physical touch until it is lifted from the device.
</para>
<para>
On some windowing platforms, multitouch devices perform pointer emulation, this works
by granting a “pointer emulating” hint to one of the currently interacting touch
sequences, which will be reported on every #GdkEventTouch event from that sequence. By
default, if a widget didn't request touch events by setting %GDK_TOUCH_MASK on its
event mask and didn't override #GtkWidget::touch-event, GTK will transform these
“pointer emulating” events into semantically similar #GdkEventButton and #GdkEventMotion
events. Depending on %GDK_TOUCH_MASK being in the event mask or not, non-pointer-emulating
sequences could still trigger gestures or just get filtered out, regardless of the widget
not handling those directly.
</para>
<para>
If the widget sets %GDK_TOUCH_MASK on its event mask and doesn't chain up on
#GtkWidget::touch-event, only touch events will be received, and no pointer emulation
will be performed.
Touch events are emitted as events of type %GDK_TOUCH_BEGIN,
%GDK_TOUCH_UPDATE or %GDK_TOUCH_END, those events contain an
“event sequence” that univocally identifies the physical touch
until it is lifted from the device.
</para>
</refsect2>
@@ -211,43 +186,66 @@
<title>Grabs</title>
<para>
Grabs are a method to claim all input events from a device, they happen
either implicitly on pointer and touch devices, or explicitly. Implicit grabs
happen on user interaction, when a #GdkEventButtonPress happens, all events from
then on, until after the corresponding #GdkEventButtonRelease, will be reported
to the widget that got the first event. Likewise, on touch events, every
#GdkEventSequence will deliver only events to the widget that received its
%GDK_TOUCH_BEGIN event.
Grabs are a method to claim all input events from a device,
they happen either implicitly on pointer and touch devices,
or explicitly. Implicit grabs happen on user interaction, when
a #GdkEventButtonPress happens, all events from then on, until
after the corresponding #GdkEventButtonRelease, will be reported
to the widget that got the first event. Likewise, on touch events,
every #GdkEventSequence will deliver only events to the widget
that received its %GDK_TOUCH_BEGIN event.
</para>
<para>
Explicit grabs happen programatically (both activation and deactivation),
and can be either system-wide (GDK grabs) or application-wide (GTK grabs).
On the windowing platforms that support it, GDK grabs will prevent any
interaction with any other application/window/widget than the grabbing one,
whereas GTK grabs will be effective only within the application (across all
its windows), still allowing for interaction with other applications.
Explicit grabs happen programatically (both activation and
deactivation), and can be either system-wide (GDK grabs) or
application-wide (GTK grabs). On the windowing platforms that
support it, GDK grabs will prevent any interactionwith any other
application/window/widget than the grabbing one, whereas GTK grabs
will be effective only within the application (across all its
windows), still allowing for interaction with other applications.
</para>
<para>
But one important aspect of grabs is that they may potentially happen at any
point somewhere else, even while the pointer/touch device is already grabbed.
This makes it necessary for widgets to handle the cancellation of any ongoing
interaction. Depending on whether a GTK or GDK grab is causing this, the
widget will respectively receive a #GtkWidget::grab-notify signal, or a
But one important aspect of grabs is that they may potentially
happen at any point somewhere else, even while the pointer/touch
device is already grabbed. This makes it necessary for widgets to
handle the cancellation of any ongoing interaction. Depending on
whether a GTK or GDK grab is causing this, the widget will
respectively receive a #GtkWidget::grab-notify signal, or a
#GdkEventGrabBroken event.
</para>
<para>
On gestures, these signals are handled automatically, causing the gesture
to cancel all tracked pointer/touch events, and signal the end of recognition.
On gestures, these signals are handled automatically, causing the
gesture to cancel all tracked pointer/touch events, and signal
the end of recognition.
</para>
</refsect2>
<refsect2>
<title>Keyboard input</title>
<!-- focus, tab, directional navigation -->
<para>
Every #GtkWindow maintains a single focus location (in
the ::focus-widget property). The focus widget is the
target widget for key events sent to the window. Only
widgets which have ::can-focus set to %TRUE can become
the focus. Typically these are input controls such as
entries or text fields, but e.g. buttons can take the
focus too.
</para>
<para>
Input widgets can be given the focus by clicking on them,
but focus can also be moved around with certain key
events (this is known as “keyboard navigation”). GTK
reserves the Tab key to move the focus to the next location,
and Shift-Tab to move it back to the previous one. In addition
many containers allow “directional navigation” with the
arrow keys.
</para>
<!-- mnemonics, accelerators, bindings -->
</refsect2>
@@ -255,37 +253,43 @@
<title>Event controllers and gestures</title>
<para>
Event controllers are standalone objects that can perform specific actions
upon received #GdkEvents. These are tied to a #GtkWidget, and can be told of
the event propagation phase at which they will manage the events.
Event controllers are standalone objects that can perform
specific actions upon received #GdkEvents. These are tied
to a #GtkWidget, and can be told of the event propagation
phase at which they will manage the events.
</para>
<para>
Gestures are a set of specific controllers that are prepared to handle pointer
and/or touch events, each gestures implementation attempts to recognize specific
actions out the received events, notifying of the state/progress accordingly to
let the widget react to those. On multi-touch gestures, every interacting touch
sequence will be tracked independently.
Gestures are a set of specific controllers that are prepared
to handle pointer and/or touch events, each gesture
implementation attempts to recognize specific actions out the
received events, notifying of the state/progress accordingly to
let the widget react to those. On multi-touch gestures, every
interacting touch sequence will be tracked independently.
</para>
<para>
Being gestures “simple” units, it is not uncommon to tie several together to
perform higher level actions, grouped gestures handle the same event sequences
simultaneously, and those sequences share a same state across all grouped
Since gestures are “simple” units, it is not uncommon to tie
several together to perform higher level actions, grouped
gestures handle the same event sequences simultaneously, and
those sequences share a same state across all grouped
gestures. Some examples of grouping may be:
<simplelist>
<member>
A “drag” and a “swipe” gestures may want grouping. The former will report
events as the dragging happens, the latter will tell the swipe X/Y velocities
only after gesture has finished.
A “drag” and a “swipe” gestures may want grouping.
The former will report events as the dragging happens,
the latter will tell the swipe X/Y velocities only after
recognition has finished.
</member>
<member>
Grouping a “drag” gesture with a “pan” gesture will only effectively allow
dragging in the panning orientation, as both gestures share state.
Grouping a “drag” gesture with a “pan” gesture will only
effectively allow dragging in the panning orientation, as
both gestures share state.
</member>
<member>
If “press” and “long press” are wanted simultaneously, those would need grouping.
If “press” and “long press” are wanted simultaneously,
those would need grouping.
</member>
</simplelist>
</para>
@@ -294,34 +298,39 @@
<refsect2>
<title>Gesture states</title>
<para>
Gestures have a notion of “state” for each individual touch sequence. When events
from a touch sequence are first received, the touch sequence will have “none” state,
this means the touch sequence is being handled by the gesture to possibly trigger
Gestures have a notion of “state” for each individual touch
sequence. When events from a touch sequence are first received,
the touch sequence will have “none” state, this means the touch
sequence is being handled by the gesture to possibly trigger
actions, but the event propagation will not be stopped.
</para>
<para>
When the gesture enters recognition, or at a later point in time, the widget may
choose to claim the touch sequences (individually or as a group), hence stopping
event propagation after the event is run through every gesture in that widget and
propagation phase. Anytime this happens, the touch sequences are cancelled downwards
the propagation chain, to let these know that no further events will be sent.
When the gesture enters recognition, or at a later point in time,
the widget may choose to claim the touch sequences (individually
or as a group), hence stopping event propagation after the event
is run through every gesture in that widget and propagation phase.
Anytime this happens, the touch sequences are cancelled downwards
the propagation chain, to let these know that no further events
will be sent.
</para>
<para>
Alternatively, or at a later point in time, the widget may choose to deny the touch
sequences, thus letting those go through again in event propagation. When this happens
in the capture phase, and if there are no other claiming gestures in the widget,
Alternatively, or at a later point in time, the widget may choose
to deny the touch sequences, thus letting those go through again
in event propagation. When this happens in the capture phase, and
if there are no other claiming gestures in the widget,
a %GDK_TOUCH_BEGIN/%GDK_BUTTON_PRESS event will be emulated and
propagated downwards, in order to preserve consistency.
</para>
<para>
Grouped gestures always share the same state for a given touch sequence, so setting
the state on one does transfer the state to the others. They also are mutually exclusive,
within a widget there may be only one gesture group claiming a given sequence. If
another gesture group claims later that same sequence, the first group will deny the
sequence.
Grouped gestures always share the same state for a given touch
sequence, so setting the state on one does transfer the state to
the others. They also are mutually exclusive, within a widget
there may be only one gesture group claiming a given sequence.
If another gesture group claims later that same sequence, the
first group will deny the sequence.
</para>
</refsect2>
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.