This is a selection modelt that allows selecting
more than one item.
The behavior is not 100% right yet for extending
selections, but it basically works.
This requires a bunch of refactoring because so far the ListItem had no
knowledge of the manager, but it needs the manager so it can access the
selection to trigger the select/unselect operation.
This way, newly displayed rows don't play an unselect animation (text
fading in) when they are unselected, but the row was previously used for
a selected item.
Instead of just destroying all items and then recreating them (or even
hide()ing and then show()ing them again (or even even repositioning
them in the widget tree)), just try to reust them in the order they are.
This works surprisingly well when scrolling and most/all widgets
just moved.
We reorder widgets start to end, so when reusing a list item, we
correctly know the previous sibling for that list item, but not the
next sibling yet. We just know the widget it should ultimately be in
front of.
So we can do a more correct guess of the list item's place in the widget
tree if we think about where to place an item like this.
Actually using this change will come in the next commit.
Previously, we were recreating all widgets every time the list item was
rebound, which caused a lot of extra work every time we scrolled.
Now we keep the widgets around and only set their properties again when
the item changes.
This is the big one.
The listview only allocates 200 rows around the visible row now.
Everything else is kept in ListRow instances with row->widget == NULL.
For rows without a widget, we assign the median height of the child
widgets as the row's height and then do all calculations as if there
were widgets that had requested that height (like setting adjustment
values or reacting to adjustment value changes).
When the view is scrolled, we bind the 200 rows to the new visible area,
so that the part of the listview that can be seen is always allocated.
The anchor is now a tuple of { listitem, align }.
Using the actual list item allows keeping the anchor across changes
in position (ie when lists get resorted) while still being able to fall
back to positions (list items store their position) when an item gets
removed.
The align value is in the range [0..1] and defines where in the visible
area to do the alignment.
0.0 means to align the top of the row with the top of the visible area,
1.0 aligns the bottom of the widget with the visible area and 0.5 keeps
the center of the widget at the center of the visible area.
It works conceptually the same as percentages in CSS background-position
(where the background area and the background image's size are matched
the same way) or CSS transform-origin.
We now don't let the functions create widgets for the item from the
listmodel, instead we hand out a GtkListItem for them to add a widget
to.
GtkListItems are created in advance and can only be filled in by the
binding code by gtk_container_add()ing a widget.
However, they are GObjects, so they can provide properties that the
binding code can make use of - either via notify signals or GBinding.
Also refactor the whole list item management yet again.
Now, list item APIs doesn't have bind/unbind functions anymore, but only
property setters.
The item factory is the only one doing the binding.
As before, the item manager manages when items need to be bound.
Require that items created with the manager get destroyed via the
manager.
To that purpose, renamed create_list_item() to acquire_list_item() and
add a matching release_list_item() function.
This way, the manager can in the future keep track of all items and
cache information about them.
It's all stubs for now, but here's the basic ideas about what
this object is supposed to do:
(1) It's supposed to be handling all the child GtkWidgets that are
used by the listview, so that the listview can concern
itself with how many items it needs and where to put them.
(2) It's meant to do the caching of widgets that are not (currently)
used.
(3) It's meant to track items that remain in the model across
items-changed emissions and just change position.
(2) It's code that can be shared between listview and potential
other widgets like a GridView.
It's also free to assume that the number of items it's supposed to
manage doesn't grow too much, so it's free to use O(N) algorithms.
This is mostly for dealing with proper anchoring and can be used to
check that things don't scroll or that selection and focus handling
properly works.
For comparison purposes, a ListBox is provided next to it.
The thing we're actually doing is create and maintain a widget for every
row. That's it.
Also add a testcase using this. The testcase quickly allocates too many
rows though and then becomes unresponsive though. You have been warned.
Thisis the abstraction I intend to use for creating widgets and binding
them to the item out of the listview.
For now this is a very dumb wrapper around the functions that exist in
the API.
But it leaves the freedom to turn this into public API, make an
interface out of it and most of all write different implementations, in
particular one that uses GtkBuilder.
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.
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
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
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.
1. Include the broadway renderer (so we can test it properly fails on
Wayland or X11)
2. List all potential renderers, print useful information when Vulkan
is not compiled in instea dof omitting it
3. Improve docs
Instead of tracking offers in GdkWaylandSelection objects, track the
pending offer in the GdkWaylandSeat and pass it to the GdkDragContext
once we get an enter event.
A container node inside another container node doesn't make a lot of
sense, we can instead just use the parent container node and add the
child container node's children to it directly.
The header linux/input.h used by GDK is specific to Linux. It is
possible to get a few Linux headers on FreeBSD by installing v4l_compat,
but it is usually better to use the one shipped with FreeBSD.
We prefer dev/evdev/input.h to linux/input.h here, so it will always use
dev/evdev/input.h on FreeBSD regardless of v4l_compat.
https://svnweb.freebsd.org/changeset/ports/465644
Broke up a long line, added an empty one, indented another one, and re-aligned
a large amount of function parameter names that got misaligned in some past
refactoring.
https://bugzilla.gnome.org/show_bug.cgi?id=791939
This commit adds support the stable version of the xdg-shell protocol.
Support for the last version of the unstable series is left intact, but
will not receive new features.
The stable version is prioritized above the older version.
https://bugzilla.gnome.org/show_bug.cgi?id=791939
When pressing e.g. a window manager shortcut, which acquires keyboard grab,
Xorg would send FocusOut NotifyGrab then FocusIn NotifyUngrab. Currently
gdk would then deactivate the current surface, which makes accessibility
screen readers think that we have switched to a non-accessible application
and came back again, and thus reannounce the application frame etc. which we
don't want when e.g. just raising volume.
And actually, receiving FocusOut NotifyGrab does not mean losing the
X focus, it only means an application aqcuired a grab, i.e. it is
temporarily stealing keyboard events. On Wayland, this isn't even
notified actually.
This commit makes gdk only deactivate surfaces when there was an actual
focus switch to another window, as determined by has_focus_window (instead
of just has_focus), which happens either normally through FocusOut with
NotifyNormal, or during grabs through FocusOut with NotifyWhileGrabbed.
Fixes#85
gdk_win32_keymap_check_compose() shouldn't be called for
non-W32 displays (i.e. when using broadway or other backends
that could be made to run on Windows).
We no longer set the widget on construction, but instead require an
explicit call to gtk_widget_add_controller().
This way, the reference handling becomes explicit and bindable.
Because gtk_widget_add_controller() is (transfer: full), we don't
even need to unref the controller after adding it.
And we don't need to keep track of it, because controllers get cleaned
up by GtkWidget.
This is the first step towards refactoring how widgets deal with event
controllers.
In the future, the widget will treat controllers the same way it treats
child widgets:
1. The controllers will be created without a widget.
2. There will be gtk_widget_add/remove_controller() functions to add
or remove controllers.
3. The widget will hold a reference to all its controllers.
This way we will ultimately be able to automate controllers with ui
files.
gtk_get_current_event() returns a new reference to the event, it should
be freed across various return branches to avoid the event leak, or we
just fetch the little stuff we're interested in.
Now that all Cairo contexts are ported to managing cairo surfaces
themselves, the old fallback code that didi the managing is no longer
needed.
Also clarify the behavior of gdk_cairo_context_cairo_create() wrt the
vfunc by doing the early exit and the clipping outside of it.
* Remove DC refcounting (we trust GDK to always do
begin_frame/end_frame calls in pairs)
* Now that there's no GDK-provided double-buffer up the stack,
double-buffering is implemented here
(though it's disabled by default - in my tests it didn't provide
any visual improvements, but did decrease performance).
* For some reason delaying window resizes until the point where
we need to blit the double-buffer into the window leads
to visual glitches, so doulbe-buffered windows are resized
in begin_frame, same as non-double-buffered ones.
* New code to clear the paint region, for all drawing modes.
Hopefully, it isn't duplicated anywhere up the stack.
* GL has its own context now, so remove any GL-related comments.
* Layered windows are still used (because cairo actually works
better with them)
* A bit more code re-use for layered windows
* Some functions that were local to gdksurface-win32.c are made
usable for the whole backend
* Drag-indicator drawing is temporarily commented out to match
a similar change in X11 backend
We used to pass 2 regions to GdkDrawCotnext.end_frame() but code was
confusing what they meant. So we now don't do that anymore and only pass
the region that matters: The frame region.
This makes the previous gdk_draw_context_is_drawing() function public
under a new name.
I decided against the old name because we use the term "frame" for a
drawing operation, so I wanted to have this boolean flag reuse the term.
As they require a draw context and the draw context is already bound to
the surface, it makes much more sense and reduces abiguity by moving
these APIs to the draw context.
As a side effect, we simplify GdkSurface APIs to a point where
GdkSurface now does not concern itself with drawing anymore at all,
apart from being the object that creates draw contexts.
Previously, we got the damage, then computed the changed area, then
started a frame with that changed area.
But starting a frame computes the damage for us.
So now we start a frame, then get the damage area from that, then
compute the change area.
Also, split it into its own file - which was the original reason for
looking at this code, the rewrite was an unintentional side effect.
This changes the context to create surfaces on demand.
So whenever the compositor holds onto a surface while GDK wants to
render, it just creates a new surface. If the compositor releases
surfaces, we will retain one for the next frame to be rendered, but free
all extra ones.
This way, we should get to a stage where we have exactly as many
surfaces as needed and never allocate/free any.
Also, don't implement SurfaceClass.ref_cairo_surface() anymore. This
means calls to it will crash now. But as they only happen in the generic
GdkCairoContext implementation, we shouldn't be affected by that.
Plus, once all backends have been ported, that call is going away
anyway.
And make the GdkCairoContext as abstract.
The idea of this and thje following commits is to get rid of all
Cairo code in gdksurface.c (and $backend/gdksurface-$backend.c)
by moving that code into the Cairo context files.
In particular, the GdkSurfaceClass.begin_frame/end_frame()
functions (which are currently exclusively used by the Cairo code
should end up being moved to GdkDrawContextClass.begin/end_frame().
This has multiple benefits:
1. It unifies code between the different drawing contexts.
GL lives in GLContext, Vulkan in VulkanContext and Cairo in
CairoContext. In turn, this makes it way easier to reason about
what's going on in surface-specific code. Currently pretty much
all backends do things wrong when they want to sync to drawing
or to the frame clock.
2. It makes the API of GdkSurface smaller. No drawing code (apart
from creating the contexts) needs to remain.
3. It confines Cairo to the Drawcontext, thereby making it way
more obvious when backends are still using it in situations
where it may now conflict with OpenGL (like when doing the dnd
failed animation or in the APIs that I'm removing in this
branch).
4. We have 2 very different types of Cairo contexts: The X/win32
model, where we have a natively supported Cairo backend but do
double buffering ourselves and use similar surfaces and the
Wayland/Broadway model where we use image surfaces without any
Cairo backend support and have to submit the buffers manually.
By not sharing code between those 2 versions, we can make the
actual code way smaller. We also get around the need to create
1x1 image surfaces in the Wayland backend where we pretend
there's a native Cairo surface.
This does nothing but disallow passing NULL to gdk_surface_begin_paint()
and instead require this context.
The ultimate goal is to split out Cairo drawing into its own source file
so it doesn't clutter up the generic rendering path.
1. Remove set_icons property
2. Make it a GtkWidget subclass
3. Add gtk_fishbowl_set_creation_func()
4. Make the widgetbowl use the new benchmarking infrastructure of the
fishbowl
And of course, gsk_render_node_get_name() is gone, too.
The replacement is of course debug nodes.
As a side effect, GskRenderNode is now *really* immutable.
The shortcuts inhibitors hash table is created when we create a
GdkWaylandWindow implementation for a GdkWindow, and it's destroyed once
we finalize the instance. The fake "root" window we create for the
Wayland display does not have a backing native window, so the shortcuts
inhibitors hash table is set to NULL; this causes a critical error
message when calling g_hash_table_destroy() on it. The finalization of
the root window happens when we close a display connection.
We should use g_clear_pointer(), instead, as it's NULL safe.
Without this change, the displayclose test fails, as all warnings are
considered fatal.
Instead of hard-coding linker flags for a specific operating system and
a specific compiler, we can should cc.links to test them, so they can be
used on more operating systems and compilers.
All of the four platform-dependent backends are enabled by default. It
is usually a good default because it requires users to explicitly choose
backends they want to use. Rules in meson.build also automatically
disable unavailable backends for macOS, Windows, Linux, so users on
these 3 major platforms don't have to manually disable things when
running meson commands.
However, meson.build doesn't do the same thing for other Unix-like
systems, which is acceptable but not ideal. To make it easier to build
GTK+ on these systems, the Linux case, which enables X11 and Wayland and
disables Win32 and Quartz, is made the default for all operating systems
that are not Windows or macOS.
This commit also changes most 'host_machine.system()' calls to os_*
variables, which are easier to read and less likely to be used wrongly.
The shortcuts inhibitors hash table is created when we create a
GdkWaylandWindow implementation for a GdkWindow, and it's destroyed once
we finalize the instance. The fake "root" window we create for the
Wayland display does not have a backing native window, so the shortcuts
inhibitors hash table is set to NULL; this causes a critical error
message when calling g_hash_table_destroy() on it. The finalization of
the root window happens when we close a display connection.
We should use g_clear_pointer(), instead, as it's NULL safe.
Without this change, the displayclose test fails, as all warnings are
considered fatal.
.linked assumes the container is a GtkBox, which is documented as never
flipping children in RTL, so :first-child is always the left child, etc.
GtkBox does that by reordering its CSS nodes when the direction changes.
But most widgets don’t do that, so :first|last-child are 1st/last ADDED
and swap sides in RTL. GtkPathBar is so, and ignoring that in our themes
meant that in RTL, its left/right buttons got each other’s borders. Yuk!
This patch adds the groundwork for supporting widgets like that, via the
%linked_flippable placeholder, and applies that to override buttons in
filechooser .path-bar.linked > button
so that the correct borders get applied to those buttons when using RTL.
Note that I select only PathBars within a FileChooser because we also
have NautilusPathBar, which also uses widget.path-bar – but *does* flip
its nodes for RTL already, so letting that get affected broke it again!
https://bugzilla.gnome.org/show_bug.cgi?id=772817
See the previous commit.
There may be other cases of these being swapped by Gadget conversions,
but hopefully someone else will find and fix those before I have to…
Close https://gitlab.gnome.org/GNOME/gtk/issues/200
Otherwise, if the Popover is destroyed before the MenuButton, the latter
still had a non-NULL but invalid instance and tried to use it in dispose
Close https://gitlab.gnome.org/GNOME/gtk/issues/199
Use g_signal_connect_data() instead of g_signal_connect_object()
to make sure the callback gets disconnected when the data object
is destroyed. This avoids problems in garbage-collected bindings.
https://bugzilla.gnome.org/show_bug.cgi?id=789215
Instead of hard-coding linker flags for a specific operating system and
a specific compiler, we can should cc.links to test them, so they can be
used on more operating systems and compilers.
All of the four platform-dependent backends are enabled by default. It
is usually a good default because it requires users to explicitly choose
backends they want to use. Rules in meson.build also automatically
disable unavailable backends for macOS, Windows, Linux, so users on
these 3 major platforms don't have to manually disable things when
running meson commands.
However, meson.build doesn't do the same thing for other Unix-like
systems, which is acceptable but not ideal. To make it easier to build
GTK+ on these systems, the Linux case, which enables X11 and Wayland and
disables Win32 and Quartz, is made the default for all operating systems
that are not Windows or macOS.
This commit also changes most 'host_machine.system()' calls to os_*
variables, which are easier to read and less likely to be used wrongly.
Well, they don't require a redraw of the widget, because the widget
itself didn't change.
They require a redraw of the parent, because that now displays the
widget in a different position.
And this means we can keep the cache of the widget's render node.
My fishbowl numbers are through the roof^W water surface. Vulkan gets
4000 now.
Due to the few type checks in gtk_widget_get_display(), it was the
slowest part of a call to gtk_widget_query_size_for_orientation if the
in case of a cache hit.
We pulled out the bounds calculation for performance reasons, but the
caller can't know how to properly compute them. Inside gtk+, we can do
that but it's not good enough for public API.
The GVariant we are getting here might not be coming
from GTK+, but rather from some other source. Best to
be forgiving and deal with missing data without crashing.
This was causing the GTK+ portal backends to crash on
print requests from Qt.
It might happen otherwise that a change is recorded in between the
widget dispose and finalization, causing a crash when setting
the visible name for the GtkStack (as that will be NULL at that point)
This will be used in subsequent commits to fix the sign by which the
value is changed in response to directional scroll or keypress events.
The idea is: you have a movement to make – in the form of a delta that
follows widget directions, i.e. −1 means left or up, +1 means right or
down – and you want to know whether that delta needs to be inverted in
order to produce the intuitively expected directional change of :value.
The existing should_invert() is not sufficient: it just determines
whether to invert visually, but we need more nuance than that for input.
To answer that – while not doubling up the work for scrolls and keys – I
add a helper should_invert_move(), which considers other relevant state:
• A parallel movement on priv->orientation should just use the existing
should_invert(), which already worked OK for this case (not others).
• Movements on the other orientation now depend on priv->orientation:
◦ For a horizontal Range, always invert, so up (i.e. −ve in terms of
widget coords) always means increase value & vice-versa. This was
done in get_wheel_delta(), but move it here for use with keys too.
◦ For a vertical Range, ignore :invert as it’s only relevant to the
parallel orientation. Do not care about text direction here either
as RTL locales do not invert number lines, Cartesian plots, etc.
This returns TRUE if the delta should be inverted before applying to the
value, and we can now use this function in both scroll and key handlers.
https://bugzilla.gnome.org/show_bug.cgi?id=407242https://bugzilla.gnome.org/show_bug.cgi?id=791802
If widgets want to clip things, they now need to do it themselves.
By not taking care of clip, we avoid the need to track clip. And by not
tracking clip, we can avoid all unnecessary cache invalidations that we
were doing for render nodes whenever the clip changed.
And when you are scrolling, the clip changes *a lot*.
priv->button is a guint, but we assigned it to a local gint.
gtk/gtkmenushell.c:734:37: warning: comparison between signed and
unsigned integer expressions [-Wsign-compare]
if (button && (new_button != button) && priv->parent_menu_shell)
^
...from CellRenderer::start-editing, to point people in the direction of
info about the lifecycle of the Editable and how to do generic setup.
https://gitlab.gnome.org/GNOME/gtk/issues/154
Drop the line copied from .activate(), replace it with a description of
what this method actually does, and explain what a NULL result means.
https://gitlab.gnome.org/GNOME/gtk/issues/154
* Note in the intro that we're really thinking about temporary widgets
* Mention a gotcha regarding GtkEntry and how ::focus-out stops editing
* Give some examples of what you'd want to do in ::editing-done
* Be a bit more precise about what ::remove-widget represents
* Summarise the lifecycle between Renderer/Editable in .start_editing()
* Emphasise again there that this should be viewed as a temporary widget
https://gitlab.gnome.org/GNOME/gtk/issues/154
When filing a new merge request it's often hard to know who to ask for a
review; using the Git log doesn't always help — the person that touched
a file last may just be fixing the build or a compiler warning.
The `CODE-OWNERS` file format is something that GitHub uses in order to
pre-fill the list of reviewers:
https://help.github.com/articles/about-codeowners/
Ideally, in the future, we'll be able to use this file with a bot like
homu to automatically go through newly filed merge requests and
automatically ask the relevant people for reviews, instead of doing this
manually.
Keep in sync with the current tree.
The changes are mostly caused by updates in the internal hierarchy of
composite widgets, and the fact that the order in which the widget tree
is traversed is not exactly stable.
Instead of having a single massive test running through the a11y
directory, we can split off each individual file into its own unit.
Having individual units has several advantages:
- units are executed in parallel
- it's easier to identify the failing units
- logs for failed units are easier to read
We can't freeze the frame clock on commit, but only after-paint,
otherwise the frameclock will resume in the paint stage.
So freeze the frame clock at the end of the frame if we are waiting for
a frame callback.
Note; The diff is only lage because of indentation changes due to
avoiding early returns in favor of a branch.
GTK does use libintl directly (in gtkmain.c, for example) and thus
needs to be linked to it (if found and/or needed).
Previously we most likely were getting libintl from glib, but
that stopped for some reason. Either way, explicit linking is
the right thing to do here.
Instead of going through an ancillary script to strip away the
`WL_EXPORT` annotation from the generated code, we should bump up the
required version of Wayland, and use the `private-code` argument for
wayland-scanner, which does the right thing for us.
There where some problems (??) with ccache not detecting changes during meson
checks. Setting CCACHE_DISABLE during the meson execution makes ccache not use
the cache and pass things directly to the compiler.
Instead of connecting to / disconnecting from the frame clock, do it
inside the vfuncs next to changing the priv->realized boolean.
This removes a race between those 2 cases that could cause child
widgets' unrealize handlers to reconnect this widget to the frame clock
because it was still marked as realize when the widget had already
disconnected from the frame clock.
Fixes#168
But in turn, also allow it to work on widgets with their own surface.
This way, we can chain up from everywhere and won't have to export
gtk_widget_set_realized().
When using strncpy() with a buffer we need to account for the
terminating NUL character. GCC 8 started warning when using PPD_MAX_NAME
as the buffer length for strncpy() because the buffer we're copying into
has the same length — which means that the terminating NUL may be
skipped if the source string has a length of PPD_MAX_NAME.
The appropriate way to handle the case where we're copying a source with
a length bigger than of PPD_MAX_NAME is, as reported in the strncpy()
documentation, to copy `PPD_MAX_NAME - 1` bytes, and explicitly NUL
terminate the destination buffer. This has the additional benefit of
avoiding the compiler warning.
* Previous commit had misleading info. The code was
added to begin_paint() instead of end_paint(). Though
that did not affect its performance in any visible way.
* Company advised to move the code to an "after_paint" signal
handler, so that it works on all renderers, not just Cairo.
This change caused high fluctuation in FPS values in fishbowl
when it is put in a situation where it cannot achieve 60fps
(such as using Cairo renderer at ultra-high resolution).
This seems to be deliberate and not a bug.
There is no easily apparent way of being notified when frame updates
happene exactly, so we just query frame info at the end of each paint.
If we query too often (faster than DWM refresh rate), we just get
the same values twice in a row, but that is, hopefully, highly unlikely.
Now that queue_draw() isn't restricted to clip anymore, we don't need to
care about clip in the CSS engine either.
We do keep GTK_CSS_AFFECTS_CLIP around though because GtkWindow does
care for the window's size.
When asked for a nonexistent (positive) monitor number,
gdk_x11_display_get_monitor would (at best) return an uninitialized pointer,
instead of returning NULL.
That way, we can store the right region there: The actual painted area
instead of the exposed area (which is way too small).
Also, the GL context is the only user of this data, so storing it there
seems way smarter.
Even widgets with an empty allocation may still want to draw stuff.
Examples include shadows or child widgets with negative margins.
Fixes GtkEntry's progressbar not showing up anymore.
Deferring a bit further making those a standalone controller, make
binding activation happen on run_controllers(), so it happens by
default on widgets (unless the key event was consumed earlier)
without the need of a legacy event controller.
Non gesture controllers have no means to collaborate with other
controllers, thus should be considered standalone entities. It makes
no sense to propagate any further if scroll/key controllers handled
the event.
Use a key controller instead. Note that this currently
breaks the handling of Enter, since we activate key bindings
twice, causing us to switch to the label and back.
This is a GtkGesture done to deal with stylus events from drawing tablets.
Those have a special number of characteristics that extend a regular
pointer, so it makes sense to wrap that.
This may result on the later emission of crossing events, with one of the
sides being already unmapped/unrealized. The widget being unmapped will
result on repick and emission of a set of crossing events anyway.
This event controller is meant to replace usage from key-press/release-event
handlers all through. Optionally it can be set a GtkIMContext, so interaction
is carried by the controller.
1. Pass clip rectangles to gtk_snapshot_push_state() that point into
the state array.
2. g_array_set_size(len+1) the state array
3. Make that function realloc() the state array.
4. The clip rectangle now points into invalid memory
5. Use the clip array
This patch fixes things by moving step 5 to before step 2.
1b9aa1b708 ('a11y: drop the focus tracker') removed a bit too much. We
still have to emit window:activate/deactivate events. They are easy to
emit anyway.
Fixes#127
Overlays are drawings that get rendered on top of the inspected window.
The only overlay in existence so far is the highlight overlay, which is
used to highlight widgets and replaces the "draw" signal handler used
previously.
Instead of just notifying the inspector of what is going to be rendered,
allow the inspector to modify it.
This way, the inspector can overlay information it deems relevant over
the render node while still having access to what the actual widget
(without the inspector) would paint.
If you want to draw a widget to cairo today, you create a widget
paintable, snapshot it to a render node and then draw the render node to
cairo.
And yes, this is that complicated on purpose. Don't draw widgets to
Cairo.
This allows being more specific about the size.
It's useful in particular when the resulting render nodes might be
too small for the size, not only when they are too large. For the
latter case, using a clip node would be enough.
It also requires adding a clip node when rendering the resulting
paintable, but that should be optimized out by GtkSnapshot when not
necessary.
This is actually not just a mechnaism to protect against too many
signals, but it's also a method to getting those signals at the wrong
time.
For every size/content change, a widget needs to invalidate twice:
Once when it queues a resize/redraw (going valid => invalid) and once
when the new size/content is actually assigned (going invalid => valid).
However, one of those invalidations might be inconvenient for the
listener. GtkImage for example does not like receiving
invalidate-contents signals when new contents are assigned, but is fine
with them when the old ones go invalid. And it will not try to draw the
paintable in between anyway.
So by bypassing the 2nd emission if nothing was changed, we can make
GtkImage happy.
This error message is printed into the journal if a GTK app can't
connect to eithre Wayland or X11. Make it at least mention who is not
capable of connecting to a server.
Unrelated, we might want to improve our error reporting when a GTK app
can't start, so that debugging issues with system startup / login get
easier to resolve.
When the clip changes that is passed to a snapshot function, we need to
create eventual cached render nodes because they might not have drawn
their whole area before.
Fixes issues with redrawing when scrolling.
When the max cost for finding a path gets to high, the diff can now be
aborted.
Because render nodes have a fallback method (by just marking the whole
bounds of the nodes as different), we use this to improve performance
of diffs.
This brings fishbowl (which is basically a container node with N images
that change every frame) back to close to previous performance.
Now that we have the full render nodes available, there is not much
benefit in fine-grained control over multiple rectangles.
In particular, it's causing pain with complex regions.
There might be a benefit in clipping to the region's rectangles in cases
like widget-factory where the whole diff is made up of the 2 rectangles
of spinner and the pulsing progress bar, but it needs a good heuristic
for where this is useful.
Instead of calling gdk_surface_invalidate_region(), just
gdk_surface_queue_expose() and rely on the renderer computing the diff
from the previous rendering.
... and diff the previous node with the current one to determine the
clip region.
This doubles the work necessary to track clip regions, but the following
commits will clean that up.
It doesn't need to be exported anymore.
As a side effect, the inspector no longer has any information about the
render region, so remove the code that was taking care of that.
Now that we don't clip the created render nodes anymore, we don't have
to compute the clip region beforehand.
So snapshot the render nodes before initializing the renderer.
This includes a copy of the diff(1) algorithm used by git diff by Davide
Libenzi.
It's used for the common case ofcontainer nodes having only very few
changes for the few nodes of child widgets that changed (like a button
lighting up when hilighted or a spinning spinner).
This requires a bunch of refactorings:
1. Don't pass the current clip region to gtk_widget_snapshot()
so we don't create full widget contents
3. Have a widget->priv->draw_needed that we invalidate on every
queue_draw() call and set on every snapshot()
2. In queue_draw(), walk the widget chain to invalidate the
render nodes of all parents
... and gsk_render_node_can_diff(). Those are vfuncs to compute a region
containing all the pixels that differ between the two nodes.
This is just the plumbing that chains into node classes. No node
implements it yet.
delete_range_cb is set to be called before the text suppression done by
the gtktextlayout (otherwise it does not work properly). But at that
point the cursor position is not yet up to date. We thus need to move
the accessibility cursor notification to after the actual text
suppression, by using another callback.
This fixes cursor position in brltty screen reading.
(cherry picked from commit fa6994d033)
The second parameter of the text-changed::delete event is to be the length,
not the end position. This fixes spurious text removals in brltty
screen reading.
(cherry picked from commit 209f908a03)
Like other widgets, this returns a floating reference, so
(transfer full) is wrong. Just omit the annotation as others do,
thus implying (transfer none).
Close https://gitlab.gnome.org/GNOME/gtk/issues/156
This is meant as an input to the font chooser.
We don't want the user to select a language, but
rather have fonts presented as they would work for
the current language. Therefore, do away with the
lang/script combo on the tweak page.
Really exclude the portions in the gtkfontchooserwidget.c that are built
when HarfBuzz and PangoFT2 are built, and update the Meson files to
exclude such sources as well from the main GTK SO/DLL and from the
gtk4-demo program.
https://bugzilla.gnome.org/show_bug.cgi?id=773299
Remove g_auto*() usage from these sources and use the traditional
g_free(), as g_auto*() are GCCisms (or CLangisms).
Also, don't include unistd.h unconditionally and stop including
langinfo.h and dirent.h, since they seem to be unused.
https://bugzilla.gnome.org/show_bug.cgi?id=773299
The demos are now built as GUI programs, which will require the presence
of WinMain() on Visual Studio builds, unless we specify the entry point.
Pass the /entry:mainCRTStartup linker flag on Visual Studio builds for
the demo programs so that they can link properly.
https://bugzilla.gnome.org/show_bug.cgi?id=773299
For some font features, we can figure out affected
glyphs, and show before/after. For some others, we
hardcode typical sequences.
Still to do: figure out how to find ligatures and
show them.
We now properly use GdkFrameTimings and can therefor check for dropping
even a single frame in the history (of 16 frames or 1/4 of a second).
Once that happens, we immediately stop adding new items to the bowl.
A side effect is that the number of icons is now a *lot* smaller.
This ensures that the frame clock gets updated with correct presentation
times even if nothing was drawn.
This is necessary for benchmarking but would also be relevant for videos
that want to sync to the frame clock but draw frames a lot less.
This commit ensures that each GdkSurface impl remembers the
cursor that GDK sets for it, and that this cursor is set
each time WM_SETCURSOR is called for that sufrace's HWND.
This is needed because W32, unlike X, has no per-window cursors -
the cursor on W32 is a global resource, and we need to keep track
of which cursor should be set when pointer is over which surface
ourselves (WM_SETCURSOR exists exactly for this reason).
This commit also makes GDK remember the surface that has an implicit
grab (since implicit grabs are gone from the upper levels of the toolkit),
and ensures that crossing events are correctly synthesized and the grab
is broken when surface focus changes. This fixes a bug where opening
a new window (by clicking something in some other, pre-existing window)
will make that new window not get any mouse input due to the fact
that the mouse-button-down event from that click caused an implicit
grab on the pre-existing window, and that grab was not released afterward.
Instead of now-unused GdkWin32Cursor class (a subclass of GdkCursor),
add a stand-alone GdkWin32HCursor class that is a wrapper around
HCURSOR handle.
On creation it's given a display instance, a HCURSOR handle and a boolean
that indicates whether the HCURSOR handle can or cannot be destroyed
(this depends on how the handle was obtained).
That information is stored in a hash table inside the GdkWin32Display
singleton, each entry of that table has reference count.
When the GdkWin32HCursor object is finalized, it reduces the reference
count on the table entry in the GdkWin32Display. When it's created,
it either adds such an entry or refs an existing one.
This way two pieces of code (or the same piece of code called
multiple times) that independently obtain the same HCURSOR from the OS
will get to different GdkWin32HCursor instances, but GdkWin32Display
will know that both use the same handle.
Once the reference count reaches 0 on the table entry, it is freed
and the handle (if destroyable) is put on the destruction list,
and an idle destruction function is queued.
If the same handle is once again registered for use before the
idle destructior is invoked (this happens, for example, when
an old cursor is destroyed and then replaced with a new one),
the handle gets removed from the destruction list.
The destructor just calls DestroyCursor() on each handle, calling
SetCursor(NULL) before doing that when the handle is in use.
This ensures that SetCursor(NULL) (which will cause cursor to disappear,
which is bad by itself, and which will also cause flickering if the
cursor is set to a non-NULL again shortly afterward)
is almost never called, unless GTK messes up and keeps using a cursor
beyond its lifetime.
This scheme also ensures that non-destructable cursors are not destroyed.
It's also possible to call _gdk_win32_display_hcursor_ref()
and _gdk_win32_display_hcursor_unref() manually instead of creating
GdkWin32HCursor objects, but that is not recommended.
If GtkExpander:sensitive was FALSE, the arrow still got the normal fg
colour, which made it look clickable, in contrast to the adjacent label.
Fix this by adding selectors to catch the applicable :disabled states.
Note: Needing these may indicate an oops in generic styles elsewhere,
but I couldn’t see any, so let’s just get it looking right for now.
Close https://gitlab.gnome.org/GNOME/gtk/issues/146
Add a new W32 backend-specific message filtering mechanism.
Works roughly the same way old event filtering did, but without
events (events are GDK/X11 concept that never really made sense
on W32), so there's no functionality for 'altering' events being
emitted. If an event needs to be emitted in response to a message
do it yourself.
Implemented like this, it should give better performance than
if we were to use GLib signals for this, since W32 sends a LOT
of messages (unlike X11, which doesn't send events as often)
all the time, and invoking the signal machinery on *each* message
would probably be bad.
https://bugzilla.gnome.org/show_bug.cgi?id=773299
Rename GdkWin32Selection to GdkWin32Clipdrop, since GdkSelection
is mostly gone, and the word "selection" does not reflect the
functionality of this object too well.
Clipboard is now handled by a separate thread, most of the code for
it now lives in gdkclipdrop-win32.c, gdkclipboard-win32.c just uses
clipdrop as a backend.
The DnD source part is also put into a thread.
The DnD target part does not spin the main loop, it just
emits a GDK event and returns a default value if it doesn't get a reply
by the time the event is processed.
Both clipboard and DnD use a new GOutputStream subclass to get data
from GTK and put it into a HGLOBAL.
GdkWin32DragContext is split into GdkWin32DragContext and GdkWin32DropContext,
anticipating a similar change that slated to happen to GdkDragContext.
OLE2 DnD protocol is now used by default, set GDK_WIN32_OLE2_DND envvar to 0
to make GDK use the old LOCAL and DROPFILES protocols.
https://bugzilla.gnome.org/show_bug.cgi?id=773299
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.");
Разъяренный чтец эгоистично бьёт пятью жердями шустрого фехтовальщика. Наш банк вчера же выплатил Ф.Я. Эйхгольду комиссию за ценные вещи. Эх, чужак, общий съём цен шляп (юфть) – вдрызг! В чащах юга жил бы цитрус? Да, но фальшивый экземпляр!
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.");
@@ -32,7 +32,7 @@ media-view-subtitles=The icon used to show subtitles in a media player
[network]
Name=Network
Description=Icons related to network status");
Description=Icons related to network status
network-transmit-receive=The icon used data is being both transmitted and received simultaneously, while the computing device is connected to a network
network-transmit=The icon used when data is being transmitted, while the computing device is connected to a network
<para>You may have noticed that we used the <literal>_from_resource(<!---->)</literal> variant
of the function that sets a template. Now we need to use GLib's resource
functionality to include the ui file in the binary. This is commonly
done by listing all resources in a .gresource.xml file, such as this:
of the function that sets a template. Now we need to use <ulinkurl="https://developer.gnome.org/gio/stable/GResource.html">GLib's resource functionality</ulink>
to include the ui file in the binary. This is commonly done by listing
all resources in a .gresource.xml file, such as this:
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.
