This reinstates diffing in the same way that it worked for offset nodes.
It would be possible to add diffing for affine transforms or even all
transforms, but I think this is unnecessary right now - and also quite
expensive to compute.
Make the API expect a tranform of the proper category instead of
doing the check ourselves and returning TRUE/FALSE.
The benefit is that the mai use case is switch (transform->category)
statements and in those we know the category and don't need to check
TRUE/FALSE.
Using the wrong matrix will now cause a g_warning().
... instead of computing it every time we need it.
This should be faster and we want to use it a lot more prominently.
Also, we have the struct memory available anyway.
In particular, check that to_matrix() and to_2d(), to_affine() and
to_translate() return the same values.
This also requires a recent Graphene version or the tests will fail.
In particular, add a per-category querying API for the matrix:
- gsk_transform_to_translate()
- gsk_transform_to_affine()
- gsk_transform_to_2d()
- gsk_transform_to_matrix()
This way, code can use the relevant one for the given category.
In case the theme doesn't set a height/min-height for the treeview
separator the treeview drawing gets confused and draws rows on top of each
other depending on the redraw area.
This is due to gtk_tree_view_get_row_height() assuming that a node with a
height <= 0 is not set and not a separator and it will default to the
expander size.
Ideally gtk_tree_view_get_row_height() would know if it operates on a separator,
but there are too many calls/levels, so just make sure the separator height
is at least 1 (Adwaita already sets "min-height: 2px", so no change there)
Cherry-picked from !614 to master
Picking is done by drawing a line along the parent's z axis and picking
at the intersection with the child's z=0 plane.
However, the previous code was casting a ray along the child's z axis.
This patch actually transforms the line to pick into the target's
coordinate system and then computes the corrrect intersection with the
z=0 plane.
Using graphene_point3d_interpolate() to compute the final intersection
point is a bit of abuse of that function, but I found no better way in
Graphene to achieve the same thing.
Since we can do partial redraws, dropping every shadow that's been
unused for one frame happens too fast. This is also a problem when a
shadow gets drawn on a texture for a few frames.
This can happen for certain transform nodes. The transform node's
child's bounds are fine, but the transform node bounds are all nan.
Just ignore those bounds since we can't meaningfully render them anyway.
If the given matrix is explicitly of category IDENTITY, we don't need to
do anything, and in the 2D_TRANSLATE case, just offset the child bounds.
Those are the two most common cases.
While *some* systems alias python to python3 nowdays, this is
not true for eveything. Especially systems that can potentially
offer both python2 and python3.
According to both PEP 394 and PEP 441 its recommended to always
add the 3 in the shebang.
After considerable discussion, we came to the conclusion
that the convenience of this API wins over the correctness
of gtk_window_present_with_time(), in particular since we
don't have a good mechanism to carry timestamps from the
events to the places where we present windows.
When 0 or GDK_CURRENT_TIME is passed to gtk_window_present_with_time(),
print a warning so that the application developer knows that this isn't
a supported use of the function, but carry on working for now.
Instead of using a grab on a GtkInvisible, use
a hook in the GTK event propagation machinery to
get events.
The only downside of this approach is that we
lose the crosshair cursor. But we get rid of
the last use of GtkInvisible.
Change gdk_surface_get/set_user_data to private
API and rename them to get/set_widget.
Also remove an unused associated function.
The last two places where the surface API is used
are in gtkroot.c and gtkwidget.c. Make them
use the private api.
This was broken by the change in 01f7f255b5 which
caused the inspector to not get any events anymore.
Revert that part, even though it may be technically
correct.
This is a first cut at updating the drawing model chapter
for the way we do things now. It introduces the scene graph and
render nodes, explains node caching and tree diffing, and removes
sections about subwindows.
This avoids invalidating the size of all widgets when updating CSS
transforms.
In theory, we don't even have to allocate the widget itself, because we
didn't change its size. But we have no way to track that.
Instead of gtk_snapshot_offset(), provide a full set of functions
kept in sync with GtkTransform APIs.
On top of that, add gtk_snapshot_save() and gtk_snapshot_restore()
mirroring cairo_save()/restore() that allow saving a snapshot's
transform state.
The code didn't change, it was just shuffled around to make the
with_bounds() versions of the text rendering unnecessary and instead
pass through the generic append_node() path.
Instead of just tracking 2 integer translate_x/y coordinates, tracka a
full GtkTransform.
When creating actual nodes, if the transform is simple enough, just
create the node in a way that makes use of the transform. If the
node, can't represent the transform, just push a transform node instead
and automatically pop that node with the next gtk_snapshot_pop() call.
They were a neat idea while they lasted. But now, it's time for
categorized transform nodes, where matrices with
GSK_MATRIX_CATEGORY_2D_TRANSLATE are the exact replacement.
Renderers have not been adapted for this purpose, so they (continue to)
run slow paths.
This is a new object (well, boxed type, but I'm calling it object) for
dealing with transform in a more constructive way than graphene_matrix_t
by keeping track of how the transform was created.
This way, reasoning about the transform becomes easier, and we can create
better ways to print it or transition from one transform to another one.
An example of this is that while a 0 degree and a 360degree rotation are
both the identity matrix, doing a transition between the two would cause
a rotation.
Don't leave memory in an unitinialized case when returning FALSE from
gtk_widget_compute_transform().
We both know that people are going to call that function without
checking the return value.
Use a GtkText child, and delegate the editable functionality
to it. Also forward all the properties that are provided by
GtkText.
Some of the more internal APIs, such as layout and im context
access and caps-lock warning, are removed here, but we preserve
most of the plain GtkEntry API by forwarding it to the GtkText
child.
With transforms in the mix, checking if the coordinate is inside the
widget "allocation" makes even less sense. Just use gtk_widget_pick()
and walk up until we find a GtkFlowBoxChild.
This is the same as the old code since the transformation only contains
teh offset right now, but it will be different later where arbitrary
transformations are possible per widget.
The transform matrix is a translation matrix from the parent's origin to
the widget origin. We will later allow more transformations than just
translations.
Instead of style + rect_of_one_box, pass the new GtkCssBoxes object.
This has the nice side effect that when drawing background + border +
outline, we only compute all the boxes we need once.
Previously, those numbers stored the values relative to the margin box
of the widget. Now they store values relative to the content box,
thereby getting rid of the last remains of weird coordinate systems.
Split out the code for computing CSS boxes from given variables from the
background render code. This way, it can be shared between different
codebases.
Also, make that code completely be contained of static inline functions.
That ensures that it can be 100% inlined in cases where only parts of
the rectangle are needed (like in gtk_widget_get_width() in the future).
This will require some more patches to actually work, but those will
follow.
This way, we can compare with literally the previous allocation and the
size will not be influenced by an adjusted allocation.
But more importantly, we can now use the transform/width/height values
for other stuff.
It's not priv->transform (to be turned into a graphene matrix),
priv->width and priv->height.
The numbers are still the same.
The only difference is that unallocated widgets will now have x/y set to
0, not to -1.
Make items-changed never emit 2 signals, instead, always emit only one,
potentially by extending the range reported in items-changed.
And be a lot more exhaustive about autoselect tests.
1. Do not make position an inout variable
The function is meant to return a range for a given position, not modify
a position. So it makes no conceptual sense to use an inout variable.
2. Pass the selected state as an out variable
Using a boolean return value - in particular in an interface full of
boolean return values - makes the return value intuitively feel like a
success/failure return. Using an out variable clarifies the usage.
3. Allow passing every position value
Define what happens when position >= list.n_items
4. Clarify the docs about how this function should behave
In particular, mention the case from point (3)
5. Add more tests
Again, (3) needs testing.
We need to remove the weak pointer, as the stack switcher can
keep the list model alive beyond the stack. This was observed
to cause crashes:
==16870== Invalid write of size 8
==16870== at 0x5168A4E: g_nullify_pointer (gutils.c:2284)
==16870== by 0x522C500: weak_refs_notify (gobject.c:2791)
==16870== by 0x50FE7BC: g_data_set_internal (gdataset.c:407)
==16870== by 0x50FECA7: g_datalist_id_set_data_full (gdataset.c:670)
==16870== by 0x5227EB4: g_object_real_dispose (gobject.c:1056)
==16870== by 0x522D295: g_object_unref (gobject.c:3309)
==16870== by 0x4AF849F: unset_stack (gtkstackswitcher.c:428)
==16870== by 0x4AF892E: gtk_stack_switcher_dispose (gtkstackswitcher.c:527)
Ironically, these properties are too good - they always
give you a proper value, which is unfortunately different
from the declared default value, which is NULL. So, don't
check these.
It is easy to emit wrong ::selection-changed signals,
and then bad things will usually happen later. Add
some sanity checks to gtk_selection_model_selection_changed
to make this easier to track down.
Make GtkStackSidebar and GtkStack communicate via
the selection model that GtkStack now exposes.
This is parallel to the GtkStackSwitcher changes
in the previous commit.
The first set of glyphs is created with a timestamp of 1. Later we
subtract the glyph timestamp from the cache timestamp, meaning we end up
with numbers ending in 9, e.g. 59. Now unfortunately !(60 <= 59), so we
do not end up incrasing the old_pixels count of the cache. Later we then
call lookup() and DEcrease the old_pixels count, which makes the
unsigned int wrap and cause a huge old_pixels value, which causes us to
drop the cache.
If the recoloring would end up multiplying the alpha component with 0
anyway, just skip drawing anything altogether.
This increases the icon count in the switch demo of the fishbowl from
~260 to ~280 on my system.
Specifically it is avoided to be toggled if:
- Just received focus (in order to preserve OSK state across focus changes)
- Moving cursor around. Still allow some jitter as perfect accuracy is not
possible.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1277
We were looking at the wrong class names here, we need
to look at the owner type to match against our list.
This fixes problems where gtk-builder-tool simplify
inadvertedly loses hexpand or vexpand settings, messing
up layout, as recently happend in gtk4-widget-factory.
Instead of adding them and waiting for the changed signal to be emitted
in the main loop, there might be a race where the change signal is
emitted before we have a chance of spinning the loop.
Rewrite the builder-tool simplify command to have
a full parse tree around, and perform simplifications
on that tree. This lets us rewrite GtkStack and turn
child properties into child meta objects.
In addition to <property name="foo">bar</property> referring
to an object with ID bar, we now also parse
<property name="foo"><object>...
to specify a property 'inline'.
The change to make widgets visible by default broke GtkInvisibles
special-cased state handling and that in turn caused picking in
the inspector to break with another recent change.
This change makes the inspector pick button work again.
This is necessary to give back focus to the Broadway elements when
content is embedded in an IFrame.
Signed-off-by: Mickael Istria <mistria@redhat.com>
Since we position the tooltip window relative to the toplevel widget and
not actually relative to the effective_toplevel, we shouldn't get the
pointer position relative to the effective_toplevel.
We previously used the pointer position (relative to the
effective_toplevel) and the anchor rect (relative to the toplevel
widget) together to calculate x_distance. This leads to wrong values in
cases where get_surface (new_tooltip_widget) != get_surface (toplevel)
Fixes#1427 in master
The event_widget is the widget that the surface belongs to which got
this event. The target widget is the one that will receive the event.
The previous terminology was confusing.
The @filename@ directive will use the full path of the file being parsed
for enumeration types; we should use @basename@, instead, as it improves
the reproducibility of the build by using only the file name.
Commit bd71e744d2 removed
gtk_box_pack_end(), but it added a gtk_container_add() with an
uninitialised widget, and the compiler is very unhappy about it.
Without this, disabling a widget that's being hovered and is a child
widget of the widget we're disabling (e.g. the GtkImage child of a
GtkButton) will retain its :hover state even though it should be
insensitive to any sort of input now.
Change the reorder api to insert after a sibling,
so that moving to first place becomes reorder (... NULL).
And add a insert_after api that can replace the common
container_add / reorder_after (... NULL) combination.
Update all callers.
The position child property is problematic, since it
requires us to emit notification for all children when
inserting a child early in the list of children.
Remove the property from all ui files.
GtkWidget saves a widget list for us, so we don't need to keep track of
them ourselves. This is okay now that we don't have a pack-type child
property anymore.
Some of the flags got lost in the meson transition or were demoted from
error flags to warning flags.
This commit reintroduces them.
It also includes fixes for the code that had warnings with those flags.
The big one being -Wshadow.
Remove the unneeded is_platform() check and just go by extension point
priority.
Also g_error() out if no im module exists, because "simple" is compiled
in and should always exist.
All built-in backend modules get a priority of 0 because they are the
default ones.
GtkIMContextSimple gets a priority of G_MININT because it's the fallback
one.
This mirrors the media modules code.
The format of the printout will be suitable for addition as a new test to
testsuite/gtk/rbtree-crash.c
by just grepping the printouts from the relevant rbtree.
We need to tell the portal what filter is supposed to be selected by
default, or it will just pick the first one, which could be wrong and
annoying.
This will require updated xdg-desktop-portal and xdg-desktop-portal-gtk
to work properly.
Fixes#1492
gtk_file_chooser_set_filter() doesn't work for GtkFileChooserNative. The
code forwards added and removed filters to the delegate dialog, but
doesn't do anything to set the selected one, so the wrong one gets
chosen. So fix that.
This only fixes the fallback dialog. The portal will be fixed in a
subsequent commit.
Partial fix for #1492
Instead of using the INCLUDE directive inside the sections file, we can
specify the default C include in the gtkdoc-mkdb arguments, and override
it inside the C sources that need it.
This gives us a better way of choosing the color of the placeholder text
(and enabled general css styling on it of course).
Closes#378 (If you want to keep the placeholder on focused and empty
entries, just don't set the placeholder opacity to 0 in
entry:focus>placeholder. This is the default behavior but this commit
includes a rule in Adwaita to hide it.
Since we now have a widget whenever we query tooltips, we can as well
get the events target_widget if we have an event (which is what we do
when coming from gtkmain.c). This keeps us from searching the entire
widget hierarchy for the target event even though we've already done
that for pointing events in gtkmain.c
This reduced the work done in gtk_tooltip_handle_event in normal motion
events to basically nothing since we already did all the heavy lifting
when handling the pointing event in gtkmain.c
As stated by the documentation, this should be called when a widget gets
updated, but in that case, one can equally use
gtk_widget_trigger_tooltip_query.
Setting it as qdata on the object doesn't save any memory since we use
the user_data as the event target, which every event has set these days.
This way is also faster since just reffing the object doesn't do any
locking.
If the text style changes, or the display settings do, we need to update
the state labels to ensure that the glyphs are available in the font
we're using.
The entire color scale hack is still done in GtkRange, which draws the
color scale in the range gizmo. So, to correctly redraw the color scale
when setting a new color, we need to redraw the proper widget and that's
the trough widget.
Fixes#1453
Instead of recording the way up from the target widget to the grab
widget (or toplevel) and then walking that path upwards, just walk the
parent chain and look at the cursor.
Most of the time, the GtkSnapshot objects we create while snapshotting
widgets don't end up containing all that many nodes or states in their
respective node or state stack. This undermines the amortized allocation
behavior of the G(Ptr)Array we use for the stacks. So instead, use the
(until now unused) parent_snapshot GtkSnapshot* passed to
gtk_widget_create_render_node and reuse its node and state stack.
We do not avoid allocating a new GtkSnapshot object, but we do avoid
allocating a ton of G(Ptr)Array objects and we also avoid realloc'ing
their storage.
Even though the IEC power glyphs are part of Unicode 9.0 (released in
2016) not all fonts have them.
To avoid showing the hexbox of doom when the system font does not have
the glyphs we'd like to use, add a fallback pair, using the old glyphs
we suggested when the labels were translatable.
The refactoring of automatically updating tree->root when setting a
node's parent works very well - unless all nodes get removed and no
node's parent got updated.
The tree is not needed to walk around the nodes.
It is however still needed for anything that requires modifying the
tree.
There is no immediate benefit in changing this API, but there might be
situations in the future where we can avoid looking up the tree when we
just want to check some details about the node.
Store a link to the tree in the root node. This allows looking up the
tree in O(log N) from the node without any extra memory usage.
This is useful because code can just store a pointer to the node and
doesn't need to keep the tree pointer around. And that can (for large
trees) save quite a bit of memory.
Searching through the tree is too specific to use a general function.
All the existing code just copies and slightly adapts the same 20 lines
instead, so there's no reason to keep the complicated API.
This broke the overlay blur demoe when resizing the window to a size
that would completely move the image below a button, causing the
GtkSnapshot code to remove the clip node below the blur node.
Considering the operations that some of the rendernode constructors
do, nodes with width or height 0 (or both of course) are very well
possible. This would break in the rendernodepaintable when adding a
transform, which divides by width/height of the rendernode.
We'd like the rose picture to be bigger than 16×16. Also remove the
scrolledwindow since the GtkPicture now automatically scales down the
rose image. This also fixes the picture always being allocated at y=0.
This can happen whenever the ::activate-link handler sets different
markup on the label, causing all links to be recreated. In this case,
the GtkLabelLink* passed to emit_activate_link is garbage after the
g_signal_emit call and we shouldn't try to do anything with it.
Fixes#1498
Unicode 9.0 introduced glyps for the "on" and "off" power states, in the
form of:
- U+23FD POWER ON SYMBOL, or ⏽
- U+2B58 HEAVY CIRCLE, or ⭘
With `HEAVY CIRCLE` as "power off symbol" selected to avoid adding yet
another circle to the standard.
Since we moved GtkSwitch to always show glyphs instead of (translatable)
strings, asking the localisation teams to either come up with a suitable
short string to replace the English "ON" and "OFF", or to fall back to
Unicode glyphs, we should ensure we're using the appropriate symbols to
begin with.
See also: gtk!503 for the corresponding gtk-3-24 change.
Signal emittion was added in 6f857f87dc commit and it seems that
this is only place where selected_row is set after emitting signal.
Because of this gtk_list_box_get_selected_row currently returns NULL
as selected row if selection mode is set to GTK_SELECTION_BROWSE.
Using an empty `configuration_data` object to copy a configuration file
is deprecated since Meson 0.47 (released July 2018); the equivalent
behaviour is available by using `copy: true`.
The target position is irrelevant for determining if the child should be
visible. When the current position is 0, it needs to be hidden, period.
Fixes#1355
The previous fixes made it unnecessary to hardcode IM modules for
different display types. The code now automatically skips system IM
modules for other displays.
The code would technically allow loading the xim module when X11 support
was not compiled in.
This is probably an artificial concern, because it's pretty hard to
compile XIM support without X11 support, but it makes the code clearer,
so there we go.
Context IDs are dependant on the display - both because displays can use
different backends, but also because changing the GtkSetting is a
per-display operation.
So just remove the cache.
If it turns out we need a per-display cache, we can add one to
GtkSettings.
Calling the accessibility function `grab_focus()` on a `GtkCell` under
Wayland will cause the client to crash.
This is another case of `gdk_x11_get_server_time()` being called
regardless of the actual windowing backend used.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1507
So it's able to operate properly with the DnD gesture set by
gtk_drag_source_set(). We usually just react on button release,
that's the right time to claim the gesture.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1557
I was stuck in an X session and noticed that my resize corners
all got east or north cursors. It turns out that gnome-shell
does not properly advertise support for edge constraints under X11,
and the absence of that makes the code for determining the edge
under the cursor misbehave.
This change should fix that.
So we can check that the currently set clip is the first one and now
intersect with it. This first clip is always the entire viewport or the
entire render_area and we don't want to end up drawing things to a
texture because of it.
Link to the GitLab documentation, and clarify that if no single commit
in a merge requests closes an issue, you should add a reference to the
issue in the commit message anyway.
This is an important document for newcomers, so we should err on the
side of being more detailed on what kind of contributions we expect,
and how we expect them.
The text is heavily modelled on the contributing-template by Nadia
Eghbal available here:
https://github.com/nayafia/contributing-template
g-ir-scanner incorrectly evaluates macro definition that include
references to other macro definitions. Provide a correct value as an
annotation.
Differences in generated gir files:
```diff
@@ -19017 +19017 @@
- <constant name="PRIORITY_REDRAW" value="20" c:type="GDK_PRIORITY_REDRAW">
+ <constant name="PRIORITY_REDRAW" value="120" c:type="GDK_PRIORITY_REDRAW">
@@ -74229,3 +74229,3 @@
</constant>
- <constant name="PRIORITY_RESIZE" value="10" c:type="GTK_PRIORITY_RESIZE">
+ <constant name="PRIORITY_RESIZE" value="110" c:type="GTK_PRIORITY_RESIZE">
<doc xml:space="preserve">Use this priority for functionality related to size allocation.
@@ -106786,3 +106786,3 @@
<constant name="TEXT_VIEW_PRIORITY_VALIDATE"
- value="5"
+ value="125"
c:type="GTK_TEXT_VIEW_PRIORITY_VALIDATE">
```
See !472
If the revealer is told do animate and then unrealize itself, we do
(correctly) stop the animation, but used to do a shortcut where we
just set the target state as current.
Other things are dependent on the animation properly finishing though,
like the contained widget child visibility. This may lead to inconsistent
state where gtk_revealer_get_child_revealed() returns TRUE but the child
widget is unmapped, or vice-versa.
Fully finish the animation here, so the child state is coherent the next
time the revealer is mapped. We can also skip notifying on the property
since it will be handled by gtk_revealer_set_position().
Tools on the same physical item have the same serial number, so the eraser
and the pen part of a single pen share that serial number. With the current
lookup code, we'll always return whichever tool comes first into proximity.
Change the code to use the hw id in addition to the serial number, this way we
can differ between two tools.
Generic tools (Bamboo, built-in tablets) always have the same serial number
assigned by the wacom driver. This includes the touch tool when the wacom
driver handles the touch evdev node (common where users require the wacom
gestures to work).
When the first device is the touch device, a tool is created with that serial.
All future tools now return the touch tool on lookup since they all share the
same serial number. Worse, this happens *across* devices, so the pen
event node gets assigned the touch tool because they all have the same serial.
Since we don't actually care about the touch as a tool, let's skip any unknown
tool. This captures pads as well.
Any wacom device currently sets the tool type to UNKNOWN. The wacom driver has
a property that exports the tool type as one of stylus, eraser, cursor, pad or
touch. Only three of those are useful here but that's better than having all
of them as unknown.
Before this patch, imwayland would assume that text-input enter and leave events follow the general (wl_keyboard) focus, and was unable to handle the situation where they would not be provided at the same time.
Fixes terminal emulator misbehaviour as outlined in https://gitlab.gnome.org/GNOME/gtk/issues/1316, which was introduced in 49b17e6c. The original commit cleared preedit text by setting it to an empty string, which still counted as existing preedit. The fix sets preedit string to null, which is correctly understood as not present.
There may be situations where this might get called while the
currently focused context just went away (eg. after setting the
text widget unsensitive).
Closes: #1317
* We don't output spaces anywhere in the code, unlike the doc suggested.
* CSS explicitly forbids whitespace between function names and lparens:
https://stackoverflow.com/questions/13877198
Do not call _gtk_widget_captured_event(), in propagate_event_down(), or
gtk_widget_event(), in propagate_event_up(), when the widget has been
unrealized.
iter_init_common() is used on uninitialized GtkTextIter, and since neither it
nor its callers initiliaze its padding fields, they contain garbage.
This is a problem for Go - which checks that structs passed to C functions do
not contain pointers to Go-allocated memory - when the garbage happens to be
such a pointer. Although Go zero-fills all GtkTextIter that it allocates, this
does not help when GTK functions such as insert_pixbuf_or_widget_segment called
for gtk_text_buffer_create_child_anchor copy garbage from their stack-allocated
GtkTextIter into a clean iter. To work around this a GtkTextIter has to be
discraded after use in text buffer anchor inserting functions:
https://github.com/gotk3/gotk3/pull/307
We display a list of supported protocols in the server_addresses_popover.
However, this curated list contains protocols which may or may not be
available, depending on the respective gvfs backend being installed.
So, populate the list only with protocols which are available.
https://gitlab.gnome.org/GNOME/gtk/issues/1476
When the user types an address with a schema that is not supported,
the Connect button doesn't become sensitive, but there is no visible
feedback at all.
This feels unresponsive and leaves the user clueless.
While it doesn't help explain why the address doesn't work, this will
provide a hint that the input was acknowledged but doesn't work.
https://gitlab.gnome.org/GNOME/gtk/issues/1476
This makes apps use "Segoe UI 9" by default instead of whatever matches "Sans 10".
It also cleans up the code and uses some new pango API while at it.
This was previously disabled in 9e686d1fb5 because it led to a poor glyph coverage
on certain versions of Windows which don't default to "Segoe UI 9" (Chinese, Korean, ..)
because the font fallback list was missing in pango.
This is about to get fixed in https://gitlab.gnome.org/GNOME/pango/merge_requests/34
so enable it again when we detect a new enough pango version.
(See !436 for the original MR)
GTK widgets expect the scroll deltas to be 1 or -1 and calculate a scroll value from that.
Multiplying the delta by the Windows scroll line setting (which defaults to 3) results
in a much larger delta and vastly different behaviour for running a GTK app on Windows
vs on Linux. For example text view and tree view scroll by 9 lines per scroll wheel tick
per default this way while on Linux it is around 3.
Remove the multiplication for now.
See !426 for the gtk3 MR
Enables hinting, antialiasing and set the subpixel orientation according to the
active clear type setting. This ensures that font rendering with the fontconfig backend
looks similar to the win32 backend, at least with the default system font.
See !437
The existing post-install shell script will most likely not work on
Visual Studio builds as there is normally no shell interpreter installed
on the system where the build is done, but the build is normally done in
a standard Windows cmd.exe console.
Instead, use a Python script so that it will work on the platforms that
Python supports.
We need to override _GLIB_EXTERN to export the required symbols for the
GIO module on Visual Studio, so that the media modules can be
successfully loaded.
Build the .rc files for Windows so that one can track the version info
more easily for Windows, as well as giving GTK+ apps a default icon.
Also, move back the manifest embedding for the themed Windows print
dialog back into gtk-win32.rc.body.in, so that we just have one way of
embedding this manifest file, making things easier for ourselves, as
this is supported in the later Visual Studio compilers as well, which is
2013 and later.
Issue #1495 showed that the docs of GtkGrid retain outdated implications
that (as was once, but is no longer, the case) it is intended to replace
GtkBox, by discussing HfW and widget properties in a way that suggests
GtkBox can't handle them. But of course it does, and it's preferable for
simple single-row/column cases. Worse, we said GtkGrid “provides exactly
the same functionality” for the latter case, but the original point of
that Issues was that it doesn’t, at least for CSS positional selectors!
Box:
• Use an actually meaningful @Short_description.
• Remove unhelpful @See_also references to unrelated containers.
• Remove references to “rectangular area”: it might be another shape
via CSS, or “rectangular” might falsely imply 2 dimensions of children.
• Mention Orientable:orientation.
• Emphasise usefulness of :[hv]align for allocating in the other axis.
• Don’t say that Grid “provides exactly the same functionality” for a
single row or column, since (A) it is overkill for that case and (B)
said Issue proved that it *doesn’t* for CSS child order, for example.
Grid:
• Don’t dwell on widget properties and height-for-width in a way that
wrongly implies that Box can’t handle those (or Grid can better). In
fact, just get rid of that bit altogether: Box handles them fine, and
such wording was only needed years ago for migration from GTK+ 2 to 3.
• Point to GtkBox as being preferred for the simple row/column use case.
As per the spec:
> The back buffer can
> either be reported as invalid (has an age of 0) or it may be
> reported to contain the contents from n frames prior to the
> current frame.
So a buffer age of 1 means that the buffer was used in the last frame.
We were handling buffer_age==1 the same as buffer_age==0, i.e. we
returned the full damage for the surface.
[1] https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_buffer_age.txt
Append a variation selector to the Emoji sequences,
to force Emoji presentation. Without this, some
Emoji come out with text presentation by default.
Closes: Pango #334
- step back on toning down the borders. Flatness !> legibility.
- darker active state for light
- draw gradinets from bottom up, to keep px sized shading regardless
of button size.
Instead of getting the translation x/y everytime we use the modelview,
get it once, when extracting the metadata. Do the same with the scale.
And save if the matrix is "simple" at all, i.e. if it only consists of a
translation and/or scale. This will be helpful later when we start
drawing transformed nodes on textures.
Increase the visibility of the box-shadow for menus
Introduce a border-radius variable for menus
Use this variable for all corners of menus except top for the top menus
We wrap SVG data from icons within another SVG with extra styling
information. The wrapped SVG may contain characters that cannot be
part of a data: URL (https://fetch.spec.whatwg.org/#data-urls).
Librsvg 2.45 got more strict in its parsing of data: URLs; whereas
previously it ignored '#' characters in them, now it considers them to
be the start of a fragment identifier, which is not allowed in data:
URLs anyway.
To avoid unallowed characters, we now create a data: URL with a
base-64 encoded SVG.
Fixes https://gitlab.gnome.org/GNOME/gtk/issues/1471
This is important when the target widget of an event is not the one that
would otherwise receive the gesture. For example, the GtkSwitch
implementation currently attaches a pan gesture to the switch itself,
but the target widget below the pointer might be the switch slider or
label.
See #1465
It is permissable to remove a widget using gtk_container_remove from the
gtk_container_foreach callback handler. Document this fact to make it
more discoverable.
Fixes#1461
Currently, gtk_event_controller_scroll_handle_event() always returns
TRUE if it is handled, which stops the propagation of the event. If
there’s a single GtkEventControllerScroll in the widget hierarchy, that
means that no others will run, depending on the propagation phase. In
Nautilus, this can be observed when adding a scroll controller to the
GtkScrolledWindow (ctrl-scrolling controls the zoom level) - either the
scrolling or the zooming breaks.
Fixes https://gitlab.gnome.org/GNOME/gtk/issues/45
Gives the same background color to all separators descending from a
title bar than to its direct childrens.
This prevents separators which are in a titlebar but not direct children
from the widget with the titlebar style class from being almost
transparent and hence it prevent them from revealing the clear color of
the window's titlebar (black).
https://gitlab.gnome.org/GNOME/gtk/issues/1231
This is better than nothing at all. The wording is taken from Carlos's
commit message when he added this shortly before 3.12 (but skip Since).
Skip the bit from his commit message explaining what this replaced; we
don't need to say all the less good things our convenience API replaces.
as per efd3758f6a strcasecmp() is not a C
standard thing (not that we bothered including any header for it anyway)
and so this test failed to build on Windows with Microsoft Visual C.
This is the excellent explanation from Emmanuele at
https://gitlab.gnome.org/GNOME/gtk/merge_requests/402#note_361210:
"
Every time you instantiate a type, the instance_init() function is called for each
parent type T_p of your type T; to preserve invariants, the class pointer inside
the instance data is set to the parent type before each invocation, until you hit
your type T. This means that calling GET_CLASS() inside an instance_init() function
will give you a pointer to the class vtable for the parent type T_p while you're
iterating over parent types. What if you want to access the actual class vtable of
the type T, though? Well, you can because the actual signature of instance_init() is:
void (* GInstanceInitFunc) (GTypeInstance *instance, gpointer g_class);
i.e. all instance_init() functions get passed the instance they are initialising
and the class vtable of the real type you're instantiating.
This is how GtkToolButton works: it "peeks ahead" at instance initialisation time,
to use the button_type class field of the actual type you're instantiating,
and calls g_object_new() with it to store the resulting object in its own private
data structure.
This whole contrived mechanism is needed to allow out-of-tree tool buttons to just
set the button type on their class init, and have their parent class create the
button they want, instead of asking all tool buttons to do this themselves and have
a virtual function called get_button() for GtkToolButton to call whenever it needs
to operate on the button instance.
Now we're coming to a close: we cannot use the G_DEFINE_TYPE macro because the
instance_init() function it creates internally will not pass the class pointer
to your custom instance_init(). Since we cannot use G_DEFINE_TYPE, we also cannot use
G_ADD_PRIVATE either.
This is the reason why, when I ported GTK 3 to the new private instance data structure
macros, I left GtkToolButton alone. I should have left a comment there, because @matthiasc
tried doing that as well, and then had to revert it in commit 1c4a7bd5. So: my bad,
sorry about that.
If we want to drop the G_TYPE_INSTANCE_GET_PRIVATE and the g_type_class_add_private() calls,
we cannot use G_DEFINE_TYPE, but what we can do is unrolling what the macros do themselves:
- add a global GtkToolButton_private_offset variable
- add a static inline gtk_tool_button_get_instance_private() that does return
(G_STRUCT_MEMBER_P (self, GtkToolButton_private_offset));
- call g_type_add_instance_private (g_define_type_id, sizeof (GtkToolButtonPrivate)) inside
gtk_tool_button_get_type() and store the result in GtkToolButton_private_offset
- replace g_type_class_add_private() inside gtk_tool_button_class_init() with
g_type_class_adjust_private_offset (klass, &GtkToolButton_private_offset)
"
When we decide to fall back because the settings portal
is not present, adhere to that decision elsewhere. And
treat the fontconfig-timestamp like the other special-cased
settings, with G_TYPE_NONE.
Under Wayland, we are currently directly using GSettings
for desktop settings. But in a sandbox, we may not have
access to dconf, so this may fail. Use the new settings
portal instead.
As GSettings now supports session-specific defaults, GNOME Classic
no longer uses a separate schema and the decoration layout is always
determined by the regular schema.
This essentially reverts commit add67b516c (although the code was
moved since then).
https://gitlab.gnome.org/GNOME/gtk/merge_requests/400
By returning a default surface. The situation where there's no
currentContext arises when GtkCSS is trying to determine the
layout sizes so no actual display is necessary.
Closes: #1411
Do not lie to W32 about the formats that we provide or accept.
Originally the logic behind such lies was that GdkPixbuf allows us to
convert any supported image to BMP or PNG, and therefore we should
announce that we always provide/accept BMP and PNG along with other
formats.
But that's not how it works. GDK has built-in serializers and
deserializers for all pixbuf formats (where it just invokes GdkPixbuf
API) and will use them automatically to read or write GdkTexture
objects (internally wrapping GdkPixbuf objects where necessary). The
encoding and decoding of images is handled
by GdkContent(De)Serializers, backend has nothing to do with it.
Therefore W32 GDK backend should only offer formats that it can
actually do conversion for by itself (such as image/bmp <-> CF_DIB,
or text/uri-list <-> CFSTR_SHELLIDLIST).
and use 150 as natural-width.
Currently there's no way for a GtkEntry to be less
than 150px wide (apart from using "width-chars" property),
this is too much for a default minimum-width, an app
developer may need to have a shorter GtkEntry, for example
when the UI it's been shrunk by the user (see [1]) or when
you want to match the size of another widget (which is less
than 150px) see [2] for Evince bug on using
gtk_combo_box_new_with_model_and_entry() for PDF forms where
GtkEntry of ComboBox is too wide and doesn't match the combo
list width.
Using "width-chars" property may be a workaround to obtain
a short minimum-width for the entry, but is not a proper
solution for the mentioned cases as you may not know how
short your GtkEntry will be, or the fact that using "chars"
as a width unit is not pixel accurate.
Curious note: the commit that introduced the GtkEntry
minimum-width to be 150px is from 20 years ago, see
https://bit.ly/2ySEfK4
[1] This change was already suggested by Benjamin Otte
in a blog comment https://bit.ly/2J96wRo
[2] Fixes issue evince#1002
- Selection mode does not get the special devel styling.
- removed teh last-child() selector for it doesn't work anymore.
Better style all section of the headerbar than none. Proper fix pending.
https://source.puri.sm/Librem5/libhandy/issues/57
Instead we just cache the monitor number and get
out of it the nsscreen when it is needed. This is
a requirement since it nsscreen it is not supposed
to be cached.
Fixes: https://gitlab.gnome.org/GNOME/gtk/issues/1312
This was noticed in Firefox and demonstrated using a GtkBuilder ui file.
buildable_add_child() calls set_tab_label(), but the latter did nothing
to update the menu_label corresponding to that tab with the new text.
Using Builder to populate the tab child, only tabs other than last got
the right non-default labels, and even that was mostly coincidental, as
adding the main child called update_labels() via real_insert_page(), so
it took effect when the 2nd last main child is added, updating the rest
but leaving the last with the default label, not that given in Builder.
Fix by factoring out the code from child_reordered() to a new helper
menu_item_recreate() and calling that in set_tab_label(), so that
whenever the tab_label is updated, so is its corresponding menu_label.
This fixes the reported case and presumably others that we could write.
fixes https://gitlab.gnome.org/GNOME/gtk/issues/1397
Comments matched to reassure the compiler that fallthrough is
intentional are supposed to precede the case or default keywords, at
least in GCC, so the one here did not suppress the warning with GCC. We
can just the if condition and put the comment at the end to solve that.
https://developers.redhat.com/blog/2017/03/10/wimplicit-fallthrough-in-gcc-7/
This meson port is not upstream yet, so a wrap file is not included.
Upstream has expressed interest but the port hasn't been tested on all
platforms yet. Will be added when it gets upstreamed.
Link to WIP port: https://github.com/centricular/harfbuzz
We do this for every single node, which is a little costly, especially
since the common case for the modelview matrix these days is a simple
translation. So, check whether the new modelview matrix is only a
translation matrix and if so, don't do a full matrix multiplication per
node.
Commit 64a489ad inadvertently introduced a regression that broke Korean
text input because the changes there resulted that only the last input
string that we have from ImmGetCompositionStringW() for each time the
commit signal is emitted is kept, and also as a result the final Korean
character that is input by hitting space is also lost as a result, as we
didn't check for whether we are done with preediting.
Fix these issues by doing the following when we receive the
WM_IME_COMPOSITION message with GCS_RESULTSTR from Windows:
-Do not emit the commit signal during WM_IME_ENDCOMPOSITION, and...
-Emit the commit signal anyways, as we did before c255ba68, however...
-We still save up the string to commit, because we need to re-compute
the cursor position when we do ->get_preedit_string(), which needs to
take the GCS_RESULTSTR string we get from WM_IME_COMPOSITION into
account as well, so that we avoid getting the Pango criticals that
occur during Chinese (and most likely Japanese) input as the cursor
position is out-of-range.
Fixes issue #1350.
The previous type was a pointer to a pointer, which seems to be a copy-paste
error from GtkBuildable.custom_tag_start which is an out parameter. It was
always cast in use so this is an API break, but not an ABI one.
This leverages the normal input context switching mechanism in GTK
by making it think that the gtk-im-module setting changed.
The backend returns gtk-im-module value as "ime" if W32
IME API says that an IME is in use. Otherwise it returns
and empty string - this still triggers an input context
switching code, which, not being able to create the desired context
(which is and empty string), falls back to looking at current
keyboard layout (currently that code is still a FIXME).
Paired with the code that signals gtk-im-module change on keyboard layout
switches, this is sufficient to make GTK capable of switching to
the appropriate IM context at runtime. At least, the kinds of context
that specify languages for which they are used automatically by default
(once locale matching is implemented), and the IME context.
Loading other kinds of IM context might still work via specifying
the gtk-im-module setting in gtk ini file, but doing so will likely
make GTK incapable of using the IME context that is used
for Korean, Chinese and Japanese (and some other languages).
Until someone figures out a way to actually change gtk-im-module
setting on Windows at runtime with meaningful values, the behaviour
introduced by this commit seems like a sufficient workaround.
GNOME Shell 3.32 will remove support for the app menu
so we need to move its contents to the primary (hamburger)
menu.
widget-factory already had a primary menu.
The only item in the app menu was About.
https://gitlab.gnome.org/GNOME/Initiatives/issues/4
The gtk_stack_snapshot_slide() function dereferences the
last_visible_child pointer without proper != NULL ckeck. This might
result in NULL pointer dereference and crash if last_visible_child is
invalid.
Add a != NULL check before dereferencing the pointer.
There’s a short-path done for focus rectangles, but it can be taken in other conditions, and then fail occasionally to render a dashed line if the border-width is too big.
Variable, added, would be a garbage value if model is NULL and
the following code, if condition, use the uninitialized variable.
A side effect could be occurred by that.
To avoid, the variable is initialized to zero.
The executable is called autotestkeywords, so we shouldn't try to run
an executable named keywords. Also rename the metadata file to match.
Signed-off-by: Simon McVittie <smcv@debian.org>
The installed-tests are now namespaced as gtk-4.0 to avoid colliding
with GTK+ 3, but these files weren't updated.
Signed-off-by: Simon McVittie <smcv@debian.org>
After removing elements, there were a few cases where the tree wasn't
properly balanced which could further down violate assumptions about the
layout.
Attached is the original testcase that triggered it. I didn't bother
simplifying it.
Commit 359df028be changed the
code to send GDK_SCROLL_SMOOTH with deltas instead of
GDK_SCROLL_(UP|DOWN|LEFT|RIGHT).
Windows defines deltas inversed for vertical direction
(positive values mean the wheel was turned forward)
but not for horizontal direction
(positive values mean the wheel was turned towards the right).
This commit fixes behavior as both axes were inverted previously.
Commit d64467b334 changed the
code to send GDK_SCROLL_SMOOTH with deltas instead of
GDK_SCROLL_(UP|DOWN|LEFT|RIGHT). Change it again, to send
both the GDK_SCROLL_SMOOTH and the GDK_SCROLL_(UP|DOWN|LEFT|RIGHT)
event separately (with the discrete event marked as emulated),
as this is what other backends (such as wayland) do.
Up until now when allocating the child it only used the natural size
while the measuring also used the minimum size, resulting in a clipped
child when animating if the child had different minimum size and
natural size. This was an obvious case when using labels that had
ellipsization.
This commit gives full allocation to the child by inverting the size
the revealer reduces from its animation progress.
Code done by Benjamin Otte.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/635
The complexity with model items vs row items is really confusing. Add to
that treelistmodel position vs child model position vs parent position,
and you're so confused, even the best naming can't help.
And once you're there, consider passthrough vs non-passthrough...
When passthrough is enabled, it should return the GType
of the child GListModels; when disabled, it should be
GTK_TYPE_TREE_LIST_ROW.
The conditions are inverted however, causing a few
warnings to trigger.
Fix that by returning the correct GType.
Most of the code creating the two types of dialogs (open file,
choose folder) is the same. This refactors the common code into a
helper method. This also makes it easier to add other chooser types
for this test (e.g. save file).
This is way more complicated than it should be, because it requires
manually limiting the number of open file enumerators.
On the other hand, it exhaustively tests the items-changed emission of
all involved listmodels because those signals come in pretty much
randomly.
It's also 50% slower than the sync version, with the caeat that the sync
version only shows the UI after it's done loading, while this version
shows it right away.
This model just takes an object and a property name and recursively
looks it up. In particular, I want it for:
widget, widget.parent, widget.parent.parent, ...
The code gets rid of the GtkTreeView and replaces it with a GtkListBox.
Most of the logic is now done via GListModel subclasses.
A big change is that this new list is now tracking updates itself and
doesn't need to be manually updated. All code that used to cause rescans
or add forgotten objects to the tree has been removed.
If objects are missing from the object tree, the logic for tracking them
needs to be added.
This patch does multiple things:
1. Add a custom persistent per-row object.
2. Move all per-row API to that object. This means notifications are now
possible.
3. Add a "passthrough" construct-only property to the TreeListModel that
influences if the model returns these new object or passes through
the ones from the model.
This greatly simplifies the code needed to be written for widgetry,
because one can just connect the per-row object to the expanders that
expand and collapse rows.
As an added power feature, these objects can also be passed through
further models (like filter models).
It also adds kind of a hack to Adwaita to make the test look neat.
Let separators be declared as sidebars to have the same style as those
drawn by GtkStackSidebar. This also let them handle the selection-mode
class, whether they are assigned it or they descend from something in
selection mode.
Also drop setting the selection mode color for non-sidebar separators.
This is convenient when building a custom sidebar using a GtkSeparator
and to extend a sidebar to the title bar.
This is needed to work around headerbar sliding animation issues without
refactoring Adwaita's support of titlebars and headerbars as it may
break applications.
https://gitlab.gnome.org/GNOME/gtk/issues/1264
This step was missed before, again.
SASS 3.6 emits rgba(0, 0, 0, 0) instead of transparent, so it wants to
change those too, but that patch was only committed in March and isn't
being backported to the previous stable, so I don't know if others'
versions will do the same - so until it's shown that anyone else (A) is
regenerating CSS and (B) also has 3.6, I'm skipping those changes. See:
c287f312ac
A number of applications want to track the state of the screensaver.
Make this information available as a boolean property. We only listen
for state changes when ::register-session is set to TRUE.
This is implemented for unsandboxed D-Bus access by talking
directly to org.gnome.ScreenSaver or org.freedesktop.ScreenSaver,
and for sandboxed D-Bus by using a (new) portal API.
A Quartz implementation is missing.
Currently, GtkRevealer clips the child if the transition type is
sliding, regardless of whether the animation had already ended. An
example where that is a problem would be in Nautilus: the file
operations popover button is animated on reveal to draw attention, but,
given that the button is in turn stashed inside a revealer with a
sliding animation, things suddenly fall apart.
Instead, use a popup and gdk_surface_move_to_rect.
I have not tried to reproduce all details of the old
positioning logic, but moving the popup above/below
the entry works as before.
In order to make tooltip positioning portable, make use of the
move_to_rect API. Some semantical changes are made, as identical
semantics cannot be implemented using the move-to-rect API.
Primarily the implemented semantics are:
Position the tooltip in the center pixels slightly below (defaults to 4
units below) the tooltipped widget. This is always the case for keyboard
driven tooltips; the case where it tries to avoid the pointer cursor is
not implemented.
For pointer position triggered tooltips, implement the following
additional semantics:
Use the current cursor size to determine the padding used to enlarge the
anchor rectangle. This is to try to avoid the cursor overlapping the
tooltip.
If the anchor rectangle is too tall (meaning if we'd be constrained
and flip on the Y axis, it'd flip too far away from the originally
intended position), rely only on the pointer position to position the
tooltip. The approximate pointer cursor rectangle is used as a anchor
rectangle. Ideally we should use the actual pointer cursor rectangle
(image used as well as hotspot coordinate), but we don't have API to
get that information.
If the anchor rectangle isn't to tall, just make sure the tooltip isn't
too far away from the pointer position on the X axis.
Closes: #134Closes: #432Closes: #574Closes: #579Closes: #878
Let's just use the fact that a window was mapped as a subsurface to
remap it above another transient parent instead of relying on the more
complicated 'should-map-as-subsurface' helper function.
Set delta_x or delta_y for GdkScrollEvent.
HIWORD (wParam) in WM_MOUSE(H)WHEEL is the scroll delta.
A delta value of WHEEL_DELTA (which is 120) means scrolling
one full unit of something (for example, a line).
The delta should also be multiplied by the value that the
SystemParametersInfo (SPI_GETWHEELSCROLL(LINES|CHARS), 0, &value, 0)
call gives back, unless it gives back 0xffffffff, in which case
it indicates that scrolling is page- or screen-based, not line-based
(GDK doesn't support that at the moment).
Also, all deltas should be inverted, since MS sends negative deltas
when scrolling down (rotating the wheel back, in the direction of
the user).
With deltas set the mode should be set to GDK_SCROLL_SMOOTH.
Fixes issue 1263.
The intention of this check was to skip the keyword
test if no c++ compiler is found. But the meson
docs say that add_languages() will abort unless we
pass required: false.
because filesystem readdir order is indeterministic.
Without this patch, building openSUSE's balsa package
had variations between builds in /usr/share/balsa/icon-theme.cache
When calling PickColor on org.gnome.Shell, we get back an "a{sv}", which
GDBus provides to us as "(a{sv})".
At the minute we're not unpacking this tuple, and so picking fails with
messages like:
GLib-CRITICAL **: 13:38:19.439: g_variant_lookup_value: assertion 'g_variant_is_of_type (dictionary, G_VARIANT_TYPE ("a{s*}")) || g_variant_is_of_type (dictionary, G_VARIANT_TYPE ("a{o*}"))' failed
Gtk-WARNING **: 13:38:19.439: Picking color failed: No color received
Let's unpack it.
The additional assignment to the old result variable just adds an
indirection even though we know the point where we assign it in all
cases. Just pass the values out and return in those cases instead.
Previously, GtkBin was only snapshot'ing its one and only child, but
nowadays it doesn't implement snapshot at all and the default
implementation in GtkWidget just snapshots all child widgets, which is
exactly what the implementation in gtkmodelbutton.c was doing.
Since the original implementation was likely based on GTK+ 3, the change
in default visibility might have not been considered, which results in
all rows suddenly sporting a visible spinner when opening a fresh file
chooser.
Unparenting a GtkListBoxRow can drop its last reference, which
will free its memory. Right after unparenting, though, we were
accessing the row's iter - which assumes that the row is still
alive. This causes a crash when, for example, binding two or
more models to the listbox.
Fix that by storing the iter in a variable, and not trying to
access it after unparenting. After unparenting, the variables
that are potentially garbage were explicitly assigned NULL for
clarity.
Fixes https://gitlab.gnome.org/GNOME/gtk/issues/1258
bindings now treat identifiers and strings the same way.
The only difference was that one allowed lookup of enum/flags by name
while the other didn't and g_warning()ed. Now both work.
Perform scrollbar visibility checks through a motion controller,
always based on GtkScrolledView-relative coordinates. The captured
event handler remains though, for a tiny bit of GDK_SCROLL event
handling.
Use a distinct key controller so we correctly handle navigation
across matches and search cancellation. As the events are forwarded
to the search_window, those need to be pushed down the entry manually.
CSD titlebar are included in the focus-chain. The logic used makes sure that the
initial focus avoids the titlebar, but tabbing around will eventually get there.
This logic fails in case the window has no other focusable widgets apart from
the ones in the header-bar. If this happens keynav focus will be lost. To handle
the above scenario, we need to fallback to focus the header-bar (if any).
Fixes: https://gitlab.gnome.org/GNOME/gnome-software/issues/404
Drop the drag-highlight and drag surfaces. The highlighting
is broken anyway, so just drop it for now. And for dragging
the header button, we can just position it properly, that
works just as well as this reparenting approach.
This fixes a potential leak of a PangoAttrList that is set when chaining
up to the parent get_preedit_string(). We check to see if the attr list
was created and reuse it instead of leaking the previous value.
Remove gtk_menu_popup_for_device() and gtk_menu_popup(), as they cannot
be implemented in a portable manner by all backends. They have been
deprecated for proper alternative APIs for some time, so lets remove
them now before its too late.
While at it, fix the example documentation for mapping a menu.
This is a temporary measure to make the check-icon-names
test not fail in ci. We still have to figure out the best
way to include a core icontheme with GTK+.
GLib master propagates argument types in g_clear_pointer(), which causes
the usual function pointer casts to GDestroyNotify to trip compiler
warnings. Additionally, this commit changes some cleanup functions where
appropriate (wl_data_source_destroy ->
gtk_primary_selection_source_destroy for struct
gtk_primary_selection_source).
GtkEntryCompletion can rapidly release and claim ownership of the
primary selection. This generates multiple XFixesSelectionNotify events,
first stating that no one owns the selection, then another stating that
we own the selection. The notification that no one owns the selection
causes GtkEntryCompletion to deselect the text, breaking inline
autocompletion.
This fixes it by ignoring any XFixesSelectionNotify with a timestamp
earlier than our clipboard timestamp.
Fixes#14
file_uri_deserializer splices a memory stream, as opposed to
string_deserializer, which uses a converter and filter stream. This
commit fixes erroneous use of GMemoryOutputStream as
GFilterOutputStream.
Since the function is usually called from GtkWidget::drag-{begin,end} handlers,
taking a GdkDrop does not work, especially given that
::drag-action-requested is emitted without checking the type.
Fixes https://gitlab.gnome.org/GNOME/gtk/issues/1220
The previous attempt at removing configure events entirely
was causing some dialogs not to show up under Wayland.
Presumably due to ordering issues with emitting ::size-change
out of the backend.
Instead, keep configure events in the event queue, but handle
them on the gdk side. This keeps the ordering intact, while
still removing configure events from the api. The dialogs
show up now.
The opaque region is only set when the background color is opaque. So
we need to do something about it when the background color changes.
However, in the case where a size allocation is going to happen, we
already do this update in size_allocate(), so in that case avoid doing
it twice.
Instead of instantly invalidating, we now cache the old render node and
do the update in an idle handler.
While that gives us a 1 frame delay, it avoids all the tricky things
like queueing resizes while resizing or queueing draws while drawing.
The only remaining issue (and a *big* one at that) is that a nested
widget paintable will now cause the widget to snapshot its previous
render node when creating a new one. And that one will snapshot its
previous render node, and that one will...
And nothing so far breaks this recursion.
Change GdkDrag::action to GdkDrag::selected-action, which is
more clearly different from actions, and follows the existing
name of the struct field and getter.
This lets us drop the ::action-changed signal for the
property change notification. But, can just as well move
the signal class handers which just update the cursor
to the ::action setter. No need to do this in the backends.
Some of the _diff implementations did a whole bunch of work just to
throw it away afterwards and invalidate the entire union of the two
render nodes, most notably the two clip nodes. Fix this to only call
gsk_render_node_diff_impossible if the previous if-condition is FALSE
and not always.
This is still fallout from the bin_window removal. We aren't moving the
GdkWindow/GdkSurface anymore so we have to account for the scrolling
ourselves.
Since those are widgets and widgets need to be size-allocate'd properly,
we need to queue an allocate, as well as actually add the hadjustment's
value to the column x position.
Fixes#1202
The purpose of a searchbar is to start a search on visible widgets when
a key is pressed. Starting a search on e.g. a stack page that is not
visible at all is not very useful.
... if none of the debug displays have any debug flags set. This way, we
can ignore the first parameter to e.g. GTK_DISPLAY_NOTE, which is
usually a call to gtk_widget_get_display.
Before this patch, gtk_widget_get_display was the slowest part of
gtk_widget_query_size_for_orientation.
We were leaking the GBytes for the image memory, which is a
noticeable memleak to anyone who's casually running a memory monitor.
Go KDE users!
Closes#1200
The min size on the oriented axis used to come from style props with
default values in the source file, used if the theme did not provide a
min size in CSS. When the style props were removed, so was any notion of
a minimal size for proressbars' main axis, meaning that now progressbars
without expand or any other source of min size were just tiny specks.
The right place to do that was always the theme, so in our themes now,
fix that by copying the old default values for the style properties; see:
https://gitlab.gnome.org/GNOME/gtk/issues/1191#note_259393https://gitlab.gnome.org/GNOME/gtk/blob/gtk-3-24/gtk/gtkprogressbar.c#L92
The result should be the same in that (A) the min size is now what it is
in GTK+ 3 & (B) an app/user can override the theme exactly the same way.
Close https://gitlab.gnome.org/GNOME/gtk/issues/1192
7733f646d6 renamed GdkDragContext to
GdkDrag, which broke the docs, as a reference to
gdk_drag_context_get_type() still exists. This commit renames the type
accordingly and adds GdkDrop.
(A) Put a space in "scrolled window" like the other doc comments
(B) Say "i.e." rather than "ie."
(C) Fix grammar from "makes [...] exactly reaches" to "exactly reach"
Rename gdkdnd.h to gdkdrag.h, to go along with gdkdrop.h
This commit includes the necessary updates to the X11, Wayland
and Broadway backends. Other backends have to be updated separately.
This is to go along with the newly introduced GdkDrop.
This commit includes the necessary updates to the X11, Wayland
and Broadway backends. Other backends have to be updated separately.
It looks like this got dropped during the move from autotools and never
restored. I can see why, since making it work wasn't a hugely fun task!
Notes on some less then obvious details:
* PlacesSidebar is private now and didn't seem to be to be particularly
easy to adapt to, so this moves to checking for it by name, not TYPE.
I couldn't find a (fast) better way; if you know how, please clean up
* added 2 casts to avoid warnings from the new type-propagating ref()
* GdkClipboard and GdkContentProvider need some properties dodged
* GtkToolItemGroup is gone
* fixed indentation and used TypeName:property-name syntax in a print()
Also update the cursor surfaces of every seat when an output changes
scale. This could for example happen when a monitor scale is changed via
Settings.
If we check it too early, we will not unset priv->draw_neeeded, which
will then cause queue_draw() calls to not have an effect later. And that
causes changes in opacity to not register.
Closes#1180
The comment above explains neatly why subclassing GtkButton for
GtkColorButton was a bad idea. Nowadays it's a GtkWidget subclass
containing a GtkButton so let's remove the special case here.
Binds this property to the button's label, allowing a model button to
have text with markup.
This will be convenient for buttons like 'Online Accounts <sup>↗</sup>'.
When deciding whether or not to emulate a press event, we're translating
the last event coordinates and mutating the given event structure
unconditionally.
We should modify the newly created GdkEvent copy, since it's what we're
going to use when emitting the press event.
This avoids mutating a constant GdkEvent and global state, and also
avoids a compiler warning.
The idea is that GTK+ 4 will be an epoch, API-wise.
Everything that was around for 4.0 has been there
since the beginning of the epoch and doesn't need
markers.
If the parent get_preedit_string implementation returns a nonnull
zero-length string, then we ignore it, which is almost fine. We have to
free it, though.
Fixes#1174
Expanders used to be 16px high. With the move from the gtk2 rendering
to gtk3 rendering they shrunk to 12px, making them hard to see, because
it's now the icon which is 16px high and the icon contains transparent
borders.
This makes the HighContrast theme use 24px icons instead, to restore
16px expanders. This may expander some containers a bit.
Closes#1046
GtkTextHandle was neglected by whoever removed the ::draw signal,
leaving it entirely broken. Update to using GtkGizmo so we can
implement snapshot of text handles.
Input has received a revamp too, handling is done through a
GtkGestureDrag and coordinate calculations simplified by storing
the delta to the hotspot on ::begin instead of ::update, as this
value is constant throughout the gesture. Widget state management
on crossing events happens implicitly, so no longer needs to be
done here.
Last but not least, CSS has also been updated so handles are
rendered at the correct size and proportion, and with the padding
that code expects of it.
Set up a gesture on the sidebar rows to detect pointer clicks on
it. The row DnD management has been moved to the row widget itself,
it makes more sense even if the drag is began from the sidebar widget.
We still need a drag gesture both on front (capture) and back (bubble)
to handle dragging from both the GtkWindow widget and chrome in the
headerbar. But we can do it through 2 drag gestures, instead of special
event handling code.
This has been broken since we switched key event delivery to follow
the same semantics than pointer/touch. There, GTK+ grabs will influence
the topmost widget during event delivery, rendering the toplevel
unable to handle key navigation. The toplevel must handle those key
events in an explicit manner then.
We don't render the keyboard focus rectangle yet, but I assume that's
something else.
Use an event controller on GtkFontChooserDialog, a nice side effect
is that we can use gtk_event_controller_key_forward() and
gtk_search_entry_set_key_capture_widget() instead of passing events
around for dialog search.
Instead of doing all handling manually in the ::event vfunc,
set up drag/multipress gestures on icon images, and implement
emission of ::icon-press/release and DnD there.
As a side effect, the GdkEvent field in ::icon-press/release
signals has been dropped. Callers that might be interested on it
may still use gtk_get_current_event*().
This isn't really necessary, if keyboard focus forcibly goes somewhere
else we will get ::grab-notify, which is sufficient to deactivate the
button again.
Selected rows in tree views in HighContrast have a background colour the
same or nearly as the normal text colour, so we cannot let entries in
such rows have transparent backgrounds, or the text inside the entry
becomes nearly or totally impossible to see.
Dodge this by giving entry.flat inside treeview and with :focus the
$base_color, which is different from the text & so lets that be seen.
https://gitlab.gnome.org/GNOME/gtk/merge_requests/125
This reverts commit 8e74eb382f.
This code is not necessary. It worked around a bug in graphene where
graphene was requiring stricter alignment than glib allocators could
guarantee.
The else case was wrongly resetting the accessible description on the
primary icon, which might not exist and can therefore cause a crash.
https://gitlab.gnome.org/GNOME/gtk/issues/1160
This functionality is similar to Linux's memfd. It creates anonymous shared memory without touching the filesystem, which allows it to work in Capsicum capability mode (sandbox).
The claimed status check should happen after ::end is emitted,
as the gesture may deny the sequence that much late. In this
case the event should keep propagating.
https://gitlab.gnome.org/GNOME/gtk/issues/1159Closes: #1159
We are poking again into the event propagation machinery, which
expects events in toplevel coordinates. Since we can't fetch the
original event back at this point, translate the coordinates
back to the toplevel so the emulated press ends up in the right
place.
https://gitlab.gnome.org/GNOME/gtk/issues/1159Closes: #1159
* There's no GdkDragContext->dest_surface anymore.
Add dest_window field to GdkWin32DragContext,
and use that instead.
* Remove unused function prototypes
* Add more comments
* Rename variables and fields from 'window' to 'surface'
where appropriate
* Fix header indentation a bit
* Try to ensure that uninitialized/unknown handle variables
and fields are set to INVALID_HANDLE_VALUE instead of NULL,
as there may be cases where NULL is a valid handle value.
This might be foreign Windows and we don't want to create surfaces for
those.
Also, stop using GdkDragContext.dest_surface, that variable is meant to
go away.
In particular, this patch removes:
gdk_surface_get_events()
gdk_surface_set_events()
gdk_surface_get_device_events()
gdk_surface_set_device_events()
Event masks so far still exist for grabs.
GdkDragContext => GdkDrop
This is all in preparation of separation of the drag and drop.
Also, don't check for GDK_DRAG_PROTO_XDND anymore - it's the only
possible value for the protocol on the target side.
Use the new method of connecting to the xevent signal instead.
Also, don't consume the xevent, there might be other code listening for
it. And we don't use PropertyNotify in the generic code path anymore, so
it'll just be ignored there.
* Remove clipdrop->dnd_target_state, it's not used anymore
* Remove non-functioning _gdk_dropfiles_store(), store dropfiles
list in GdkWin32Drop instead
* Fix multiple comment typos
* Fix _gdk_win32_get_clipboard_format_name_as_interned_mimetype() to
leave names that look like mime/types alone
* Refactor _gdk_win32_add_w32format_to_pairs() to populate
GdkContentFormatsBuilder directly, instead of making a GList
* Rename context -> drag (still using GdkDragContext type,
but [almost?] all variables and comments say "drag" now)
* Rename GdkDropContext -> GdkDrop
* Rename some parameter names for clarity
* Rewrite local protocol to look more like OLE2 protocol
instead of mirroring the structure of the X11 API.
* Add handle_events field to GdkWin32DragContext,
to shut off event handling (temporary fix until GTK is patched up)
* Remove _gdk_win32_drag_context_find() - the drag object is stored
in GdkDrop instead. Use _gdk_win32_find_drag_for_dest_surface()
to get it initially.
* Remove target_ctx_for_window, droptarget context is stored
in the surface instead.
* Call gdk_drag_context_set_cursor() just like wayland backend does
(slightly broken for now)
* Clean up the action choosing code (filter source actions by using
keyboard state, pass that to GTK, get all actions supported by GTK in
response, match them up with filtered source actions, return the
result, falling back to COPY in case of multiple actions)
* Check drag_win32->protocol instead of the use_ole2_dnd variable where
possible
* Remove protocol checks from functions that are only used by the local
protocol
* Use event state to manufacture the keyboard state for WM_MOUSEMOVE
* Change function names printed by GDK_NOTE to name the actual
functions, not their theoretical generic GDK stack ancestors
* Consistently use drag_win32 and drop_win32 variables instead of a mix
of that and win32_drag/win32_drop
* Return FALSE from button handler to ensure that GTK gets the button
event to break implicit grab
* Emit leave event on failed idroptarget_drop() calls
Instead of looking at the list of contexts, just look at the current
drop context. There is only one, after all.
Then remove the is_source argument from gdk_drag_context_find().
The filters now return TRUE/FALSE and no longer a GdkFilterReturn. They
also don't conform to the GdkFilterFunc typedef anymore but instead take
the arguments that they need.
This is not needed because GTK must be run in the main thread these days,
which is the same one that runs the main loop. So when this function is
called, the main loop is awake.
https://bugzilla.gnome.org/show_bug.cgi?id=550989
This uses the new method without GDK_ACTION_ASK:
Either it is a single action (queryable via gdk_drag_action_is_unique())
or it is not and then the drop target has to make a decision
(potentially by asking someone).
The ultimate goal of this patch series is to split GdkDragContext into
GdkDrop + GdkDrag classes for the destination and source side of a dnd
operation.
The refactoring is meant to work something like this:
1. Introduce GdkDrop as a base class
2. Make all drop related code (like GdkEvent) use GdkDrop instead of
GdkDragContext. Move/duplicate APIs to allow that.
3. Port all drop contexts in the backends from GdkDragContext to GdkDrop
4. Delete all APIs in GdkDragContext that aren't needed anymore.
5. Make GdkDragContext no longer a GdkDrop subclass
6. Rename GdkDragContext to GdkDrag
In 01455399e8 ("gdk: do not deactivate surface on keyboard grabs"), we
made gdk avoid deactivating surfaces when another application takes a
keyboard grab, by using has_focus_window instead of has_focus. That however
broke activating surfaces when the gdk application acquired a grab itself,
in which case has_focus_window is false but has_focus is true.
We thus actually need to use both: surfaces should be activated either
because we have normal keyboard focus, or because we grabbed the keyboard.
This also renames HAS_FOCUS to APPEARS_FOCUSED to better reflect its
role.
Fixes#85
There is no reason why we shouldn't pass this flag every time
Z-order changes. We have separate routines that are used to
maintain relative Z-order, so it should be completely OK to
pass SWP_NOOWNERZORDER to let the OS know that it shouldn't try
to maintain relative Z-order of the windows when raising them.
Pass SWP_NOOWNERZORDER when rising TEMP surfaces to the top. This ensures that
they don't drag anything else to the top with them. The use-case for this is
a tooltip appearing for a non-foreground surface, causing said surface to rise
above other surfaces, some of which maybe foreground at the moment.
https://bugzilla.gnome.org/show_bug.cgi?id=784766
According to the old new thing[0], we should use the instance handle
of the GDK/GTK DLL when registering GDK-specific types in the system.
Using the instance handle for the whole application in these circumstances
is not an error, but can potentially clash with the types registered
by the application itself.
Also, extract window class icons from the GDK/GTK DLL, not from the
application executable.
[0]: https://blogs.msdn.microsoft.com/oldnewthing/20050418-59/?p=35873
The argument is eventually passed to g_conv(), so it should
be the charset, not the mime/type. Without this change the
contentype converter will fail to convert UTF-8 strings to, say,
CP-1251 later on.
Unconditionally putting 'gdkwayland_inc' in src_dir argument of gtkdoc
call tells gtkdoc-scan to scan source files in a non-existent build
directory, gdk/wayland. To avoid causing build failure when a specific
backend is disabled, we should include directories conditionally.
Otherwise gcc complains when we use these as arguments to g_new() on
32bit architectures with:
../gtk/gtkcomposetable.c: In function ‘gtk_compose_table_list_add_array’:
/usr/include/glib-2.0/glib/gmem.h:217:10: warning: argument 1 range [2147483648, 4294967295] exceeds maximum object size 2147483647 [-Walloc-size-larger-than=]
__p = g_##func##_n (__n, __s); \
~~~~^~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/glib-2.0/glib/gmem.h:279:42: note: in expansion of macro ‘_G_NEW’
#define g_new0(struct_type, n_structs) _G_NEW (struct_type, n_structs, malloc0)
^~~~~~
../gtk/gtkcomposetable.c:851:22: note: in expansion of macro ‘g_new0’
gtk_compose_seqs = g_new0 (guint16, length);
^~~~~~
/usr/include/glib-2.0/glib/gmem.h:96:10: note: in a call to allocation function ‘g_malloc0_n’ declared here
gpointer g_malloc0_n (gsize n_blocks,
^~~~~~~~~~~
When a remote instance of a GTK application implementing the Startup
Notification protocol gets spawned it will pass the startup sequence
ID as "platform data" to the main instance. Thus, we need to make sure
that the startup sequence gets completed in that case, since the remote
instance won't do it by itself, since it won't map any top level window.
Checking for this "platform data" in the implementation of the after_emit()
virtual method in the primary instance should be a good place to do so, since
the existence of such data proves that a remote instance has been spawned.
https://gitlab.gnome.org/GNOME/gtk/issues/1084
The DESKTOP_STARTUP_ID gets cleared early after the process is spawned,
meaning that it's too late at add_platform_data() to pick it up and send
it over to the primary instance, as it will be always unset at that point.
To solve this, we use the new gdk_display_get_startup_notification_id()
method to pull the startup notification ID for the application, if present,
out of the display and pass it over to that primary instance.
https://gitlab.gnome.org/GNOME/gtk/issues/1084
Includes implementation for Wayland and X11, which are the only backends
implementing the Startup Notification Protocol, returns NULL otherwise.
https://gitlab.gnome.org/GNOME/gtk/issues/1084
Similar to what has been done recently for DESKTOP_AUTOSTART_ID [1],
we need to get rid of this call to g_unsetenv() in the displays'
backends for X11 and Wayland, so that it's guarantee to happen any
thread is created, while still being accessible when needed.
Let's stash the value of this environment variable when loading the
GDK library, and provide a private method so that it can be retrieved
from the displays' backend when implementing gdk_display_make_default().
[1] https://gitlab.gnome.org/GNOME/gtk/commit/22269902
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/979
check_dir_mtime() is called by ftw() and is given
the real stat struct, not its glib version (which may
or may not be the same as "struct stat").
This is irrelevant for MSVC (it has no ftw()) and
works correctly for MinGW-w64 (which declares stat
structures correctly). If mingw.org complains, add
a special ifdef for it later.
It's quite old, but mostly harmless (both "message == WM_KEYUP"
and "message = WM_KEYUP" evaluate to not-FALSE, and message
value is not used after that line).
Any data that is later fed to graphene must be
allocated with proper alignment, if graphene
uses SSE2 or GCC vector instructions.
This adds custom array code (a streamlined copy
of GArray with all unnecessary bells and whistles removed),
which is then used for the state_stack instead of GArray.
There's also a runtime check for the size of GtkSnapshotState
itself being a multiple of 16. If that is not so, any array
elements past the 0th element will lose alignment.
There are probably struct attributes that can
make GtkSnapshotState always have size that is a multiple
of 16, but we'll burn that bridge if we cross it.
The check survived from GTK2 when that function could still return
GdkPixmap and GdkFont objects and was accompanied by this comment:
/* We may receive events such as NoExpose/GraphicsExpose
* and ShmCompletion for pixmaps
*/
and gtk_image_set_can_shrink().
Images are meant to always be icon-sized, they can never shrink below
that.
And images are icons, so they are meant to be square. If they are
not, we pretned that's by accident and keep aspect ratio.
This commit introduces GtkPicture, which is supposed to complement
GtkImage.
GtkImage will be adapted to always display an icon, while
GtkPicture displays regular imagery.
Instead declare a priv local. We should do this even if we don't remove
the priv pointer from GtkWidget entirely, just to stay consistent with
new code we introduce.
The code is mostly stolen from graphene.
Allocators support any alignment, but their implementation
only calls system aligned allocator functions if malloc()
is not aligned to 16-byte boundaries. If it is aligned,
the implementation just calls malloc() regardless of which
alignment is requested by the caller.
This can be fixed by saving the result of meson malloc()
alignment check and adding a few conditions to the implementation,
but right now GSK and GTK only need 16-byte alignment either way.
* A bunch of new variables for config.h.meson
* A check for aligned allocation being necessary at all
(graphene must use GCC vector instructions or SSE2)
* A check for C malloc() being aligned at 16-byte boundaries
* A check for a few special aligned allocator functions being
present and not being built-ins (posix_memalign is a builtin
in GCC, even on platforms where there is no posix_memalign
system function)
* Added -mstackrealign flag on Windows, since otherwise
stack variables may become unaligned when the stack briefly
passes through OS code (such as in various callbacks and
handlers)
Otherwise, requesting a min size in em where the equivalent in px had a
fractional part would lead to the widget getting allocated 1 too few px.
You could see this in the CSS property vs. allocation in the Inspector.
Note that margin/border/padding are left alone: the rationale is that we
do as browsers do, and Benjamin said we already do that for those,
whereas his tests on min-(width|height) showed otherwise. My subsequent
analysis indicated it to be far less clear-cut than that, but he remains
unconvinced that we should ceil() all the things! So just do these ones.
https://gitlab.gnome.org/GNOME/gtk/issues/1088
This is the API used by GtkMenu to properly position menus on the screen
without requiring GTK to query the menu window's position or the work
area of where the window is positioned. It makes it possible to position
popup windows properly when using Wayland.
Make this API available to external users so custom popup windows can be
positioned properly as well.
Related: https://gitlab.gnome.org/GNOME/gtk/issues/997
Causing a grab in the handler for ::pressed by, e.g., popping up a
context menu will cause the gesture to be canceled and, subsequently,
::end and ::released to be fired, all while the button is still
physically pressed. That results in no event being available to the
::released handler and garbage coordinates, given that
gtk_gesture_get_point() returns FALSE.
Emitting ::released can be avoided by checking the return value
gtk_gesture_get_point().
Querying the event sequence of a gesture will always yield NULL for
non-touch events, but passing NULL in to calls to
gtk_gesture_get_last_event() is a perfectly valid use case.
That code branch is meant to check for key events, seems obvious we want
GDK_KEY_PRESS, not GDK_BUTTON_PRESS (which also broke the branch right
below).
Makes us all able to dismiss popovers again.
We can just as well use notify::has-focus for the purpose of
focus tracking, and we can at the same time avoid emitting the
deprecated AtkObject::focus-event signal.
A recent dependency change in MSYS2 made it pull in vulkan, which made
meson think it's available but it somehow links against the system vulkan dll
instead.
Disable vulkan for now.
:climb-rate is not about what you get when you single-click on a button,
as this implied: it's what happens if you hold down a button or a key.
Fix the description of @climb_rate to new(), and while here, mention the
key in the blurb of :climb-rate itself.
The last round of patches to get the desired direction of value move in
response to scrolls/keypresses on scales had the inadvertent side effect
of giving the opposite direction on scrollbars. Seeing as gtkrange.c is
already a collection of hacks, add another so that fix only holds if the
instance is a GtkScale, since that is what those patches were aimed at.
Close https://gitlab.gnome.org/GNOME/gtk/issues/1065
We were mutating the list while iterating over it. This was not a
problem before since remove_controller just set the controller pointer
to NULL instead of actually removing it from the list of controllers.
We can avoid a signal connection per event controller (and the
EventControllerData struct) since every event controller knows the
widget it's attached to.
GtkTextView scrolls to the insertion point when the text
buffer signals a paste is done. This is wrong when there
are multiple views on the same buffer, and the paste
happened in another view.
To fix this, flip the handling of the scroll_after_paste
boolean to only be TRUE if we know that we want to scroll.
The gtk_app_chooser_dialog_set_heading() function do emit
notify::heading. Since the setter simply calls the function,
the setter itself shouldn't emit a notify signal by itself.
The bubble_timeout_id was reset only on some special case.
And so warnings were shown when the source is being tried
to be removed with the already removed id.
Fix this by unconditionally resetting the id on start of the function.
When an animated cursor was set and the previous cursor animation delay
happened to be the same, we wouldn't restart the animation timeout and
just return G_SOURCE_CONTINUE assuming the timer would continue. This
assumption is however only valid if the function was called from the
timeout, which is not the case.
Instead also arm the timer also if there is no previous timer active.
gdk_wayland_*_grab()/ungrab() would emit crossing events which translate
as focus_in/focus_out events for keyboard.
However, the ungrab() functions compare the native toplevel as this is
what gets the Wayland pointer enter/leave events with the grab surface,
so if the grab is issued on a child gdk surface, those won't match and
we would emit more focus_out events than focus_in.
This means that a widget such as spice-gtk which issues a keyboard grab
whenever the pointer enters the surface and releases the grab when it
leaves the surface would get uneven numbers of focus_in/focus_out
events.
Also, gdk_wayland_seat_ungrab() would not emit crossing events for
keyboard devices, whereas gdk_wayland_device_ungrab() does, which adds
even more potential discrepancies between focus_in/focus_out events.
To solve this problem, introduce two new helper functions which check
the relevant native surfaces to emit crossing events when needed that
get called evenly from both gdk_wayland_seat_grab()/ungrab() and gdk
_wayland_device_grab()/ungrab() APIs.
Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=780422
Closes https://gitlab.gnome.org/GNOME/gtk/issues/792
The last parameter of the signal callback from .ui
is the template's object from which the class is
derived.
And so, we already have access to the window object.
Let's just use it.
Our flatpak-builder manifests include building Graphene from Git; since
we're building the GTK demos, it's pointless to build the Graphene tests
as well. Disabling tests and benchmarks avoids pointless installations
inside the Flatpak build repo that will just be removed by the time we
bundle the demo.
<property name="text">Grumpy wizards make toxic brew for the evil Queen and Jack. A quick movement of the enemy will jeopardize six gunboats. The job of waxing linoleum frequently peeves chintzy kids. My girl wove six dozen plaid jackets before she quit. Twelve ziggurats quickly jumped a finch box.
<object class="GtkStackPage">
<property name="name">entry</property>
<property name="child">
<object class="GtkEntry" id="entry">
<property name="text">Grumpy wizards make toxic brew for the evil Queen and Jack. A quick movement of the enemy will jeopardize six gunboats. The job of waxing linoleum frequently peeves chintzy kids. My girl wove six dozen plaid jackets before she quit. Twelve ziggurats quickly jumped a finch box.
Разъяренный чтец эгоистично бьёт пятью жердями шустрого фехтовальщика. Наш банк вчера же выплатил Ф.Я. Эйхгольду комиссию за ценные вещи. Эх, чужак, общий съём цен шляп (юфть) – вдрызг! В чащах юга жил бы цитрус? Да, но фальшивый экземпляр!
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.