13 bytes in 1 blocks are definitely lost in loss record 766 of 16,875
at 0x4C2DB9D: malloc (vg_replace_malloc.c:299)
by 0xA9D0247: vasprintf (in /usr/lib64/libc-2.24.so)
by 0xA2453FC: g_vasprintf (gprintf.c:316)
by 0xA2152F7: g_strdup_vprintf (gstrfuncs.c:514)
by 0xA21539C: g_strdup_printf (gstrfuncs.c:540)
by 0x678F25C: gdk_rgba_to_string (gdkrgba.c:360)
by 0x5FAE00D: rgba_to_string_noalpha (gtkicontheme.c:4322)
by 0x5FAE6F2: gtk_icon_info_load_symbolic_svg (gtkicontheme.c:4492)
by 0x5FAED4F: gtk_icon_info_load_symbolic_internal (gtkicontheme.c:4622)
by 0x5FAEEE8: gtk_icon_info_load_symbolic (gtkicontheme.c:4711)
by 0x5F00246: gtk_css_image_recolor_load (gtkcssimagerecolor.c:118)
by 0x5F003E4: gtk_css_image_recolor_compute (gtkcssimagerecolor.c:170)
14 bytes in 1 blocks are definitely lost in loss record 801 of 16,875
at 0x4C2DB9D: malloc (vg_replace_malloc.c:299)
by 0xA9D0247: vasprintf (in /usr/lib64/libc-2.24.so)
by 0xA2453FC: g_vasprintf (gprintf.c:316)
by 0xA2152F7: g_strdup_vprintf (gstrfuncs.c:514)
by 0xA21539C: g_strdup_printf (gstrfuncs.c:540)
by 0x678F25C: gdk_rgba_to_string (gdkrgba.c:360)
by 0x5FAE00D: rgba_to_string_noalpha (gtkicontheme.c:4322)
by 0x5FAE68E: gtk_icon_info_load_symbolic_svg (gtkicontheme.c:4482)
by 0x5FAED4F: gtk_icon_info_load_symbolic_internal (gtkicontheme.c:4622)
by 0x5FAEEE8: gtk_icon_info_load_symbolic (gtkicontheme.c:4711)
by 0x5F00246: gtk_css_image_recolor_load (gtkcssimagerecolor.c:118)
by 0x5F003E4: gtk_css_image_recolor_compute (gtkcssimagerecolor.c:170)
15 bytes in 1 blocks are definitely lost in loss record 838 of 16,875
at 0x4C2DB9D: malloc (vg_replace_malloc.c:299)
by 0xA9D0247: vasprintf (in /usr/lib64/libc-2.24.so)
by 0xA2453FC: g_vasprintf (gprintf.c:316)
by 0xA2152F7: g_strdup_vprintf (gstrfuncs.c:514)
by 0xA21539C: g_strdup_printf (gstrfuncs.c:540)
by 0x678F25C: gdk_rgba_to_string (gdkrgba.c:360)
by 0x5FAE00D: rgba_to_string_noalpha (gtkicontheme.c:4322)
by 0x5FAE6C3: gtk_icon_info_load_symbolic_svg (gtkicontheme.c:4487)
by 0x5FAED4F: gtk_icon_info_load_symbolic_internal (gtkicontheme.c:4622)
by 0x5FAEEE8: gtk_icon_info_load_symbolic (gtkicontheme.c:4711)
by 0x5F00246: gtk_css_image_recolor_load (gtkcssimagerecolor.c:118)
by 0x5F003E4: gtk_css_image_recolor_compute (gtkcssimagerecolor.c:170)
16,384 bytes in 1 blocks are definitely lost in loss record 16,847 of 16,875
at 0x4C2DADE: malloc (vg_replace_malloc.c:298)
by 0x4C2FC91: realloc (vg_replace_malloc.c:785)
by 0xA1F89FA: g_realloc (gmem.c:159)
by 0xA1BAD2E: g_array_maybe_expand (garray.c:779)
by 0xA1BA566: g_array_set_size (garray.c:555)
by 0xA1BBCB8: g_byte_array_set_size (garray.c:1752)
by 0x8D1CC48: g_file_load_contents (gfile.c:6766)
by 0x5FAE767: gtk_icon_info_load_symbolic_svg (gtkicontheme.c:4501)
by 0x5FAED4F: gtk_icon_info_load_symbolic_internal (gtkicontheme.c:4622)
by 0x5FAEEE8: gtk_icon_info_load_symbolic (gtkicontheme.c:4711)
by 0x5F00246: gtk_css_image_recolor_load (gtkcssimagerecolor.c:118)
by 0x5F003E4: gtk_css_image_recolor_compute (gtkcssimagerecolor.c:170)
https://bugzilla.gnome.org/show_bug.cgi?id=772215
The relative-to widget may be reparented itself into/out of a
scrollable. In this cases make the hierachy-changed handler to
unset the parent scrollable when unparented, and look up again
the parent scrollable after it's reparented.
https://bugzilla.gnome.org/show_bug.cgi?id=771812
gtk_popover_set_scrollable_full() takes care of the signal connected
on the scrollable itself, in addition to the adjustment signals the
popover listens to.
gtk_popover_update_scrollable() looks up the current relative-to
widget hierarchy and updates the current scrollable.
The places where the scrollable is being maintained have been updated
to use these functions.
https://bugzilla.gnome.org/show_bug.cgi?id=771812
Opaque region, margin and input region were only being synced when a cairo
paint happened. That caused GL paints to sometimes end up with bad state.
Move calls to sync state to gdk_window_impl_wayland_end_paint.
https://bugzilla.gnome.org/show_bug.cgi?id=771553
Setting the shadow width earlier as done with commit 4cb1b96 to address
bug 771561 proved to cause unexpected side effects on size_allocate
signal propagation.
As the window is sized correctly earlier, the size_allocate signal is
not emitted again in gtk_widget_size_allocate_with_baseline() which
prevents clutter-gtk from relocating its child widget correctly.
To avoid this issue, revert commit 4cb1b96 but make sure the values
passed as min and max size is never negative in Wayland as this is a
protocol error.
With this, the min/max size will be wrong for a short amount of time,
during the state transition, until the shadow width is updated from
gdk_window_set_shadow_width().
This approach is much safer and less intrusive than changing the
size_allocate logic in gtk.
This reverts commit 4cb1b9645e.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=771915
After checking for rendered_surface, the call to gtk_css_node_get_style
can invalidate the style and result in rendered_surface being set to
NULL. This was result in some icon views appearing blank on
Endless OS on armv7hl, and this error:
Gtk-CRITICAL **: gtk_css_style_render_icon_surface: assertion 'surface != NULL' failed
Call gtk_css_node_get_style earlier to ensure we always pass a valid
surface to gtk_css_style_render_icon_surface.
https://bugzilla.gnome.org/show_bug.cgi?id=765649https://phabricator.endlessm.com/T13524
This was meant to be silenced unless expicitly requested but
G_ENABLE_DEBUG is defined by default unless --disable-debug is passed to
configure, so use G_ENABLE_CONSISTENCY_CHECKS instead which is only
defined if --enable-debug is explicitly passed.
add circle objects to the injected style for recoloring.
Should avoid randomly colored symbolic icon bits when circles are
in the mix as in network-vpn-acquiring-symbolic for example.
Otherwise, with CSD, we could have a discrepancy where gtk uses the
right values for the shadows whereas the gdk backend still uses the old
values, leading in some cases to invalid or negative min size being
computed (which, in Wayland, leads a protocol error).
https://bugzilla.gnome.org/show_bug.cgi?id=771561
The GLib main loop blocks on MsgWaitForMultipleObjectsEx to
determine if there are any incoming messages while also allowing
for background tasks to run. If all available messages are not
processed after MsgWaitForMultipleObjectsEx has signaled that
there are available, CPU usage will skyrocket.
From my limited understanding (by inspection of profiling
under Visual Studio):
Key is pressed - MsgWaitForMultipleObjectsEx unblocks, and
sends message to GDK's event handler. Some event is now queued.
g_poll unblocks, calls the g_event_dispatch which finally
resolves to gdk_event_dispatch. This then calls
_gdk_win32_display_queue_events, but since a message is already
queued, it fails to call PeekMessage and returns immediately.
At the next iteration, g_poll again calls MsgWaitForMultipleObjectsEx
which queues yet another event and returns almost immediately, since
there are events available which haven't been processed by PeekMessage.
The dispatch function is then called and the process repeats.
https://bugzilla.gnome.org/show_bug.cgi?id=771568
The main corpus of the documentation for gtk_window_get_size() is still
full of X11-isms, so we should port it to something that is more
backend-agnostic. Additionally, having some examples would be nice for
application authors looking at a way to appropriately use this function.
If somebody decides to use gtk_widget_set_double_buffered() in the
middle of a draw() then there's the risk of calling end_draw_frame()
with an invalid pointer.
Some overeager compilers may warn about the double_buffered bit field
changing values and leading to a potentially uninitialized variable.
In order to avoid compiler warnings or crashes, we can simply store the
value of the double_buffered bit field at the beginning of the rendering
and use that instead of the actual bit field.
https://bugzilla.gnome.org/show_bug.cgi?id=771463
Not all occurrences of this warning can be fixed today, so put it behind
a G_ENABLE_DEBUG flag since it still shows legitimate problems even if
some of them are false positives.
A popup may have moved and resized when configured. Make sure every
layer knows about this and call gdk_window_move_resize() with the
configured dimension and position. This won't actually move the
window, but might resize it.
https://bugzilla.gnome.org/show_bug.cgi?id=771117
The result of move_to_rect, received from the xdg_popup.configure
event, needs to be translated to the correct coordinate space; that is
from real parent window geometry to coordinates relative to the gdk
window set as transient-for.
https://bugzilla.gnome.org/show_bug.cgi?id=771117
Use a helper to translate a coordinate from non-real GdkWindow parent
to window geometry coordinate space of the real GdkWindow parent,
meaning the coordinate space of the GdkWindow of the parent used as a
xdg_popup parent where (0, 0) is inside of the shadow margin.
https://bugzilla.gnome.org/show_bug.cgi?id=771117
When using the dynamic positioner (i.e. positioning from move_to_rect)
we can always rely on having a proper transient-for to position
relative to, so lets drop the ignored parameter.
https://bugzilla.gnome.org/show_bug.cgi?id=771117
Move the code used for calculating the result of move_to_rect
(final_rect, flipped_rect etc) closer to the other move_to_rect
functions (i.e. next to create_dynamic_positioner), and let the
xdg_popup configure handler just call the calculation function.
https://bugzilla.gnome.org/show_bug.cgi?id=771117
If an application umaps the toplevel from its popup callback, this can
lead to a protocol error.
Make sure we mark popup parent and use that to check if their parent is
the toplevel being unmapped in which case we shall unmap the popup first
to avoid the protocol error.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=770906
The fix for bug 767468 had some unintended side-effects. This is
an attempt at doing the same fix (don't grab focus when we are
grab-shadowed), while avoiding the breakage, by using GTK+'s
internal tracking for grab-shadowed-ness.
https://bugzilla.gnome.org/show_bug.cgi?id=770508
Analogous to (un)mount operation, we now keep a reference around
during the ongoing operation and make use of the destroyed flag
to check if we are still alive or if we have been cancelled as
a result of the widget being destroyed.
https://bugzilla.gnome.org/show_bug.cgi?id=764979
Since we hold on to a reference during (un)mount operations, we
don't trigger the cancellation of operations in finalize anymore.
Instead we now override the GtkWidget's destroy() and cancel any
ongoing operations there.
https://bugzilla.gnome.org/show_bug.cgi?id=764979
The current code wrongly assumes that cancellation can only happen
as a result widget finalization, and consequentially does not
properly recover from it. Therefore if the operation is cancelled
as a result of user interaction, the entry is will stay disabled
and the spinner will keep spinning. This is fixed by removal of
the early bail out in case of cancellation.
https://bugzilla.gnome.org/show_bug.cgi?id=764979
During mount and unmount opertions we keep a reference to the
GtkPlacesView around, so we have a valid view for the callback
code, even in the case that othe external references have been
dropped (i.e. the containing window gets destroyed).
https://bugzilla.gnome.org/show_bug.cgi?id=764979
RandR 1.5 is enabled on VirtualBox guest of Fedora 25 but
XRROutputInfo->name is "default". If init_randr15() does not
return TRUE, the monitor size sets 0 because gdk_screen_get_width()
returns 0.
This problem causes GtkStatusIcon not to show the activate menu.
https://bugzilla.gnome.org/show_bug.cgi?id=771033
This reverts commit 6af5033386.
Scrolled window behavior of propagating child natural sizes
has now been made optional, so there is no need to work around
this by setting a hard coded maximum content height anymore.
This reverts commit 76af907676.
The behavioral change described in the migration guide
has now been made optional with new scrolled window API,
so no need to mention this in the migration guide.
This reverts commit 37e913d76b.
This is no longer needed since the natural size propagation of
scrolled window children is now an optional behavior. Reverting
this also makes the widget factory scrolled window sizes behave
the same as with the gtk+ 3.20 branch.
In gtkscrolledwindow.c, the return type of _get_propagate_natural_width()
and _get_propagate_natural_height() were accidentally gint instead of
gboolean, fixed to match the type correctly declared in the header file.
The code always assumed that getting a row at a certain 'y' was
possible but if the list box has more empty space than rows then a
valid row may not be retrieved.
https://bugzilla.gnome.org/show_bug.cgi?id=770703
- while we don't use steppers anymore, for some reason they are still
defined in the theme and if you sacrifice a chicken and jump on one
leg at full moon, you can enable them.
https://bugzilla.gnome.org/show_bug.cgi?id=769498
When a popup is mapped but will not be the top most popup (for example
the parent is not the current top most popup, or if there already is a
popup mapped but the parent is a toplevel), warn and ignore it instead
of continuing, as continuing would be a protocol violation.
https://bugzilla.gnome.org/show_bug.cgi?id=770745
Since we're using _get_rect_coords in size-allocate when allocating the
size of the child widget, use the newly introduced _get_rect_for_size to
calculate the difference between the passed size_for and the one we're
supposed to pass on to the child widget.
When calculating the requested size of a popover, we need to do the
exact same same thing _get_rect_coords did, but not for the
current popopver allocation. Add _get_rect_for_size that can be used for
this purpose
Making propagation of child natural sizes mandatory (or default, even) was
evidently a mistake as this causes dynamic content in a scrolled window
to resize it's parent when the scrolled window is competing for space
with an adjacent widget.
This patch instead adds API to control whether natural width and
height of the child should be propagated through the scrolled windows
size requests.
There was a return between a push/pop of an error trap, and
this managed to trigger the 'unpopped trap' warning in the
displayclose test now. Fix this.
Add an API that enables an application to, given an exported window
handle, set its own window as a transient of the window associated with
the exported window handle.
https://bugzilla.gnome.org/show_bug.cgi?id=769788
We were using __VOID for the SHOW_OTHER_LOCATION signal that
uses flags named SHOR_OTHER_LOCATION_WITH_FLAGS.
However, if a signal uses flags the marshal needs to use __FLAGS.
This patch addresses this using VOID__FLAGS as the marshaler parameter.
Thanks to Jan Steffens for pointing this out.
https://bugzilla.gnome.org/show_bug.cgi?id=770550
Only set input, opaque and window geometry regions once per commit.
They are double buffered anyway, so the last one would only take effect
either way; this way reading protocol logs are much more pleasent.
https://bugzilla.gnome.org/show_bug.cgi?id=769937
There is annoying interference between formatting the value
(for which we set the number of digits to show) and the small
frame-to-frame value changes that we do for autoscrolling.
To work around this, turn off the digits-based rounding entirely
and format the value ourselves with ::format-value.
And rename it to "Touch and Drawing Tablets", since it's no longer about
"axes" really.
As for pad support in the demo, just keep it "simple", make the
controller handle all pad devices, and make all the actions have the
same callback.
https://bugzilla.gnome.org/show_bug.cgi?id=770026
The wayland tablet protocol allows notifying the compositor with
descriptions of the actions performed by each tablet element. This
API call allows to hook up in to this wayland-specific feature.
https://bugzilla.gnome.org/show_bug.cgi?id=770026
These devices are kind of an strange case. Their "master" device is
the keyboard, because they share toplevel focus with it, regardless
of stylus focus. Nonetheless, they are only expected to send the
GdkEventPad* set of events.
https://bugzilla.gnome.org/show_bug.cgi?id=770026
This is a subclass of GdkWaylandDevice that implements GdkDevicePad,
all pad features are looked up from the info obtained through the
tablet v2 interface.
https://bugzilla.gnome.org/show_bug.cgi?id=770026
This GdkEventController is a helper object to handle pad events,
it allows setting a mapping to action names, to be triggered in
the given action group.
In order to help on places where advanced mapping/configurability
of pad features is not desirable, this controller also allows
passing a NULL pad device, meaning it will listen on all pads,
and/or passing -1 on mode/index, so an action applies to all
modes/features (eg. strips/rings).
https://bugzilla.gnome.org/show_bug.cgi?id=770026
This is an interface meant to be implemented by the "pad" devices.
This device-specific interface exposes the mapping of all pad features,
it allows retrieving:
- The number of buttons/rings/strips
- The number of groups
- The number of modes a group has
- Whether a given button/ring/strip belongs to a given group
https://bugzilla.gnome.org/show_bug.cgi?id=770026
We want the same treatment for those, the event will be emitted on the
toplevel, which will then decide what to do with the event.
It just doesn't make much sense to propagate those up/down the hierarchy,
when we want specifically one action being triggered from those.
https://bugzilla.gnome.org/show_bug.cgi?id=770026
GDK_PAD_BUTTON*,RING and STRIP will be emitted respectively when
pad buttons, rings or strips are interacted with. Each of those
pad components belong to a group (a pad can contain several of
those), which may be in a given mode. All this information is
contained in the event.
GDK_PAD_GROUP_MODE is emitted when a group in the pad switches
mode, which will generally result in a different set of actions
being triggered from the same buttons/rings/strips in the group.
https://bugzilla.gnome.org/show_bug.cgi?id=770026
An xdg-popup requires a serial that the compositor will compare against
its own serial and will dismiss the popup if it doesn't match.
gtk+ uses either a pointer or touch serial for its helper function
_gdk_wayland_seat_get_last_implicit_grab_serial() but if the menu is
triggered before the user has had any pointer or touch interaction with
the client, using a keyboard shortcut, there is neither pointer nor
touch serial available, and gtk+ will use 0 as the default.
As a result, the compositor will instantly dismiss the xdg-popup. In
this case, gtk+ should use the keyboard serial instead.
Track keyboard serial as well and use the keyboard serial as the value
if there is no newer pointer or touch serial available.
https://bugzilla.gnome.org/show_bug.cgi?id=768017
At the time of move_to_rect() is called, not all state may have been set
up on the impl gdk window, causing the position to sometimes be
slightly offset due to drap shadow margins. For now, work around this
by postponing the processing of the move_to_rect() parameters until
showing, when its more likely that all state (such as shadow margin)
has been set correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=769402
The Wayland backend manages a set of fake root coordinate spaces, where
each non-relative positioned toplevel (i.e. not popups, popovers,
tooltips etc) make up the basis of separate fake root coordinate spaces.
This means that the Wayland backend doesn't have the abilitiy get a
proper root coordinate when querying on a non-toplevel GdkWindow. To
avoid this issue, first find the toplevel, while translating the anchor
rect coordinates so that they are in the toplevel window coordinate
space. Then use this toplevel to translate the coordinates to root
window coordinate space.
https://bugzilla.gnome.org/show_bug.cgi?id=769402
The position of each transient-of will be in fake-root coordinate
space; thus we should not accumulate all the positions making it an
offset; each window is already in fake root coordinate space.
https://bugzilla.gnome.org/show_bug.cgi?id=769402
When using the set transient-for as a popup parent, fetch the effective
toplevel instead, otherwise we will position against the wrong
coordinate.
https://bugzilla.gnome.org/show_bug.cgi?id=769402
The effect of transitions-enabled=true can now be
achieved using gtk_popover_popup/popdown and the effect
of transitions-enabled=false can be achieved using
gtk_widget_show/hide.
https://bugzilla.gnome.org/show_bug.cgi?id=769706
Since not chaining up in gtk_widget_show/gtk_widget_hide is not allowed,
we can't just implicitly delay the hiding in GtkPopover's hide
implementation. Fix this by introducing gtk_popover_popup() and
gtk_popover_popdown() to show or hide a popover with transition and
revert GtkPopover's show/hide implementation to apply their effect
without the transition.
https://bugzilla.gnome.org/show_bug.cgi?id=769706
The order in which tooltips are created, drawn, shown and then positioned,
always requires repositioning the surface. The tooltip window type only has
limited capability to do so. An alternative could be to use bufferstreams.
https://bugzilla.gnome.org/show_bug.cgi?id=768138
When a dialog is created, the mir event source is already executed on the
call stack. So without the recurse flag it will not be run in the main loop
used for the dialog.
https://bugzilla.gnome.org/show_bug.cgi?id=768138
The event will be sent when the surface becomes visible on an output. With this change the GdkMirWindowImpl keeps track of the scale value and sends a configure event on change.
Signed-off-by: Andreas Pokorny <andreas.pokorny@canonical.com>
The config.rpath script was added by running gettextize, but it's not
really needed, as config.rpath is generated by autotools and it's
included in the dist tarball automatically.
Upstream gettextize has been fixed so it does not happen any more:
http://savannah.gnu.org/bugs/index.php?48729
The GtkHeaderBar gadget implementation was subtly broken: it called
gtk_widget_set_allocation both in gtk_header_bar_size_allocate (with
the actual allocation) and in gtk_header_bar_allocate_contents (with
the content allocation of the main gadget). Dropping the second call
fixes the render node conversion for GtkHeaderBar.
The event code could potentially dereference pointer_info if the
invariant that ENTER_NOTIFY and LEAVE_NOTIFY events are only emitted on
devices which have pointers is violated elsewhere.
Found with scan-build.
https://bugzilla.gnome.org/show_bug.cgi?id=712760
In order to eliminate g_test_expect_message() (which doesn’t work with
G_LOG_USE_STRUCTURED), make the warning about the fallback theme not
existing be conditional on the icon theme search path containing a
system path. Any application code which modifies the search path does so
through appends and prepends, so this should not affect whether the
warning is emitted in production.
https://bugzilla.gnome.org/show_bug.cgi?id=769485
:toggled is triggered on :clicked, so using :toggled lead to the menu
to be popped up at the same time, while allowing to use the toggle state
and avoiding any need to a hack to prevent recursion, which somehow
wasn't enough for double emission of GtkMenuToolButton:show-popup.
https://bugzilla.gnome.org/show_bug.cgi?id=769287
Pick the W32 API for possible deadkey+<something> combinations
and prefer these to other sources of deadkey combos.
Specifically, if W32 API supports at least one combo for a particular
deadkey, only use that data and do not attempt to do other, unsupported
combinations, even if they make sense otherwise.
This is needed to, for example, correctly support US-International
keyboard layout, which produces a combined character for <' + a>
combo, but not for <' + s>, for example.
This is achieved by stashing all the deadkeys that we find in
an array, then doing extra loop through all virtual key codes and
trying to combine them with each of these deadkeys. Any combinations
that produce a single character are cached for later use.
In GTK Simple IM context, call a new GDK W32 function to do a lookup
on that cached combination table early on, among the "special cases"
(which are now partially obsolete).
A limitation of this code is that combinations with more than
one deadkey are not supported, except for combinations that consist
entirely of 2 known deadkeys. The upshot is that lookups should
be relatively fast, as deadkey array stays small and the combination
tree stays shallow.
Note that the use of ToUnicodeEx() seems suboptimal, as it should
be possible to just load a keyboard library (KBD*.DLL) manually
and obtain and use its key table directly. However, that is much more
complicated and would result in a significant rewrite of gdkkeys-win32.
The code from this commit, though hacky, is a direct addition to
existing code and should cover vast majority of the use-cases.
https://bugzilla.gnome.org/show_bug.cgi?id=569581
This changes the group/level semantic.
Previously W32 backend used "group 0/1" to denote "AltGr OFF/ON"
and "level 0/1" to denote "Shift is OFF/ON".
Now "group" means "keyboard layout" and there can be up to 255 groups,
while AltGr and Shift are combined into a single level enum that
takes values between 0 and 4.
Unlike X, W32 doesn't do effective group overriding, meaning that
it will never tell the caller that a different group was actually
used (even for universal keys, such as Enter), because key symbol
table is completely fabricated and there's no point in trying to
save a few of kilobytes of RAM by not duplicating universal key
records for all groups.
Also contains many whitespace changes (tab elimination, fixed
indentation) and cleanup (axed a few global variables, these are
now accessed via the default keymap).
https://bugzilla.gnome.org/show_bug.cgi?id=768722
GTK+ has two directories for translations: the default 'po' and the
additional 'po-properties' for the GObject properties translation
domain.
Since the content of the translations directories are filled by
autoreconf and gettext, and are duplicated between the two gettext
domains we use, we should handle this ad hoc inside git.mk, instead of
trying to catch up by adding po-properties files in GITIGNOREFILES.
The contents of the macro directory are too complicated for git.mk to
handle: the contents are filled by autotools and may change between
systems or autotools releases; and we additionally ship our own m4
macros.
To avoid unnecessary noise on the `git status` output we should simply
add an ignore file specifically for the macro directory.
The new positioning-related properties had some quality of
implementation issues, such as incorrect initial values and
excessive change notification. This broke the notify test.
It tried to set the expand state if either xexpand/yexpand where true.
Due to a missing queue_compute_expand when adding a child it actually
only computed the expand state in case a child queued after being added
or in case a child had the expand property set (see optimization in
gtk_widget_set_parent)
In my case this broke layouts as a child of GtkCombBox started setting
an exand flag with 3.20 which queued a compute_expand, which in turn
propagated an expand child props set for a cell in the same table up
and overrode the expand child prop of a parent GtkBox.
This removes the custom compute_expand implementation to match the
behaviour of GtkBox (don't propagate child prop expand flags
but let child expand flags override the child props) and not get random
expand behaviour depending on whether and when child widgets set their
expand state.
https://bugzilla.gnome.org/show_bug.cgi?id=769162
gtk+/demos/gtk-demo/css_blendmodes.c: In function ‘update_css_for_blend_mode’:
gtk+/demos/gtk-demo/css_blendmodes.c:49:26: error: format not a string literal, argument types not checked [-Werror=format-nonliteral]
blend_mode);
^~~~~~~~~~
https://bugzilla.gnome.org/show_bug.cgi?id=769236
The error was:
gtk3-scan.c:193: undefined reference to `gtk_shortcuts_label_get_type'
collect2: error: ld returned 1 exit status
It's since commit 7543cd8ce4, which made
the GtkShortcutLabel class public.
Introduce a private API meant for abstracting how to get a handle
of a window that can be shared with other processes. The API is
async, since some implementations will require that. Currently,
only X11 is supported, which doesn't.
Based on a patch by Jonas Adahl.
When there's no useful shortcut accelerator set,
GtkShortcutLabel doesn't show any useful information.
To work around that, add a new property to set the
text to be displayed when there's no accelerator
available.
https://bugzilla.gnome.org/show_bug.cgi?id=769205
GtkShortcutLabel is a widget that displays a single
shortcut accelerator or gesture in the user interface,
and is currently used by the shortcuts window.
This widget, however, has public value as other applications
also may want to expose their own shortcuts. For instance,
it'll be useful for the Keyboard panel on Control Center and
the new shortcut editor in Pitivi, among others.
This patch exposes GtkShortcutLabel as a public widget,
and adds the necessary documentation.
https://bugzilla.gnome.org/show_bug.cgi?id=769205
Scroll history must refer to a timespan for the values to be valid, otherwise
we return FALSE, in this case the stored event(s) should be discarded anyway.
It could be the case that the last scroll event is received long after any
previous scroll event, in this case the last scroll event discards all "old"
scroll events, and scroll_history_finish() returns FALSE because there's no
time/offset deltas in the scroll history.
This is desired so we don't trigger the deceleration effect if there was no
effective velocity, we still must reset the installed scroll cursor, so take
it out of this if() condition.
I thought I needed ot rearrange the ordering of the animation-direction
values for the parser, overlooking the fact that we already parse them
backwards to address this very problem.
It is important to know whether the returned object can or cannot
change, for a certain widget. For example to connect to the
GtkStyleContext::changed signal.
https://bugzilla.gnome.org/show_bug.cgi?id=769047
Always return an error if we fail to get a dbus proxy; the callers
are only looking whether error is set, not whether the return value
is NULL.
Use the same function for the inhibit proxy as well, and clean up
the sm_proxy in finalize.
Only update to using v2 headers/structs. The incompatible changes
to tool events are dealt with in the next commit. Pads aren't handled
in this commit either.
In the "Other Locations" view, locations can be opened from the context menu
based on their mount or volume. However, some locations, like "Computer", do not
have either of those so they cannot be opened from the context menu. In order to
fix this, the file associated with the location can be used as well.
https://bugzilla.gnome.org/show_bug.cgi?id=768657
The sizes passed are in device pixels and do not take into account the
scaling factor of the window itself. We cannot change the semantics of
the function, so let's at least add a warning for this trap door.
xdg-desktop-portal now has a portal for inhibiting session status
changes. We don't need to use it if we can talk to the session
manager, but if can't, try org.freedesktop.portal.Inhibit.
https://bugzilla.gnome.org/show_bug.cgi?id=768499
This commit adds API for adding combo boxes and check buttons to
GtkFileChooser, and getting the selected value back in ::response.
In contrast to gtk_file_chooser_set_extra_widget, these APIs are
abstract and suitable for implementation in GtkFileChooserNative.
https://bugzilla.gnome.org/show_bug.cgi?id=768499
Implement GtkFileChooserNative for sandboxed applications
by talking to org.freedesktop.portal.FileChooser. Currently,
this supports OPEN and SAVE mode.
https://bugzilla.gnome.org/show_bug.cgi?id=768499
The gtk_show_uri API doesn't let us specify a parent window. With
portals, there may be an intermediate dialog, for which it is nice
to have parent window information, to place it properly.
https://bugzilla.gnome.org/show_bug.cgi?id=768499
If we have an application that never goes idle (or takes a long time to
go idle), the close buttons in CSD decoration don't work properly.
While it's not clear why the usage of an idle was added in the first
place, keep on using it to avoid unexpected reentrancy problems, but
change the priority to G_PRIORITY_DEFAULT.
https://bugzilla.gnome.org/show_bug.cgi?id=768485
On X11, device_query_state() uses XIQueryPointer() which will return a
child window only if the pointer is within an actual child of the given
window.
Wayland backend would return the pointer->focus window independently of
the given window, but that breaks the logic in get_device_state() and
later in gdk_window_get_device_position_double() because the window is
searched based on coordinates from another window without sibling
relationship, breaking gtkmenu sub-menus further down the line.
Fix the Wayland backend to mimic X11's XIQueryPointer() to return a
child only if really a child of the given window.
That's the most sensible thing to do to fix the issue, but the API here
seems to be modeled after the X11 implementation and the description of
gdk_window_get_device_position_double() is not entirely accurate.
https://bugzilla.gnome.org/show_bug.cgi?id=768016
Our property parser stops at the first match when looking for
enums, so we need to order our values so that we don't end up
with prefixes of longer names being found first.
I noticed this when the parser tried to interpret
background-blend-mode: color-burn; as "color, with junk at the end".
It also affects animation-direction, which is also fixed here.
After introducing the CSS blend mode enum values and including
the background-blend-mode CSS property, it is very important to
actually provide an example of the new feature.
This patch adds a new demo to gtk3-demo which shows how the
background-blend-mode CSS property works.
https://bugzilla.gnome.org/show_bug.cgi?id=768305
CSS supports blend modes, in which a series of layers are
merged together according to the given operation or set of
operations.
Support for blend modes landed on Cairo, which exposes all
the commons and also the exquisites blend modes available.
Adding support for blend modes, then, is just a matter of
using the available Cairo operations.
This patch adds the background-blend-mode CSS enum property,
and adapts the background rendering code to blend the backgrounds
using the available blend modes when they're set.
https://bugzilla.gnome.org/show_bug.cgi?id=768305
Xfce4-session-manager added support for managing dbus based clients.
This patch adds support for checking if Xfce session manager is
around after trying the gnome one.
https://bugzilla.gnome.org/show_bug.cgi?id=693203
I was struggling to understand why calling
gtk_print_unix_dialog_set_manual_capabilities (...,0)
was not having the expected effect of hiding the preview
button. The initial capabilities were not applied at all.
This has most notably impact in selection buffers, because those were
shared across all selection atoms. This turned out wrong on 2 situations:
- Because the selection atom was set at SelectionBuffer creation time, the
GDK_SELECTION_NOTIFY events generated will have unexpected info if the
buffer is attempted to be reused for another selection.
- Anytime different selections imply different stored content for the same
target.
This is better separated into per-selection buffers, so it's not possible
to get collisions if a same target is used across different selections.
https://bugzilla.gnome.org/show_bug.cgi?id=768177
The sanitize_utf8() function has been copied from X11 so both
backends behave the same. This allows interaction with older clients
(mainly through Xwayland, and the STRING selection target) that
request non-utf8 text.
https://bugzilla.gnome.org/show_bug.cgi?id=768082
commit 0015ebc4a8 reworked
some of the titlebar size allocation code. Those changes
inadvertently introduced a warning when the application sets
the headerbar title widget to be hidden.
This commit fixes that warning.
https://bugzilla.gnome.org/show_bug.cgi?id=768184
This partly reverts 9f5b9c0e07, which
removed the check for GtkWidget-window-dragging in the multipress
gesture. This check is still needed for widgets which have this style
property set (e.g. menubars and toolbars) can maximize the window on
double click -- but those widgets which have it set to FALSE shouldn't
maximize the window.
Use G_FILE_ATTRIBUTE_FILESYSTEM_REMOTE to detect remote filesystems
instead of hardcoded list of filesystem types.
Bump required GLib version accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=767965
...or warning style class applied.
This particular style bit wasn't converted to the saner 3.20 way
so `entry:selected` used in place of `entry selection`.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=768025
we used to style infobars by using the .info, .question, .warning
and .error selectors directly, which used to be ok when we had just
styleclasses all over the place, now it needs to be more specific
or it interferes with everything with those styleclasses applied
like entries.
The header bar currently ignores the expand property on its
children. This commit changes the code to honor that property.
It divvies up any free space and distributes it equally to packed
children (with any left over space given out a pixel at a time
on a first come, first serve basis).
This commit also adds support for the title widget to be made
expandable.
It accomplishes this by using up the padding the title widget
is centered with.
https://bugzilla.gnome.org/show_bug.cgi?id=724332
In order to support the expand property on children, we're
going to need to look at the size of the packed children
on each side of the title widget, up front, before allocating
them (to compute how much extra allocation each expanded child
gets).
This commit lays the groundwork for that analysis by splitting
the size calculation of each side of the header bar outside
of the loop that allocates each child of the header bar.
https://bugzilla.gnome.org/show_bug.cgi?id=724332
With a headerbar, the widget in the center may be a label, constructed
internally, or a custom widget, constructed externally. The size
allocation code needs to handle either case the same way for the most
part. There's more than one place in the code that checks which of
the two widgets to use and does some operation on the selected one.
This commit simplifies the code by checking up front which one is the
center (title) widget and storing that in a temporary variable,
This allows reducing duplicated logic later on in the function.
https://bugzilla.gnome.org/show_bug.cgi?id=724332
There's some extraneous MIN() calls that have predetermined answers.
This commit drops them and then simplifies a few redudant checks into
one MIN call.
https://bugzilla.gnome.org/show_bug.cgi?id=724332
The size allocation code maintains an array of two elements,
to track the allocation of children packed into the two sides
of a header bar. Sometimes this array is indexed with 0 and 1,
and sometimes its indexed with GTK_PACK_START and GTK_PACK_END.
The latter happen to have the values 0 and 1, respectively, but
that's not really obvious.
For clarity, this commit changes the code to index those arrays
consistently, sticking to 0 and 1 across the board.
It's only possible to have a label or a custom title, not both.
The size allocate code confusingly treats them as independent.
That is confusing, because, as the code is written, it makes it
look like the space for the custom title isn't getting accounted
for.
This commit else-ifies some parts of the size allocate code for
clarity.
Firefox does a bunch of interesting things with GTK.
If the top-level GtkWindow does not have a "csd" style class associated,
Firefox will happily draw the contents of the container used to render
HTML and XUL directly on the top level's GdkWindow; on the other hand,
if a "csd" style class is found, the MozContainer will create a new
child window, and draw on it.
Then, Firefox will proceed to disable double buffering on both the
top-level window and the MozContainer (unless they are backed by the
same GdkWindow, in which case only the top-level will be
single-buffered) *and* it will add a GDK_EXPOSURE_MASK flag to the
MozContainer events for good measure (even if this is only needed for
GTK+ 2.x).
After landing the GdkDrawingContext API in GdkWindow, GTK enabled
automatic double buffering on all top-level windows backed by a native
surface, ad most users of single buffering rely on child widgets instead
of top-levels, and we'd still like to have the same double buffering
behaviour for all top-levels on all backends. Obviously, with Firefox
disabling double buffering on the top-level window, the change broke
their drawing mechanism.
Ideally, Firefox could be fixed to not disable double buffering on the
top-level window when MozContainer has a separate GdkWindow — i.e. the
CSD case — but since we did introduce a slight change of behaviour in
fringe users of the GTK+ API, let's keep backwards compatibility with
the old code for a little while longer, and create an intermediate Cairo
context unbound from the GdkDrawingContext, like we used to do until
GTK+ 3.20.
And ensure it's still visible before returning the keyboard focus to it.
Because of the extra ref, add a dispose handler that will ensure the
ref is lost (by popping down), although this should be already ensured
through other paths (eg. when the popup widget loses visibility).
This fixes a possible crash in dispose paths, where we might be restoring
focus on an already destroyed widget, and at a time where, if the toplevel
is being itself disposed, no new focus should be set.
https://bugzilla.gnome.org/show_bug.cgi?id=767849
If there are widget margins set, the whole popover will be displaced.
However the calculation of the tail position doesn't have this into
account, ending up with the tail being detached from the popover if
the margin grew too big.
We should not render the arrows invariably next to the GdkWindow edge,
but optionally displaced inside it depending on the widget margins.
Fixes the gtk3-demo "Popovers" demo case, whose GtkEntry popovers set
widget margins for some reason.
https://bugzilla.gnome.org/show_bug.cgi?id=767851
do_sort will crash if sort_func is not defined. Instead of adding a check
there in the hot path, just check for sort_func before invalidating the
sort of the underlying GSequence.
I noticed that some of the gestures did not show up in the
search results in the builder example in gtk3-demo, because
they share the same title and don't have an accelerator to
disambiguate. Include the shortcut type to handle this case.
Set a max-content-width on some of the scrolled windows to
keep things looking mostly the same, now that GtkScrolledWindow
passes along the natural size of its child.
The cellrenderer signals might be taking the grab somewhere else, at which
point it's dubious we should attempt to take the keyboard focus into the
treeview.
This concretely breaks popovers triggered from cellrenderer signals on
button press, because the treeview will attempt to grab focus
inconditionally then.
https://bugzilla.gnome.org/show_bug.cgi?id=767468
It's almost certainly a programmer error if an action isn't
activatable because its target and parameter type don't match.
This commit changes the existing g_message to a g_warning.
https://bugzilla.gnome.org/show_bug.cgi?id=767705
Previously a style cascade's parent could not have a parent itself. That
represented the two levels at which you could add a style provider: at
the screen level, with gtk_style_context_add_provider_for_screen(), and
at the style context level, with gtk_style_context_add_provider().
This commit changes no functionality, but this change will be necessary
for adding style providers in the future that apply to a subtree of the
widget tree. It relaxes the requirement that a style cascade's parent
must not have a parent, since in the future a style context may be
affected by any number of parent widgets' style contexts.
https://bugzilla.gnome.org/show_bug.cgi?id=751409
Debian stable currently ships with a 3.16 kernel, so
it doesn't have memfd available.
This commit adds shm_open fall back code for that case
(for now).
https://bugzilla.gnome.org/show_bug.cgi?id=766341
We currently use syscall() directly to invoke memfd_create,
since the function isn't available in libc headers yet.
The code, though, mishandles how errors are passed from syscall().
It assumes syscall returns the error code directly (but negative),
when in fact, syscall() uses errno.
Also, the code fails to retry on EINTR.
This commit moves the handling of memfd create to a helper function,
and changes the code to use errno and handle EINTR.
https://bugzilla.gnome.org/show_bug.cgi?id=766341
When disposing a GdkDrawingContext we should unset the association
between the instance and the Cairo context; this avoids stale pointers
in case a reference that has acquired on the Cairo context survives the
lifetime of the GdkDrawingContext.
This is a bit of fallout from 34feba1, now that we resolve
the has_indicators value earlier than realize, it becomes
possible to call gdk_window_move_resize() before realization.
Just added the appropriate checks.
Instead of associating the GdkWindow that created the GdkDrawingContext
we can directly bind the Cairo context to the GDK drawing context.
Cairo contexts created via gdk_cairo_create() go back to not having a
GdkWindow associated to them, like they did before we introduced the
gdk_window_begin_draw_frame() API.
https://bugzilla.gnome.org/show_bug.cgi?id=766675
Instead of giving out Cairo contexts, GdkWindow should provide a
"drawing context", which can then create Cairo contexts on demand; this
allows us to future proof the API for when we're going to use a
different rendering pipeline, like OpenGL.
https://bugzilla.gnome.org/show_bug.cgi?id=766675
Existing code drawing on a GDK window has to handle the direct drawing
and the buffered drawing by itself, by checking the window type and
whether or not the window is backed by a native windowing surface. After
that, the calling code has to create a Cairo context from the window and
keep an association between the context and the window itself.
This is completely unnecessary: GDK can determine whether or not it
should use a backing store to draw on a GdkWindow as well as create a
Cairo context, and keep track of it.
This allows to simplify the calling code, and enforce some of the
drawing behavior we want to guarantee to users.
https://bugzilla.gnome.org/show_bug.cgi?id=766675
The maximum content size does not increase the minimum request
but only ensures that both minimum and natural requests do not
exceed the maximum setting.
Widgets should support size requests before being realized in general,
otherwise this can cause flicker/resize at initial display time as
the toplevel window can make a request before realize/allocate.
This also makes the added testsuite/gtk/scrolledwindow.c test work again,
this was broken because we only ever calculate whether we are going
to use overlay scrollbars once the scrolled window is realized (and
the test case does not realize any window).
This patch does a couple of things:
o Removes the obscure 'extra_width' and 'extra_height' variables
making the request code exceedingly difficult to read
o Fixes the max-content-size properties introduced in bug 742281
so that they do not grow the minimum request.
o Cleanup of request code in general:
- min/max content sizes are clamped around the child request as needed
- scrollbar requests are only added in one place, after child request
sizes are calculated and without the extra_width/height thing.
Commit 023f406c96 has a typo that results
in this error:
../../../testsuite/gtk/notify.c: In function 'test_type':
../../../testsuite/gtk/notify.c:679:54: error: expected expression
before ')' token
(g_str_equal (pspec->name, "max-content-width") ||)
^
A wl_buffer has a max size of 4096 bytes, of which 8 are needed for the
header and another 4 for the string argument length (in this case), so
make sure the we only save the first 4083 bytes that are still valid
UTF8.
https://bugzilla.gnome.org/show_bug.cgi?id=767241
The allowed values for the max-content- properties depend
on the value of the min-content- properties, in a way that
our simple test is not prepared to deal with. Just skip
them for now.
xdg-shell allows desktop environments to extend the list of states
within a given range.
Use this possibility to add a new state for tiled so that gtk+ can
benefit from this.
https://bugzilla.gnome.org/show_bug.cgi?id=766860
If gtk_scrolled_window_add() has added a GtkViewport,
gtk_container_remove (GTK_CONTAINER (scrolled_window), child_widget);
or
gtk_container_remove(GTK_CONTAINER(scrolled_window),
gtk_bin_get_child(GTK_BIN(scrolled_window)));
removes both the added child widget and the viewport.
https://bugzilla.gnome.org/show_bug.cgi?id=710471
This removes leftover code from when classes where added to the style
context.
Now that they get added directly to css nodes, the classes can exist
without a style context.
https://bugzilla.gnome.org/show_bug.cgi?id=767312
With the FTS5 query syntax, when using quotes to delimit the search phrase
the '*' token must happen after the quote, or will otherwise be considered
a character to match, go through the tokenizer, and end up ignored in
result.
This reverts commit 0943c9f6b2.
The commit caused unexpected breakage in gtk3-widget-factory,
and also broke the just-added max-content-size properties.
Needed to adjust this again after applying commit 4e5ecb7
for bug 742281. Now that we also have max content size properties,
pushed the addition of possible scrollbar sizes to after the
clause which clamps the child request size into min/max content
sizes.
Commit a01fe14 changed the behaviour of popovers when the focus leaves
them to stop child popovers being hidden when the focus leaves their
parent. However they are now a bit too reluctant to hide - if the
focus passes to an unrelated popover the first popover is not
hidden. Also if the focus passes to another widget that does not
perform a gtk grab then the popover isn't hidden until the user
presses a non-movement key or clicks outside the popover.
The solution is to go back to checking if the focused widget is a
descendant of the popover, but to include popovers and their related
widgets in the ancestry chain.
https://bugzilla.gnome.org/show_bug.cgi?id=765595
This patch causes the scrolled window default behavior to change in
such a way that the natural size request of the child is unconditionally
reported, which probably should have been the case since day 1.
This should not cause significant fallout since a scrolled window is
normally used to expand/fill, eating up remaining space for scrollable
content - it will however cause the scrolled window to compete for
additional space with siblings, proportionally to the size of the
scrolled window's content.
gtk_tree_view_get_path_at_pos() mistakenly identifies the first
pixel of all but the first column in a tree view as belonging to
the previous column.
https://bugzilla.gnome.org/show_bug.cgi?id=708148
The GtkScrolledWindow has support to set the minimum content size (both
width and height) which controls the minimum space allocated, but does
not exposes any way to control the maximum size the content can grow.
After the introduction of GtkPopover, which always uses the minimum
size of it's children widgets, the lack of max-content-width and -height
properties became a concrete use case.
This patch introduces the GtkScrolledWindow::max-content-width and
-height properties. The properties will alter the minimum size of
the scrolled window, making it grow up to the set value. They also
respect the previously set ::min-content-width and -height.
https://bugzilla.gnome.org/show_bug.cgi?id=742281
Similar in spirit to
gtk_style_context_get (ctx, state, "font", ...)
but avoids the need for a style context.
This will be used to for css-styled text rendering
from css subnodes.
This is _gtk_style_context_get_pango_attributes, decoupled
from the GtkStyleContext. This will be used to drive css-styled
text rendering from css subnodes of widgets, e.g. for the value
in GtkScale.
The Wayland protocol does not share XI2's wealth of information
about individual devices, but it does provide discriminating
information about the source for scroll events. Pass this on to
the application by creating separate slave devices for these,
and setting them as source device on the scroll events.
These devices can be discriminated by their input-source property:
wheel - GDK_SOURCE_MOUSE
finger - GDK_SOURCE_TOUCHPAD
continuous - GDK_SOURCE_TRACKPOINT
https://bugzilla.gnome.org/show_bug.cgi?id=767093
fix up
GtkHeadeBar checks the window type hint to determine if the regular
buttons such as menu, maximize or iconify should be visible in the
header bar.
However, an application may very well use a "normal" toplevel window and
set it transient and modal afterwards. In such a case, the iconify
button would remain visible, and the user can hide the window, but being
a modal, the parent window would remain insensitive.
Check for the window type, modality and transient relationship to decide
whether or not the regular toplevel buttons should be visible in the
header bar.
https://bugzilla.gnome.org/show_bug.cgi?id=767052
When we emit ::draw, the widget should not have alloc_needed set
anymore. If this happens, it indicates a broken situation. Add a
warning to help tracking down why this might occur.
See https://bugzilla.gnome.org/show_bug.cgi?id=765410
When filechooer is re-used (instead of being created and destroyed
every time it's needed), it might happen that the directory the
application wishes to initially show is the same directory that
was shown last time the filechooser was used. In that case, make sure
filechooser knows that it does not need to do its default "select $pwd
or $home" routine.
https://bugzilla.gnome.org/show_bug.cgi?id=766122
adds a paragraph to gtk_text_view_get_pixels_below_lines(),
describing how it can be used together with
gtk_text_view_get_pixels_above_lines() to get the total
amount of line spacing between two paragraphs.
https://bugzilla.gnome.org/show_bug.cgi?id=747206
Calling gdk_gl_context_realize() should always result in a valid result,
so we need to provide a default implementation, to avoid a call to a
NULL function pointer.
If the popover's relative-to widget is unparented/reparented, we end
up unparenting/reparenting the popover as well. In that case, at the
moment of reparenting, the widget might have been visible (and is
thus mapped again), but priv->window hasn't been set yet.
We must first set priv->window, and then call gtk_window_add_popover(),
that way gtk_popover_map() has its prerequisites straight.
https://bugzilla.gnome.org/show_bug.cgi?id=766323
gtk_widget_set_parent() will map the widget if the parent is mapped
and the widget is both visible and child-visible. As we currently
only set the child visibility after adding the child, we immediately
map all children that are added to a mapped stack, even when they
are not actually shown. Avoid this by setting the child visibility
before adding the child, so widgets are only mapped when shown.
https://bugzilla.gnome.org/show_bug.cgi?id=766737
Use g_drive_is_removable for external drives detection. Current heuristic
fails in some cases (e.g. when removable drive is attached before login),
see Bug 765457.
Bump GLib version accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=765924
When starting a rubberband selection from an empty area, we could run
into crashes if the selection moves over the rows and then back out
to unpopulated area. Handle this case without crashing.
https://bugzilla.gnome.org/show_bug.cgi?id=766336
Use .marks-before/after to indicate the presence of marks.
As Lapo points out, compatibility with the previous names
is not really that important, since everything else changed
around it.
https://bugzilla.gnome.org/show_bug.cgi?id=766440
Warn about the situation when we've found a resource or file path,
but gdk-pixbuf fails to give us a pixbuf. This generally means that
either pixbuf loaders are not found or the shared-mime database
is missing.
Given that Wayland has no global coordinate, the only way for gdk to
retrieve the monitor a window last entered is to retrieve it from the
GdkWaylandWindow itself.
Implement the backend specific get_monitor_at_window() to return the
monitor that was last entered by the window.
https://bugzilla.gnome.org/show_bug.cgi?id=766566
In Wayland, surfaces get an enter/leave notification each time they
enter or leave an output.
Add an API to GdkWaylandWindow to retrieve the output the window has
last entered.
https://bugzilla.gnome.org/show_bug.cgi?id=766566
Some backends (namely Wayland) do not support global coordinates so
using the window position to determine the monitor will always fail on
such backends.
In such cases, the backend itself might be better suited to identify
the monitor a given window resides on.
Add a vfunc get_monitor_at_window() to the display class so that we can
use the backend to retrieve the monitor, if the backend implements it.
https://bugzilla.gnome.org/show_bug.cgi?id=766566
It turns out that it is too hard (and in some cases, impossible)
to get this information from node positioning, so bring back the
.scale-has-marks-above/below style classes on the main node.
This should allow us to fix the 'pointy sliders'.
https://bugzilla.gnome.org/show_bug.cgi?id=766440
The GdkDragContext should only listen to GDK_GRAB_BROKEN events sent to
its own pointer device. It turns out that the passive key grabs mistake
GDK into sending a GdkEventGrabBroken on the master keyboard, which the
DnD machinery mistakes as a signal to cancel the operation.
https://bugzilla.gnome.org/show_bug.cgi?id=766442
Only generate crossing events on wl_touch.down for the virtual master
device used for touch events, and only whenever this virtual device
actually moves across surfaces. This behavior resembles better what is
expected in X11, where the pointer is warped to the touch position
on XITouchBegin.
This avoids the double emission of leave events when the pointer
emulating touch is lifted, that crossing event will be instead
generated when/if the focus surface changes.
https://bugzilla.gnome.org/show_bug.cgi?id=766314
This is required for proper integration with any other library/application that
may perform wayland API calls and poll() the wayland fd from multiple threads.
Using wl_display_dispatch{_queue}() is thread-safe if not mixed with custom
poll() usage, which GSource/GMainContext does.
Essentially, the problem is that multiple threads polling and reading
the same fd is extremely racy. Use the wayland provided API for allowing
concurrent access to the wayland display fd.
See the wayland man pages for wl_display_prepare_read(),
wl_display_cancel_read() and wl_display_read_events() for more details.
https://bugzilla.gnome.org/show_bug.cgi?id=763852
GtkScrolledWindow leans towards using the minimum size of its child
widget, unless the scrollbar policy is GTK_POLICY_NEVER. This is
probably fine for most GtkScrollable implementations out there.
Especially when using GTK_SCROLL_MINIMUM, which is the default for all
implementations inside gtk+.
However, this is not good for GTK_SCROLL_NATURAL children. eg.,
VteTerminal's minimum size is 1x1 and natural size is the number of
visible rows and columns requested by the user. We really want to use
the natural size unless the user has resized the window to change that.
https://bugzilla.gnome.org/show_bug.cgi?id=766569
This code tries to add the minimum content size, if one is set, to the
GtkScrolledWindow's size requisition. This is obvious from the check
for non-negative values of min-content-height and min-content-width.
Using MAX needlessly makes the code harder to read by implying that
there is more to it when there actually isn't.
Fall out from 0d9ebb501dhttps://bugzilla.gnome.org/show_bug.cgi?id=766569
When we are beginning to calculate the height, if the vscrollbar_policy
is not GTK_POLICY_NEVER, and there is no min-content-height, then we
need some small non-zero value to get started. The idea is to always
ask for at least enough to fit the horizontal scrollbar.
Simply put, this should be the mirror image of the corresponding width
calculation code.
Those who got used to the buggy behaviour might notice that their
GtkScrolledWindows are not as tall as they used to be.
Fall out from 55196a705fhttps://bugzilla.gnome.org/show_bug.cgi?id=766530
Sometimes on wayland we're seeing a frame draw before the first tick
callback, where the window position has not yet been updated.
With this change, the window is properly positioned as soon as
gtk_stack_start_transition returns.
https://bugzilla.gnome.org/show_bug.cgi?id=766405
Fix testsuite/a11y/about.ui GtkAboutDialog :
"CRITICAL **: atk_hyperlink_get_start_index: assertion 'ATK_IS_HYPERLINK (link)' failed"
That is set widget->priv->accessible as soon as accessible object is generated.
When accessible object is created accessible->priv->widget is set,
if widget->priv->accessible is not , then _gtk_label_accessible_update_links
exits early, thus without creating the links on the accessible side.
(This as it checks for the widget to have the accessible set before proceeding).
https://bugzilla.gnome.org/show_bug.cgi?id=766458
GTK used to not emit GtkWidget::style-updated on widgets that weren't
realized. This sped up construction of complex widgetry in the early
days of GTK3 where we instantly invalidated on every change.
We don't do that anymore, so in theory (and in my limited testing with
widget-factory) this shouldn't be a prolem anymore.
What is a problem though is that postponing style-updated leads to 2
problems:
(1) Unrealized widgets will not emit style-updated which may cause them
to not properly update their state and return wrong values from
get_preferred_width/height() etc
(2) Emitting style-updated during realize can happen too late.
When a widget is not made child-visible by its parent (common
examples: notebook, paned) it will also not be realized when the
parent is initially shown. However, when they get realized later
(after a resize of the parent), they will emit style-updated (and
potentially queue a resize) during size-allocate.
https://bugzilla.gnome.org/show_bug.cgi?id=765700
Cancelling the gesture causes the last_event pointer to become
invalid. Make a copy of the event so we can keep using it
regardless of the gesture state.
At one point, the sidebar was using gtk_treeview_set_tooltip_column,
which expects tooltips to be markup. With the listbox-based sidebar,
we don't do that anymore. So don't escape the tooltip text.
https://bugzilla.gnome.org/show_bug.cgi?id=766175
We're measuring both the width of the minimal and the maximal value for
the value gadget, but only give the value the minimal width for its
current value, resultnig in an always left-aligned value.
Fix this by assigning the width of the value gadget to the value layout
and letting pango align the text inside the layout.
https://bugzilla.gnome.org/show_bug.cgi?id=766120
Menus are placed vertically by definition, it does not make much sense
to support horizontal axis for scrolling.
Use GDK_EVENT_STOP/GDK_EVENT_PROPAGATE instead of TRUE/FALSE and add a
default case to return GDK_EVENT_PROPAGATE for unhandled events.
https://bugzilla.gnome.org/show_bug.cgi?id=765939
On X11, we get both smooth and emulated scroll events, whereas other
backends such as wayland will give smooth events only with touchpad
scrolling.
Discard emulated scroll events so that we get consistent behaviours
between backends.
Allow for both horizontal and vertical smooth events for scrolling so
that horizontal scrolling still works without emulated scroll events as
well, again for consistency between gdk backends.
https://bugzilla.gnome.org/show_bug.cgi?id=765939
Some compilers we support, such as pre-2013 Visual Studio, does not support
for INIFINITY, log2() and exp2(), so check for exp2() and log2() during
configure, and use fallbacks for them and INIFINTY if they are not found.
https://bugzilla.gnome.org/show_bug.cgi?id=766207
Split out the part where we generate/update the caches for the GSchemas
and the icons, so that it is easier to ensure that things continue to
function correctly when we have GlibEtcInstallRoot != CopyDir.
Children tend to call back into the scrolled window while being removed
and that doesn't work too well if the scrolled window is destroyed
already as Christian Hergert found out.
Consolidate the .lib's that we need to link to for GDK and GTK+ into the
property sheets, and also link to setupapi.lib as that is needed by
the port to the new GdkMonitor API.
WINBOOL is MinGW-specific, so change it to BOOL, which is universally
available.
Also, Visua Studio is more picky on where __stdcall (WINAPI) is placed, so
fix that to be in-sync with what is done in the other sources.
This only used by luck before. We are changing a property from the
::notify handler for that property. Now that GtkRevealer is notifying
the property when it stops animations on unmap, we end up in a life
lock situation where we never make it out of the notify queue.
Fix this by not restarting the animation if the widget is unmapped.
Depending of float rounding during target calculation, the size of the
GtkRevealer can be set to zero will the animation is not finished.
If the GtkRevealer is in a GtkPaned, it will be hidden and so the animation
will be stopped before it is finished.
In this case, force the emission of the child-revealed signal to let
client code know the animation is finished.
https://bugzilla.gnome.org/show_bug.cgi?id=765973
This was another very frequent use of qdata. Since we typically
have only one or two display objects, storing the display-settings
association in a simple array is faster than using object data
or a hash table.
Use of g_signal_handlers_disconnect_by_func() needs to do more work than
necessary to find all the matching handlers. Instead, just hold on to the
signal identifier and remove it directly so we hit the fast path.
Not terribly ground breaking in terms of performance gains, but its done
enough to be worthwhile.
https://bugzilla.gnome.org/show_bug.cgi?id=766049
Christian Hergert reported seeing webkit crashes with recent
GTK+. The stacktrace points at the CSS machinery calling into
GtkSettings to get the font name, and then getting surprised
by a property notification that triggers style validation.
To avoid this, query the font name xsetting right away when
we get set a screen.
The active keyboard grab can be spared then. This way the passive
key grabs allow other key combinations (eg. alt-tab) that are not
mandatory to grab here.
This will almost certainly overwritten before the widget gets
to the screen, but while we are doing this, we might as well
use the same state that we initialize the widgets state to.
Instead of creating 2 pango layouts in every draw() and on in
_get_content_size (and calling into gettext twice in both cases), just
keep the layouts around and create them in only one place.
I was somehow under the misconception that we'd get GdkEventSettings
events for all the xsettings at startup. That is not in general true,
so we need to make sure that we check for the xsettings value before
we use them, or derived fields. Update all the private getters to
do so; and fix settings_update_font_values() to cope with font
descriptions that might miss the family or size.
I mistakenly assumed that gtk_settings_init was already doing
something to trigger a notify for all properties. It doesn't,
so we have to ensure that settings_update_font_values() is
called at least once.
https://bugzilla.gnome.org/show_bug.cgi?id=765966
The wayland specification for discrete step information for scroll and
other axes reads:
| The discrete value carries the directional information. e.g. a
| value of -2 is two steps towards the negative direction of this axis.
mutter sets a value of 1 for SCROLL_DOWN events and -1 for SCROLL_UP
events.
gdkdevice Wayland backend does the opposite, it translates a positive
discrete value as SCROLL_UP and a negative value as SCROLL_DOWN, which
ends up inverting the scrolling direction.
Fix the logic in gdkdevice Wayland to use a positive value as
SCROLL_DOWN and a negative value as SCROLL_UP so that it matches mutter
and weston logic.
https://bugzilla.gnome.org/show_bug.cgi?id=765907
The fallback code for rendering builtin checks, radios
and expanders was using border parameters. With the generic
gadget borders using the same parameters, this was giving
double borders.
Before commit 6c1bee2377 we were setting an attribute of GtkNotebook
to track the pressed button if the pressed button happened on the
tab itself.
Later in the motion handling code we were checking whether the private
pressed button attribute was set or not in order to handle a tab dnd
or not.
In commit 6c1bee2377 the code changed and set the pressed button
variable unconditionally, which means, a motion event from within the
tab content triggered a tab reordering.
This happened only if the children hierarchy have a widget that bubbles
up both button press event, which sets the private pressed button
attribute; and motion events, which started the tab dnd checking the
private pressed button attribute.
A widget that experienced the regression was GtkListBox.
In order to fix it, set the button pressed variable only when it press
the tab itself, not the content.
https://bugzilla.gnome.org/show_bug.cgi?id=764395
Specifically, this URI is not supported on Windows, but GFile will
do its "best" and turn it into GLocalFile("$pwd/network"), with
spectacularly bad results.
https://bugzilla.gnome.org/show_bug.cgi?id=765858
When checking for cairo_win32_surface_create_with_format in -lcairo,
temporarily put CAIRO_LIBS into LIBS so that AC_CHECK_LIB() can
find it in weird places like /usr/local/lib, where gcc would not look
on its own.
https://bugzilla.gnome.org/show_bug.cgi?id=765793
We only keep one align flag per child, so it seems odd to
keep separate h/v expand flags. Just keep one expand flag
and interpret it according to orientation. Allow setting
the expand flag for child widgets too, though, so we can
make widget expand without interfering with the recursive
widget expand flag.
Update all callers.
Use the new possibility of expanding child widgets to make
the label of check and radio buttons expand. This fixes
unexpected behavior of these widgets in RTL in some places.
https://bugzilla.gnome.org/show_bug.cgi?id=765742
In RTL, we want to interpret GTK_ALIGN_START and _END
in the opposite way. Since we don't give gadgets a text
direction, just allow setting an align_reverse flag
to the box gadget.
If the monitor vfuncs are not implemented in a display class,
fall back to providing a single monitor object representing
the entire screen. This is not meant to be 'good enough', it
is just to provide some implementation until all backends
implement the monitor vfuncs. When that is the case, the
fallback should be removed.
If there was a piece of text in the cell, then when the edit
entry is shown for that cell, it should have a piece of text
in it roughly at the same location.
Therefore, when child widget is enlarged (child preferred
size exceeds cell size), extra width should be added by
extending either left or right edge depending on text direction.
If after that the child sticks outside of the treeivew visible region,
try to push it back inside (breaking its alignment with the
cell), again, giving preference (i.e. adjusting it last)
to either left or right edge depending on text direction.
https://bugzilla.gnome.org/show_bug.cgi?id=765471
NoSymbol is not a valid GDK symbol (it only has the concept of
VoidSymbol, for some reason, which is neither the same thing nor
produced by any sane keymap). Passing NoSymbol events through to GTK+
apps is unlikely to produce anything useful.
In particular, this meant VTE would scroll to the end of the buffer when
pressing Fn (required for Page Up/Down on Macs), as it was receiving a
keypress that wasn't a modifeir. This does not happen on X11, as the
KEY_FN keycode is above 255, so does not get sent to clients.
https://bugzilla.gnome.org/show_bug.cgi?id=764825
We don't care about the specific (possibly client-side) window that
requested the focus here, only the toplevel. Fixes mistakenly sent
focus events when the grab happens inside the current focus window.
https://bugzilla.gnome.org/show_bug.cgi?id=762756
This avoids the g_source_remove(), g_source_destroy(),
g_timer_source_new(), and g_source_set_name_by_id() in the common case.
Instead, we reuse our previous source and update the ready time to our
new deadline. We lose the coalescing with g_timeout_add_seconds(), but
that is not going to help in the common case anyway (unless you have
three hands and can scroll multiple pixelcached backed widgets at once).
https://bugzilla.gnome.org/show_bug.cgi?id=765640
In non-composited environments, we were ending up with all-black
drag icons, because nothing was drawing the background of our new
toplevel. Fix this by drawing background when we are not composited.
We don't do this when composited, since we want to allow transparent
icons.
GtkPlacesView currently provides no example of
server addresses, which may confuse users.
To fix that, add a helper popover with some
guidance on server addresses.
https://bugzilla.gnome.org/show_bug.cgi?id=756570
The documentation clearly says that the widget is not destroyed,
but we were in fact failing to keep it alive, since it was still
a child or the icon_window when we destroy that. Fix this by
reparenting the icon_widget out before. Also, deal with the
possibility that the application might destroy the widget
halfway through, for whatever reason.
I added a new test function, but didn't actually use it.
No wonder I couldn't reproduce the lifecycle issues with
drag widgets that firefox is experiencing.
Always associate a drag context with a GdkDisplay and use that when
getting a cursor for a given action.
If we don't do this, dragging on a window that doesn't use the default
display will make us use cursors from the wrong display.
https://bugzilla.gnome.org/show_bug.cgi?id=765565
Typically, there won't be any references on old frame timings except for
the most recent timing. So instead of discarding these and re-entering
gslice twice, just steal the old frame timing and reuse it.
https://bugzilla.gnome.org/show_bug.cgi?id=765592
Don't track all orphaned dialogs globally, as mixing them up with each
other would in most cases trigger errors when we try to pass bogus
values to Wayland requests.
https://bugzilla.gnome.org/show_bug.cgi?id=765474
The naming of pointers to GdkWaylandDisplay's were inconsistent.
Running the following commands in gtk+/gdk/wayland illustrate the
inconsistency:
$ grep -r '\<display_wayland\>' *.[ch] | wc -l
195
$ grep -r '\<wayland_display\>' *.[ch] | wc -l
81
This patch renames all occurrences of "wayland_display" to
"display_wayland". This is also consistent with naming in the X11
backend. A couple of whitespace changes were done as well in places
where the rename was already done, that added line breaks to long lines
that stood out.
https://bugzilla.gnome.org/show_bug.cgi?id=765474
Generate .pc files for the package, so that it would be easier for
building introspection for packages that depend on GTK+. Also split
PythonPath into PythonPath and PythonPathX64 to facilitate the build of
introspection files, which need to have Python that is built with the
same ac=rchitecture where GTK+ is built.
Clean up the formatting and spacing a bit.
When synthesizing keyboard repeat, we can potentially drift further from
the mark depending on the timing of the frame callback and how long it
took to deliver the event.
This patch attempts to reduce this by tracking from a stable epoch the
time of our next keyboard repeat.
https://bugzilla.gnome.org/show_bug.cgi?id=765567
There are various functions to access links based on their index for
a11y. We can spare quite a few lines of code by just using
g_list_nth_data instead of iterating over the list ourselves.
https://bugzilla.gnome.org/show_bug.cgi?id=765496
We perform lots of gadget allocations that require allocating a
GtkBuiltinIcon. One notable example is the scrollbar for a scrolled
window.
In the process of doing this, we often calculate baseline information that
isn't necessary. With how much this code path gets exercised, its worth
catching the result for the common case, which is that the font-description
has not changed and we are using the default language the application
was started with.
This simply caches the previous result and verifies that we can reuse it
with pango_font_description_hash() and a simple language check.
Numbers below are scrolling through a textview with GDK_KEY_Down.
Before:
SELF CUMULATIVE FUNCTION
[ 0.08%] [ 9.26%] gtk_builtin_icon_get_preferred_size
[ 0.01%] [ 8.82%] pango_context_get_metrics
[ 0.02%] [ 0.16%] gtk_widget_get_pango_context
[ 0.06%] [ 0.06%] pango_context_get_language
[ 0.01%] [ 0.02%] g_type_check_instance_cast
[ 0.02%] [ 0.02%] strlen
[ 0.02%] [ 0.02%] pango_context_get_font_description
[ 0.02%] [ 0.02%] g_list_foreach
[ 0.01%] [ 0.01%] gtk_css_style_get_value
[ 0.01%] [ 0.01%] itemize_with_font
[ 0.01%] [ 0.01%] pango_context_get_type
[ 0.01%] [ 0.01%] get_base_metrics
[ 0.00%] [ 0.01%] pango_font_metrics_unref
[ 0.01%] [ 0.01%] g_list_free
[ 0.01%] [ 0.01%] gtk_builtin_icon_get_type
After:
SELF CUMULATIVE FUNCTION
[ 0.08%] [ 0.18%] gtk_builtin_icon_get_preferred_size
[ 0.02%] [ 0.02%] pango_font_description_hash
[ 0.00%] [ 0.02%] gtk_widget_get_pango_context
[ 0.00%] [ 0.02%] g_object_get_qdata
[ 0.00%] [ 0.02%] g_datalist_id_get_data
[ 0.02%] [ 0.02%] gtk_builtin_icon_get_type
[ 0.01%] [ 0.01%] pango_context_get_font_description
[ 0.00%] [ 0.01%] - - kernel - -
[ 0.01%] [ 0.01%] pango_context_get_language
[ 0.00%] [ 0.01%] gtk_css_style_get_value
[ 0.00%] [ 0.01%] gtk_css_gadget_get_style
https://bugzilla.gnome.org/show_bug.cgi?id=765486
This allows us to decide when the R and B color channels should be
flipped with a much better granularity.
For instance, when using GLX_EXT_texture_from_pixmap to create a GL
texture from a surface we don't need to swap the R and B channels, as
the internal representation of the texture data will already have the
appropriate colors.
We also don't need to flip color channels when blitting from a texture.
Cairo surfaces are in BGRA format, but we upload them as RGBA buffers on
GLES; this means that the R and B channels are flipped in the texture
data.
Instead of doing a costly channel flip before putting them on the GPU,
we can flip the values inside the GLSL shader we use specifically for
GLES.
We cannot use GL_BGRA and GL_UNSIGNED_INT_8_8_8_8_REV when reading back
from the frame buffer in the software fallback path, as they do not
exist on OpenGL ES.
This will make the slow path a bit slower, because of the implicit
format conversion.
When uploading a Cairo image surface to a GL texture we cannot use
GL_BGRA and GL_UNSIGNED_INT_8_8_8_8_REV on OpenGL ES, as they do not
exist in the core spec.
On some platforms we can ask the GL context machinery to create a GLES
context, instead of a GL one.
In order to ask for a GLES context at GdkGLContext realization time, we
use a bit field like we do for forward compatible, or debug contexts.
The 'use-es' bit also changes the way we select a default version,
because OpenGL and OpenGLES versions differ.
https://bugzilla.gnome.org/show_bug.cgi?id=743746
When decelerating the kinetic scroll, we can get into a position where it
looks like we are stuttering. This happens because the amount we move is
so little that it takes multiple frames to make forward progress by one
pixel.
This prevents that by detecting when we have reached the slow stutter of
the deceleration and simply stops the deceleration phase immediately.
https://bugzilla.gnome.org/show_bug.cgi?id=765493
This has several benefits:
- Less code in GtkApplication. The accels handling is something
self-contained, and GtkApplication now delegates the work.
- For the accels functions, there is now a distinction between static
functions and functions in the gtkapplicationaccelsprivate.h header,
which makes the code easier to understand, because we have a good
overview just by reading the header.
- The struct _GtkApplicationPrivate is now easier to find instead of
being in the middle of the file.
https://bugzilla.gnome.org/show_bug.cgi?id=764879
These will become the functions present in the
gtkapplicationaccelsprivate.h header.
The gtk_application_accels functions deal with detailed_action_name's
instead of action_and_target's. action_and_target is an implementation
detail of Accels.
The added function prototype is temporary, it'll be removed in a later
commit.
https://bugzilla.gnome.org/show_bug.cgi?id=764879
When the current cursor_row is taller than the page_size we get from the
GtkAdjustment, the previous code would not actually cause any scrolling,
so make sure we just take the row after or before the cursor_row in that
case.
https://bugzilla.gnome.org/show_bug.cgi?id=765261
Windows save in hardware_keycode an information which is not so low
level and some application require the hardware scancode.
As Windows provides this information save it in GdkEventPrivate
and provide a function to get this information.
For no Windows system the function return the hardware_keycode instead.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=765259
These runtime checks were being performed whether or not we were in a
debug build. Using GTK_DEBUG_CHECK() will compile out of production
builds, as it will result in something like:
if (G_UNLIKELY(0))
which the optimizer can prune.
https://bugzilla.gnome.org/show_bug.cgi?id=765284
This first adds a common autotools module that can be included by
the Makefile.am's to generate the file lists and the g-ir-scanner/
g-ir-compiler command lines to build the introspection files.
The autotools files for gdk/ and gtk/ are then updated to generate
the full file lists needed to build the introspection files, with
the full command lines for g-ir-scanner and g-ir-compiler as NMake
Makefile modules that can be used to build the introspection files
for Visual Studio builds.
https://bugzilla.gnome.org/show_bug.cgi?id=765195
These were showing up higher in Sysprof profiles.
The simple fix is to avoid the emit_by_name() and let the interface emit
the signals directly. No function preconditions are provided since these
are internal API.
Setting the font: shorthand to something like smaller is not
in line with the css spec. Just set the font-size: property
for this.
Also fix the other font: shorthand to specify size and family
according to the css spec.
If we get gdk_wayland_seat_flush_frame_event() with no previous event to be
flushed, we fallback into the scroll event checks. However, there's no check
performed there as to whether it really scrolled, so it'd always send a smooth
scroll event with 0/0 deltas in this case.
This should be mostly harmless, but still, we should only end up emitting scroll
events if those really happened.
The frame event is also meant to compress wl_pointer.leave events, at this
point the focus surface will be definitely NULL. In the end, wl_pointer.frame
should flush the last composed event despite the pointer focus.
https://bugzilla.gnome.org/show_bug.cgi?id=765065
We must emit the cancel event with the same semantics, and towards the GdkWindow
that is currently under the touchpoint, so make proxy_button_event() deal with
GDK_TOUCH_CANCEL.
Fixes the GDK_TOUCH_CANCEL event being emitted only on the toplevel, which is
usually non-sufficient.
Add a way to associate a detailed action name with a shortcut.
If the action name is set, update the accelerator whenever
accels change on the window that the shortcuts window is
associated with.
https://bugzilla.gnome.org/show_bug.cgi?id=764975
https://bugzilla.gnome.org/show_bug.cgi?id=765134 shows
a stacktrace where we end up with arrow_gadget being NULL
despite the conditions for its presence being satisfied.
This commit makes sure we call update_arrow_gadget() whenever
any of the conditions changes. This should fix the reported
crash.
The previous patches didn't mark some strings as to be translated, and
tried to translate strings with a variable part already inside the
string, which isn't going to work.
Mark the strings as translatable with context, and also make sure to
translate static strings when getting them out of their structure.
https://bugzilla.gnome.org/show_bug.cgi?id=764585
broken from my previous commit about rounded corners, dialogs
doesn't use the "window" node, but the "dialog" node, so use the
.background styleclass in the selectors which is more generic.
Since Wayland is using libxkbcommon, it inherits X unfortunate
real/virtual modifier distinction, so we have to do the same
gymnastics we do for X to map between the two.
This should fix matching of accelerators using virtual modifiers
(modulo gnome-shell bugs regarding the handling of Super).
https://bugzilla.gnome.org/show_bug.cgi?id=764424
1) g_print() can be redirected
2) g_print() does some extra processing, such as character set conversion.
Specifically, on W32 it will detect system codepage via GetACP(),
and will convert UTF-8 output into that codepage, even though
the output should stay unchanged (whether gtk-builder-tool interprets
strings from ui files as UTF-8 is a separate matter).
https://bugzilla.gnome.org/show_bug.cgi?id=765118
MoveWindow should not be used over the pre-existing move/resize
functions, which already correctly position a window with respect
to its parent, while also taking into account the size of window
decorations.
https://bugzilla.gnome.org/show_bug.cgi?id=765100
When clearing the icon helper, we need to invalidate it. Otherwise the
previous icon keeps lingering along.
This is not relevant inside gtkiconhelper.c where other code causes the
invalidation, but happens when external code calls
_gtk_icon_helper_clear().
https://bugzilla.gnome.org/show_bug.cgi?id=765066
Fixes a couple bugs...
- Pixel font sizes in css would render as point sizes.
- For em font sizes, where the parent size was set and not default, we would
incorrectly convert a pixel value from points to pixels.
We'll always grab the default font size in pixels so we don't keep confusing
things.
Worth noting that gtk css font-size will still behave differently than the
web. Pango interprets font-size differently.
gdk_window_reparent() already changes children list for old and new parent.
Doing so twice results in a circular reference in the list, which can hang
the application later, for example in gtk_window_show().
https://bugzilla.gnome.org/show_bug.cgi?id=764845
This makes usage of _gdk_display again when creating a window.
This is needed because there is a window created when the display
is being initialized, so it becomes a chicken and egg problem.
For now we roll back this to fix the wintab crash but we might
want to fix this again in the future by improving the wintab
initialization.
https://bugzilla.gnome.org/show_bug.cgi?id=764664
The zoom/rotate change for quartz does not build on 10.7. This change
adds zoom/rotate support in quartz only for 10.8 and following. The
problems is described here:
https://bugzilla.gnome.org/show_bug.cgi?id=760276 and here
https://trac.macports.org/ticket/51052
NSEventPhaseMayBegin was only introduced in 10.8 although documentation
says it is introduced in 10.7. Tests on 10.7 indicate that the phase
property for the Magnify event is not supported at all on 10.7
Because of our port of css animation and css transition to
progress tracker, we should not think of animated styles as
immutable objects that can map any timestamp to css values.
Rather, timestamps can correspond to different values depending
on the value of GTK_SLOWDOWN over the course of the animation.
To keep animated styles and style animations totally immutable,
we will not share styleanimations between animatedstyles, and
make a new copy of a styleanimation for each timestamp.
Not the ideal solution for this problem, but in practice leads to
much better performance on lower end hardware.
Stack does a double draw on the first frame of its animation, of
both the old contents (into a cairo surface) and the new contents.
Homogeneous stacks only need to reallocate contents on the first
frame.
On lower powered hardware where our frames will be a good deal
slower than the refresh rate anyway, we can assure a smother
experience by waiting a frame to start tweening where frame duration
will be more consistent.
glade-previewer places a gtkwindow inside another toplevel gtkwindow,
updating the shadow width for the client induces a busy loop where the
parent will grow continuously until it crashes gnome-shell/mutter.
To avoid the loop, do not update the shadow width if not dealing with a
toplevel window.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=761651
On wayland, such axes are per-tool, we must update device capabilities
on the fly as new tools enter proximity, first the slave device so
it matches the current tool, and then the master device so it looks
the same than the current slave device.
Only the management of tablets and tools is added so far. No tablet events
are yet interpreted.
As it's been the tradition in GTK+, erasers are split into their own device,
whereas the rest of the tools are meant to be routed through the
GDK_SOURCE_PEN device. Both pen/eraser devices are slaves to a master
pointer device, separate to wl_pointer's. This is so each tablet can
maintain its own cursor/positioning accounting.
Signed-off-by: Stephen Chandler Paul <thatslyude@gmail.com>
This will enable multiple "pointers" to have separate data here.
Will come out useful when adding support for tablets, as they
will have a separate cursor for all purposes.
On wayland we get separate master/slaves for each tablet, we will
need to receive crossing events for each master pointer if there's
more than one around.
Axis labels are very X specific, and are not really possible to port to other
backends such as Wayland. As such, it makes more sense to use GdkAxisUse and
GdkAxisUseFlag in order to determine the axis capabilities of a device and draw
their axes.
Signed-off-by: Stephen Chandler Paul <thatslyude@gmail.com>
Because there are multiple different types of styluses that can be used with
tablets, we have to have some sort of identifier for them attached to the
GdkDeviceTool, especially since knowing the actual tool type for a GdkDeviceTool
is necessary for matching up a GdkDeviceTool with it's appropriate
GdkInputSource in Wayland (eg. matching up a GdkDeviceTool eraser with the
GDK_SOURCE_ERASER GdkInputSource of a wayland tablet).
Signed-off-by: Stephen Chandler Paul <thatslyude@gmail.com>
On the devices and backends that support it, this signal will be emitted
on slave/floating devices whenever the tool they are interacting with
changes. These notifications may also work as a sort of proximity events,
as the tool will be unset when the pen moves too far.
For backends, gdk_device_update_tool() has been included, all that should
be done on their side is just calling this whenever any tool might have
changed.
GdkDeviceTool is an opaque object that can be used to identify a given
tool (eg. pens on tablets) during the app/device lifetime. Tools are only
set on non-master devices, and are owned by these.
The accounting functions are made private, the only public call on
GdkDeviceTool so far is gdk_device_tool_get_serial(), useful to identify
the tool across runs.
This fixes a bug that was introduced by db1b24233e.
The reason why 0:0 coordinates were passed was that SWP_NOREPOSITION was
misinterpreted as SWP_NOMOVE. That is not the case - SWP_NOREPOSITION
prevents owner Z-order change, not the window position change.
gnome-control-center is calling gtk_window_resize() on configure-event
signals which leads to a busy loop.
Avoids such a busy loop by not re-configuring a window with the same
size, unless this is coming from and xdg-shell configure.
bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=764374
A naive way to perform an action on all parent nodes of a given node
could be to do:
while(gtk_tree_model_iter_parent(model, &iter, &iter)) {
/* perform some action on iter here */
}
However, since gtk_tree_model_iter_parent() will initialize the iterator
pointed to by the second parameter before performing the lookup, this
will not work.
Explicitly document this behaviour.
Signed-off-by: Wouter Verhelst <w@uter.be>
https://bugzilla.gnome.org/show_bug.cgi?id=573380
We use a label_sizing_box to make sure the headerbar can always contain
both a title and a subtitle without resizing when showing/hiding either
of them, but we should only do that for the height; the min width of the
label_box can be larger than that of the label_sizing_box.
Commit cdc580463e made it so that
unresizable windows can't be smaller than a set default size but it
lost the logic to ensure these windows remain at least big enough to
comply with their requisition.
https://bugzilla.gnome.org/show_bug.cgi?id=764174
When we invalidate a window we need to also invalidate all child windows
that are native (non-native are automatically invalidated as we track
invalidation once per native window only). This was done in a pretty
inefficient way, recursing over the entire tree.
This makes the invalidation much faster by only looking at the native
children of the native window we're in, filtering out those that
are not a descendant of the client side window we're interested in.
Given that there are very few native subwindows this is much faster.
We were missing all of the status directories, and a few sizes.
This was causing us to not find image-missing on systems without
hicolor icon theme (this basically only happens on Windows).
https://bugzilla.gnome.org/show_bug.cgi?id=764378
e8aa9b0440 introduced a new debug mode
that highlights resizes. Unfortunately it has the side effect of
always queueing redraws even when the debug mode is not enabled.
Make the redraw conditional.
Currently only one kind of decorative window is in use - the shape
indicator that is shown when snapping windows to the edge of the screen.
When normal toplevel class is used, its window procedure expects certain
motions from GDK (passing user data to CreateWindowEx(), registering
handle in a hash map etc), and might crash if that is not done.
Dumb window doesn't require anything, it can just be.
https://bugzilla.gnome.org/show_bug.cgi?id=763013
Now halfleft/halfright/fullup snaps do hug screen edges as intended.
Documents AeroSnap behaviour when snapped windows are drag-resized
(currently this implementation handles this in a very simplistic way).
Don't believe GTK when it tells us that window shadow is 0, preserve
previous values (but do remember that GTK wants no shadow, in case
we need that).
Fixes a couple of bugs in unsnapping (check offset against the half
of the window; don't put pointer in the middle of the window vertically
if it still fits in the top half).
https://bugzilla.gnome.org/show_bug.cgi?id=763013
Implements gdk_win32_window_set_shadow_width().
Uses shadow width/height to adjust max tracking size, allowing
windows to be drag-resized to cover the whole desktop.
Also uses SM_C*VIRTUALSCREEN instead of SM_C*MAXTRACK.
https://bugzilla.gnome.org/show_bug.cgi?id=763013
Indicator is a bare layered click-through native window,
painted completely by GDK, including animation.
This commit also isolates some of the more spam-ish debug logging
under ifdef.
This commit also changes the system metric used for maximal window
height for the snapping purposes. Turns out, SM_CYMAXTRACK is way
too large, use SM_CYVIRTUALSCREEN instead.
https://bugzilla.gnome.org/show_bug.cgi?id=763013
This implements the part of AeroSnap that snaps windows when you
drag them (while moving or resizing) to the edge of the screen.
It also fixes drag behaviour for snapped and maximized windows
(if such windows are dragged, first they must be unmaximized/unsnapped).
Note that this code does not take into account the shadow width, and
because of that the under-pointer-position-preserving window moves
might not look as such for maximized windows, which lack the shadow
when maximized, but do have the shadow when unmaximized.
This commit also doesn't cover some corner-cases the same way AeroSnap does.
Also, the snapping indicator (which is supposed to be a window shape that
shows where the window will be if the drag op is stopped at its current
point) is not being drawn, all routines responsible for its creation,
moving and drawing are stubs.
https://bugzilla.gnome.org/show_bug.cgi?id=763013
This is what AeroSnap does. If a window is being unsnapped on
a new monitor, check if the work area is large enough for the
window to fit in its normal size. If the window fits, just
reposition it so that the ratio of
left-window-edge-to-screen-edge / right-window-edge-to-screen-edge
remains the same, without scaling the window.
https://bugzilla.gnome.org/show_bug.cgi?id=763013
It works exactly like AeroSnap.
Except for shift+win+left/right, which is left for AeroSnap
to handle (AeroSnap takes action before we get the message,
so there's no way for us to override it).
The only thing that doesn't work is shift+win+left/right on
a maximized window, for reasons unknown at the moment.
This only implements winkey+stuff behaviour of AeroSnap,
not the drag-to-the-edge-and-something-funny-happens one.
https://bugzilla.gnome.org/show_bug.cgi?id=763013
If a layered window was hidden and is made visible, erase its
contents before showing it. GDK will schedule a redraw, but until
then we generally don't want to show old contents.
https://bugzilla.gnome.org/show_bug.cgi?id=763783
This is achieved by sending undocumented message WM_SYSMENU
to the window.
Before doing that, the window is given WS_SYSMENU style
(to enable window menu) and some combination of
WS_MAXIMIZEBOX (for "Mazimize" item)
WS_MINIMIZEBOX (for "Minimize" item)
WS_SIZEBOX (for "Size" item)
depending on which operations are currently permissible.
WM_SYSMENU is processed by DefWindowProc(), which results
in showing the window menu. We remove extra styles
at the first opportunity (WM_INITMENU message), as they
alter the way our window is rendered.
https://bugzilla.gnome.org/show_bug.cgi?id=763851
While this commit was found to make emacs windows shrink (and it was
reverted in the gtk-3-20 branch for that reason), that was the only
observed breakage, while the reversal broke several of our unit tests.
Closer study of the emacs sources revealed that it does some really
unsupportable things like doing its own X event handling behind GTK+'s
back and freely mixing sizes of GtkWindows and GdkWindows obtained in
various ways. I've filed a bug against emacs with suggestions for how
to avoid the shrinking window, regardless of this commit.
Original commit message:
It seems this branch is not needed anymore. It was originally added in
1999 to support gtk_widget_realize(), but all those reasons seem
obsolete today.
Instead just call gtk_widget_realize().
If you end up at this commit when bisecting:
There is no bug that made me remove this code, it was purely meant to be
cleanup / dead code removal. I seem to have introduced a new bug or
bisecting wouldn't have let you here. So it seems we should just revert
this commit.
Since we are really only interested in the center point of the
slider allocation, the pre-computed slider geometry is perfectly
fine, just use it always. This avoids the complication with
gadget visibility.
The slider gadget may be turned invisible as side-effect of
gtk_range_calc_slider(). If that happens,
gtk_css_gadget_get_content_allocation() returns { 0, 0, 0, 0},
which leads us to calculate a negative allocation for the highlight
node. Avoid this, by just reusing our already calculated slider
allocation in this case (it is not technically the same as the
content, allocation, but the difference hardly matter here.
https://bugzilla.gnome.org/show_bug.cgi?id=764022
These functions are supposed to return the numbers of consecutive
1 bits in each components mask as precision. However, due to a
copy-paste mistake when this code was moved around in
commit 70d689cddd, the precision
was always reported as zero. This affects only a few applications
that directly set window background on X11 windows, such as emacs.
https://bugzilla.gnome.org/show_bug.cgi?id=764210
Delay as long as possible before calling OpenClipboard(),
call CloseClipboard() as quickly as possible after that.
Don't call OpenClipboard() when we don't need to (for example,
we don't need to open clipboard to call GetClipboardOwner()).
Also, print out actual W32 error code in some cases where it
was not printed before.
https://bugzilla.gnome.org/show_bug.cgi?id=763907
Error codes can be easily looked up in an error code list
and/or googled up. Error messages, while descriptive, often
describe the wrong thing, and the messages themselves are not
part of the documentation of a function, unlike error codes.
It would be preferable to have the code, or both.
https://bugzilla.gnome.org/show_bug.cgi?id=763913
As the elements in the enum are not explicitly numbered, inserting an
element between some other elements shall change the values of elements
after the insertion. So append the new element at the end.
Anyway, no code should rely on the position of an element in an enum.
https://bugzilla.gnome.org/show_bug.cgi?id=763850
Some other widget might have mapped and raised another child window of
the toplevel in the meantime, causing the popover window to be covered.
Raise the popover window to avoid the issue.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=763627
The trash is monitored for state changes - going from empty to non-empty and the
other way round. Monitoring is done by handling change signals from a regular
file monitor. On each signal, an enumeration of the trash contents is started in
order to see if it is empty or not. This causes issues when many files are
trashed, because the gvfs trash backend is flooded with enumeration requests,
resulting in CPU usage spikes. In order to fix this, the "item-count" attribute
of the trash should be queried instead.
Replace asynchronous enumeration with asynchronous information query and update
the trash state based on the "item-count" attribute. Emit state change signal
only when the state actually changes.
https://bugzilla.gnome.org/show_bug.cgi?id=763600
gtk+ currently depends on the scaling factor and the cairo device scale
of both the backend surfaces and image surfaces to be equal.
Until now we didn't apply a cairo device scale at all and depended on the
automatic scaling of CGContexts. This works when drawing with cairo but
fails in case of image surfaces, which get requested at a too small size.
To make the quartz backend behave more like the X11 one, set the cairo device
scale on the surface in gdk_quartz_ref_cairo_surface(). As this conflicts
with the default scaling done by CGContext (we would get double scaling)
undo the CGContext scaling using CGContextScaleCTM().
This patch is based on the following patches by Brion Vibber:
https://bugzilla.gnome.org/show_bug.cgi?id=740199#c4https://bugs.freedesktop.org/show_bug.cgi?id=69796#c4https://bugzilla.gnome.org/show_bug.cgi?id=763779
When loading a per-theme settings.ini file, look for it in
the same directory where we found the gtk.css file for the
theme. Previously, we were always looking in
$prefix/share/themes/THEME/gtk-3.0/, even if the css was
loaded from somewhere else.
https://bugzilla.gnome.org/show_bug.cgi?id=641354
With this change, we now look in
$XDG_DATA_HOME/themes/THEME/gtk-3.x
$HOME/.themes/THEME/gtk-3.x
$XDG_DATA_DIRS/themes/THEME/gtk-3.x
GTK_DATA_PREFIX/themes/THEME/gtk-3.x
https://bugzilla.gnome.org/show_bug.cgi?id=641354
If the configure-event gives us the same size as we had before,
which is common for animation resizes, then try to keep the
existing buffer around. This saves us a memfd_create() syscall
on every frame.
https://bugzilla.gnome.org/show_bug.cgi?id=763350
Now that GdkWaylandDeviceData is gone, the functions prefixed
"gdk_wayland_device_" and taking a GdkWaylandSeat as first
parameter feel out of place. Renaming those makes it more obvious
that it's seat functions.
https://bugzilla.gnome.org/show_bug.cgi?id=763859
It's the same than gdk_device_get_seat() nowadays. Also, rename the
usages of GdkWaylandDeviceData to GdkWaylandSeat in the functions
affected by the removal.
https://bugzilla.gnome.org/show_bug.cgi?id=763859
When animating, we might be changing the size allocation of the previous
stack child. However, we were not querying the size in the process
meaning you would often see warnings about allocating the size without
knowing what it should be.
This simply adds an innocuous size request, since responding to last_child
sizing requests is not all that critical in the transition.
https://bugzilla.gnome.org/show_bug.cgi?id=763900
We were just relying on the drag context finalize() to destroy
the window. But with garbage-collected bindings, that might
not happen as soon as we like, so explicitly hide the window
when the drag ends successfully.
https://bugzilla.gnome.org/show_bug.cgi?id=763659
This isn't an issue at the moment. Only exporting to a file can fail
by setting by setting an error and it happens to correctly return
GTK_PRINT_OPERATION_RESULT_ERROR regardless of this code.
Still, let's make this block of code more correct to prevent future
changes from introducing broken behaviour.
https://bugzilla.gnome.org/show_bug.cgi?id=763731
We've changed our API here; what these applications are doing
used to be fine. Don't make users suffer for this by spamming their
logs in a stable release. We'll keep the warning in master.
https://bugzilla.gnome.org/show_bug.cgi?id=763796
backdrop wasn't in the mix, added and adjusted other widgets
styling not to be overridden by it when not needed.
Spotted a typo making the backdrop base color white in the process.
Using UpdateLayeredWindow() on iconic windows brings them *back* from
their iconic (minimized) state. That is bad.
As a precaution, also don't use SetWindowPos() on iconic windows.
This means that iconic windows can't be moved. That is fixable
by using SetWindowPlacement(), but there is no pressing need to do so,
as there are very few cases when windows need to be moved while minimized.
https://bugzilla.gnome.org/show_bug.cgi?id=763835
Some applications set both a default size on their gtk window and a size
request on the corresponding gtk widget.
Until now, the default size was ignored for fixed size windows, so this
had no effect and remained unnoticed, but with the recent change for
client-side decorations, the default size is now used even for fixed size
windows, which can cause the resulting fixed size window to be much
smaller than expected with the size request.
For fixed size windows, if we have both a size request and a default
size set, prefer the size request as before.
https://bugzilla.gnome.org/show_bug.cgi?id=763749
if (orientation) doesn't make a lot of sense but C doesn't complain and
instead evaluates orientation to TRUE for GTK_ORIENTATION_VERTICAL
(since that's 1), thus inverting the value sizes.
commit c3dc0d80f1 fixed the behavior of
GtkContainer widgets requesting an IMMEDIATE resize-mode.
However, GtkWindow has been stomping on resize-mode during realize()
since commit addcc64b9c. The combination
of factors that led to this not being a visible problem during all this
while is uncertain, but this now causes the Shell to continuously try to
relayout its ShellEmbeddedWindow (a GtkWindow subclass).
This commit separates the resize-mode as set internally by GtkWindow
from the one set with the external API, so that GtkWindow only changes
it when it had not been set before by the subclass.
https://bugzilla.gnome.org/show_bug.cgi?id=763650
The implicit grab may be finished so the pointer lies on top of the other
scrollbar, in this case one scrollbar should lose the hovering state, and
the other should gain it. So we must check for proximity in both indicators.
Two errors here:
1) A typo in splashscreen rectangle calculation - sets right twice
instead of setting top
2) Centering for dialogs is off because it doesn't convert
GDK virtual desktop coordinates to Windows WM virtual desktop
coordinates by adding _gdk_offset_*
https://bugzilla.gnome.org/show_bug.cgi?id=763628
The way gdk_drag_status() may be called multiple times during the
processing of drag and drop events throughout the widget hierarchy
brings some superfluous messaging going in, esp. when it's the last
request the one we want to honor, yet we emit messaging requests on
all.
This is barely appreciable in the X11 backend, but due to the design
of the wayland protocol, quick series of changes like this it have
some self-amplificating consequences which may end up flooding the
connection.
We can delegate this to a late "commit" call, performed within GDK
event management. This way gdk_drag_status() calls may be cached
and only result in windowing messaging once per ::drag-motion or
::drag-data-received event. Emitting the final status will also
avoid spurious action changes on the compositor and the other peer.
https://bugzilla.gnome.org/show_bug.cgi?id=763298
Besides the ::drag-failed handling in order to trigger the window creation
hook, add some handling of the application/x-rootwindow-drop mimetype, so
the same effect is achieved if the tab could be dropped in a destination
accepting this mimetype.
https://bugzilla.gnome.org/show_bug.cgi?id=763387
This makes toplevels pseudo-transparent wrt this mimetype, so if
the drag source offers this mimetype and not another that was
managed by the destination-side widget hierarchy, the window will
be an acceptable target for this mimetype, allowing it to trigger
whatever is meant to in the source side.
https://bugzilla.gnome.org/show_bug.cgi?id=763387
This code:
> gdk_window_get_root_origin (window, &x, &y);
> x -= root_x;
> y -= root_y;
> pointer_window = gdk_device_get_window_at_position (device, &x, &y);
was meant to find the child gdk window at coordinates root_x and root_y.
These 4 lines had 2 bugs:
1) x = x - root_x (same for y) is wrong, it should be x = root_x - x
2) gdk_device_get_window_at_position() does not give you the window
at position x and y. It gives you the window under the device
(mouse pointer) and the returns the device coordinates in x and y.
https://bugzilla.gnome.org/show_bug.cgi?id=763533
Don't make the popup follow the slider while it is open; that
makes interaction with it unnecessarily hard. Also move all the
popups inwards a little bit, so they are not flush with the
scales, which looks untidy.
https://bugzilla.gnome.org/show_bug.cgi?id=763380
We were not taking the scrollable borders into account when
requesting size for the scrolled window, which could lead
to underallocating the scrollbars at size allocation time
when we *did* take the borders into account.
This is most notable with treeviews, where we have the
headers as borders, and was causing the treeview-crash-too-wide
reftest to fail.
This test has a word that wouldn't fit in the room we have with
a window width of 100, and then we get clipped in the one case
but not the other. Make the window a little wider, so it fits.
The tree walk holds a tree iter, which will become invalid
when we either remove the row that it points to or remove
all rows.
Reset the tree walk in those cases to avoid a crash that
was pointed out by Bastien Nocera.
MacOS provides the NSEventTypeMagnify which is very similar to the
Gtk ZOOM gesture and NSEventTypeRotate which is very similar to the
Gtk Rotate gesture. Those two event sequences are translated to a
sequence of GDK_TOUCHPAD_PINCH events. This sequence is then detected
in the upper gtk layers as Gtk Zoom/Rotate Gestures.
https://bugzilla.gnome.org/show_bug.cgi?id=760276
This widget is a bit unusual in that it is a box that acts as
the drop target, while the visible content is a child of the box.
Propagate :drop(active) to the child to make the highlight visible.
When compressing window state events, we didn't free the discarded
event after removing it from the queue, causing us to leak it. This
commit makes sure to free the discarded event after unqueuing it.
https://bugzilla.gnome.org/show_bug.cgi?id=762468
We previously considered any click inside the trough if it
hit an area that the slider might cover. Bring this behavior
back; the trough of scales is otherwise just too narrow to
hit easily with a click.
Consider this bug:
1. Open a file chooser; switch it to $HOME
2. Start typing "~/Dow" with some file that *does* exist in your $HOME
3. Delete the inline-completion selection (e.g. the "nloads" after "~/Down").
4. While you are at "~/Dow_" hit Tab. No completion will occur.
This happens because of the following.
Say the GtkFileChooserEntry is in the process of loading $HOME,
because _set_base_folder() was called. If the entry contains no text,
then the FULL_PATH_COLUMN of the file system model will be set to
unprefixed filenames from $HOME, like
.ssh/
Documents/
Downloads/
somefile.txt
Later we avoid reloading the folder if g_file_equal(old_folder, new_folder).
However, the FULL_PATH_COLUMN gets populated in completion_store_set()
out of the actual filenames that GIO returned, plus the chooser_entry->dir_part.
If the user starts typing "~/Dow" then dir_part changes to "~/", *but*
the folder won't be reloaded since it is also $HOME. However, the completion
machinery assumes that FULL_PATH_COLUMN will contain prefixed entries like
~/.ssh/
~/Documents/
~/Downloads/
~/somefile.txt
So, we add an invariant that chooser_entry->dir_part and
chooser_entry->current_folder_file must change at the same time, and
must not get out of sync: If any of them changes, then the
completions are regenerated.
A gtk_surface.present request was added to gtk_surface which takes
timestamp from some input event, and uses that timestamp to figure out
whether the window can be presented or not. If we don't have a
timestamp, we should just give up instead of making up our own,
otherwise we might steal someones focus.
https://bugzilla.gnome.org/show_bug.cgi?id=763037
The gtk_shell protocol used some half baked unstable protocol semantics
that worked by only allowing binding the exact version of the
interface. This hack is a bit too confusing and it makes it impossible
to do any compatible changes without breaking things.
So, instead rename it to include a number in the interface names. This
way we can add requests and events without causing compatibility issues,
and we can later remove requests and events by bumping the number in
the interface names.
https://bugzilla.gnome.org/show_bug.cgi?id=763001
The adjustment double properties allow values from -G_MAXDOUBLE
to G_MAXDOUBLE, which leads to overflow when calculating
max - min / 10. To avoid that, simply use a fixed page_size of 1.0.
The contents node was not getting state updates at all, and the
trough node was missing some state updates as well, because we
were not calling update_trough_state() in all the places where
it is needed.
This request actually means nothing to the upper GDK layers,
we used to preempt a GDK_SELECTION_REQUEST event, but this is too
eager, and not like things work in X11.
Originally in wayland, this event may be used for feedback purposes.
We however don't perform any mimetype-based feedback, so we can
safely ignored.
This makes data_source_send() the only place where we actually
trigger GDK_SELECTION_REQUEST, this one is conceptually the same
than the X11 selection request event.
...hopefully when needed.
By default I assume a left hand side placement on ltr languages
and the opposite in rtl, for other placements left/right style
classes can be used.
Under Wayland, popovers use subsurfaces, and we end up getting
configure events for these delivered to the toplevel they're in.
To avoid triggering resize loops, ignore configure events that
are not for the toplevel window itself.
https://bugzilla.gnome.org/show_bug.cgi?id=763351
The virtual host assigns the name of the mouse device to
"VirtualBox USB Tablet" in VirtualBox and we'd use that device as mouse.
If not, GtkTooltip is not enabled.
https://bugzilla.gnome.org/show_bug.cgi?id=763017
Other portions of the GDK-Win32 backend make use of this function as
layered windows need to be disabled for GL windows and possibly other
parts, so make this function a private function that is available within
the backend.
https://bugzilla.gnome.org/show_bug.cgi?id=763285
Layered windows and GL do not work well together, so disable layered
windows when initiating a GdkGLContext, so that GtkGLArea programs can run
properly.
Also based on patch by LRN to address the issue.
https://bugzilla.gnome.org/show_bug.cgi?id=763080
The default value for the double-click key in the
org.gnome.settings-daemon.peripherals.mouse schema is 400.
Use the same value as the declared default for the
gtk-double-click-time GTK+ setting, to avoid pointless
differences in corner cases.
https://bugzilla.gnome.org/show_bug.cgi?id=720950
The sidebar in the object page was using up more space than it deserves.
Replace it with a combo box in the subheader. Now that we have more space,
put the CSS node tree and the style properties in the same page again.
And add a default color like it was before.
This also fixes other issues with scale values interacting with scale
mark labels, which were buggy at least since 3.18.
When opening the value editor for any GtkAdjustment properties
in the inspector, the popover stretches out for miles, since
it reserves enough space to draw MAXDOUBLE. This is not useful.
Limit the space we reserve to 8 digits.
This removes the event_poll_fd global variable and the (ab)use of
get_default_display. It is also more consistent with other backends.
Also store display
This is not much of a test, tbh. But it will give us a convenient
dump of all GTK+ settings in continuous, which helps with tracking
down test failures that might depend on settings.
We're seeing loops where the size of some status icons constantly
dithers between 24 and 25. Since I couldn't track down exactly
where the one extra pixel comes from, just stop reacting
to single-pixel size changes.
https://bugzilla.gnome.org/show_bug.cgi?id=758893
We used to always make the labels in message dialogs selectable,
which is a bit problematic wrt. to keynav - the label can
unexpectedly 'turn blue', which irritates some people.
With the new gtk-keynav-use-caret setting, we can now only
make the labels selectable when it is required for accessibilty
reasons.
When changing tool button contents according to the toolbar-style
property, we need to update the style classes to ensure that the
visual style matches.
https://bugzilla.gnome.org/show_bug.cgi?id=760560
gnome-session takes an "app id" for client and inhibitor registration,
This app id is supposed to be a desktop file id (complete with the
.desktop extension), but gtk+ currently uses g_get_prgname ().
This commit changes gtkapplication to use the application id instead,
which is a much more natural fit. gnome-session is going to be updated
to stop using the .desktop extension, too, so everything is consistent.
https://bugzilla.gnome.org/show_bug.cgi?id=763106
We weren't using the open flags on the other locations signal, which
makes impossible for applications like nautilus to act in the same
way that for any other location where the user can choose between
opening in the current view, in a new window or in a new tab.
Add a new signal with an open flags parameter and deprecate
the other-location signal.
https://bugzilla.gnome.org/show_bug.cgi?id=754743
Use gdk_window_get_effective_toplevel when looking for
a suitable transient parent, to skip over offscreen windows
that we might encounter in the window tree. This fixes
a crash in glade.
https://bugzilla.gnome.org/show_bug.cgi?id=763110
One important aspect of non-resizable windows that we need to preserve
is that they shrink when their content requires less size.
Previous changes to allow the default size to be applied to fixed size
windows would have prevented all fixed size windows from shrinking when
their content requires less size.
Allow shrinking for fixed-size windows unless a default size was
specified.
https://bugzilla.gnome.org/show_bug.cgi?id=762974
It does not make sense to pass a for_size into the size allocation
machinery that is smaller than the min-size in that direction.
Warn if it happens, so we can track it down when it occurs.
added a min-height/width compensation too when in fine-tune mode,
so scale with marks and no labels doesn't make the scale node grow
when in fine-tune.
added a scale node padding compensation for the trough growth in
fine-tune mode, so now the scale node doesn't grow anymore when
mark labels are present.
We were failing to do that, leading to progress not disappearing
anymore after it was initially shown, in the gtk3-widget-factory
entry progress example.
Fixes bug 763023: in certain circumstances, XRRGetOutputInfo will return
a null pointer. This commit adds a check to detect and handle this
return value.
If animations are disabled, the only difference we need to make is that
we don't have to start the transition. Size requests should remain the
same.
https://bugzilla.gnome.org/show_bug.cgi?id=762996
Previous commit to address the default size introduced a regression
with fixed size windows if no default size was given, the resulting
window would end up much smaller than its actual content.
kind of a workaround, this approach is pretty unmaintainable, I
hope we'll get a CSS property for spacing directly on the parent
container (a toolbar in this particular case).
See https://bugzilla.gnome.org/show_bug.cgi?id=762397
If a window is not resizable (with gtk_window_set_resizable ()),
the size given with gtk_window_set_default_size() is ignored.
The solution to this would be to use gtk_widget_set_size_request() but
that's a GtkWidget API and therefore does not take into account the
client side decorations when in use with GtkWindow.
Refactor the code so that gtk_window_set_default_size() (which is a
GtkWindow API) gives the expected result on non-resizable windows as
well.
bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=762974
Will make GTK+ more willing to use CSD for all normal windows without
being asked to. Lack of desktop composition will, of course, prevent
it from using CSD (in theory).
GTK_CSD=0 will force CSD to NOT to be used whenever
possible (i.e. in cases where CSD is not specifically requested
by a window, by design).
https://bugzilla.gnome.org/show_bug.cgi?id=759899
Otherwise WM-dependent default cursor is used, which does not
match our theme. Worse, later GDK will realize that we have
our own left_ptr cursor and will apply it after all, making
the discrepancy even more noticeable.
https://bugzilla.gnome.org/show_bug.cgi?id=762902
* Explicitly grab the device, setting appropriate cursor on it.
* Fix gdk_device_virtual_set_window_cursor() to just set the
cursor, without trying to check that mouse is over the given
window. Also prevent it from immediately resetting cursor.
* Alse take into account things that happen in other parts of
GDK - don't look for replacement cursor, GDK already did that,
and don't create a default arrow cursor instead of NULL,
GDK-W32 already did that up the stack as well.
Warn about inappropriate cursor == NULL argument instead.
https://bugzilla.gnome.org/show_bug.cgi?id=762711
When a gtk_widget_queue_allocate() on some widget increases the clip,
widget->parent's clip was not updated. This appraoch naively just
unions widget's new clip with widget->parent's clip.
This of course only works if widget and parent share the same GDK
window. In the cases where they don't we can't do anything and need a
better fix.
Fixes label-text-shadow-changes-modify-clip.ui reftest.
Toplevels are now true layered windows that are moved,
resized and repainted via UpdateLayeredWindow() API call.
This achieves transparency without any extra effort,
and prevents window size and window contents desychronization
(bug 761629).
This also changes the way CSD windows are detected. We now
use window decorations to detect CSDiness of a window,
and to decide whether a window should be layered (CSD windows should
be) or not.
Decorations are now stored in the window implementation,
not as a quark-based property of the window-as-gobject.
https://bugzilla.gnome.org/show_bug.cgi?id=748872
Normally works only on CSD windows, non-CSD windows continue
to use WM modal loop for drag-resizing and drag-moving. However,
if it is activated on non-CSD windows, it does work.
Has the advantage of being completely immune to AeroSnap.
AeroSnap only worked partially on CSD windows, with the only part
that worked being "don't let users drag window titlebar outside of
the desktop". Now AeroSnap doesn't work on windows moved by
this code at all, which is good, since they currently don't work
well with it due to the way shadows are drawn.
It's possible to also re-implement AeroSnap (or something similar),
but that is a story for another commit.
This code was originally intended to fix the problem of window
size and window contents desynchronization, but failed to achieve
that result in the end. Nevertheless, it serves as a foundation for
other changes to the way window resizing works.
https://bugzilla.gnome.org/show_bug.cgi?id=761629
key repeat is handled client side, which means stalls in the compositor
dispatching key release events can lead to fictious repeat events.
This commit ties key repeat to a server roundtrip to ensure the client
and server are in sync.
https://bugzilla.gnome.org/show_bug.cgi?id=757942
We don't need the key repeat rate or anything like that when
handling key up events, so do key up events first before querying
for that information.
https://bugzilla.gnome.org/show_bug.cgi?id=757942
deliver_key_event is sometimes called from a timeout handler and
sometimes called directly. We currently erroneously return TRUE
(G_SOURCE_CONTINUE) in the case where it's called directly, but to
no ill effect, since we ignore that return value. In the future,
we're going to need to call it directly in other parts of the code
where the return value would be relevant and handling TRUE, would
require adding redundant code.
Instead, this commit just changes the code to always reset the timer
manually, and never rely on glib's ability to automatically reset
the timer by returning TRUE. This makes the code smaller, too, since
there's less special casing required.
https://bugzilla.gnome.org/show_bug.cgi?id=757942
The check is not working for many containers anymore as they are not the
direct parents of their children. We want to allow this behavior in more
places.
We are actually not using the crypt() in GDK-Broadway for quite a while,
so the code implementation for MSVC is actually not used. So, it's time
to get rid of this.
Search also for the headers in include/gio-win32-2.0, as gio.h will
include those headers at some point, and arrange the include paths in a
dependency hierarchy style, top-to-down.
If the parent of a transient is not a native Wayland window (e.g.
offscreen window), the transient loop check will crash.
Check for the actual type in the transient loop check and do not assume
the parent is necessarily Wayland native.
bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=761156
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
If there are already a window state event for a given window queued
when the window state is changed, drop that event and queue a new event
with a changed_mask based on the state before last event that was queue
without compression.
https://bugzilla.gnome.org/show_bug.cgi?id=762468
We create and destroy gadgets inside the levelbar hierarchy here,
and if we don't explicitly remove their CSS nodes from the parent,
they stick around.
According to xdg_shell, an xdg_surface.configure with size 0x0 should
be interpreted as that it is up to the client to set a size.
When transitioning from maximize or fullscreen state, this means the
client should configure its size back to what it was before being
maximize or fullscreen.
This problem currently only occurs on weston because weston sends a
configure with size 0x0 when transitioning back from maximize or
fullscreen.
bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=762713
gdk_display_list_devices is deprecated and all the backends
implement the same fallback by delegating to the device manager
and caching the list (caching it is needed since the method does
not transfer ownership of the container).
The compat code can be shared among all backends and we can
initialize the list lazily only in the case someone calls the
deprecated method.
https://bugzilla.gnome.org/show_bug.cgi?id=762891
The way this method is used from the GtkRange subclasses doesn't really
work well when the slider properties change as a consequence of e.g. a
style class being applied (e.g. the fine-tune style class).
In fact, there's no need to read the minimum slider size out of band,
and we can obtain the same result in a way that always work by setting a
private property on GtkRange.
Since we can use negative margins, we should not use the margin box
for the slider area. Use the border box instead, since that's what is
typically mapped to the visible area.
This commit introduces another node, called "contents", that holds the
main contents of the range. This allows for the main gadget itself to
span across the whole surface of the widget now.
The staging buffer gets allocated any time begin_paint is called
on the window. This can happen even with an empty paint region,
so we should cope with that situation. At the moment we crash
trying to post a runtime warning.
https://bugzilla.gnome.org/show_bug.cgi?id=762755
We were adding the border gadget size and the label widget size in any
case, but when calculating the width, we want the maximum of those two,
not the sum.
https://bugzilla.gnome.org/show_bug.cgi?id=760482
The g_print documentation explicitly says not to do this, since
g_print is meant to be redirected by applications. Instead use
g_message for logging that can be triggered via GTK_DEBUG.
The g_print documentation explicitly says not to do this, since
g_print is meant to be redirected by applications. Instead use
g_message for logging that can be triggered via GTK_DEBUG.
The g_print documentation explicitly says not to do this, since
g_print is meant to be redirected by applications. Instead use
g_message for logging that can be triggered via GTK_DEBUG.
The g_print documentation explicitly says not to do this, since
g_print is meant to be redirected by applications. Instead use
g_message for logging that can be triggered via GTK_DEBUG.
The g_print documentation explicitly says not to do this, since
g_print is meant to be redirected by applications. Instead use
g_message for logging that can be triggered via GTK_DEBUG.
GtkWidget uses gtk_container_foreach() to iterate over children and
check whether they need their allocation reset.
However, that leaves out internal children, such as scrollbars of a
GtkScrolledWindow. Use gtk_container_forall() instead.
gdk_display_add_seat was prepending new seats to the list, which
was effectively making the added seat the new default. Since that
is probably not intended, append to the list.
Setting label-yalign should affect the border gadget, but we need to
compensate for its position by moving the child down or up, depending on
the border gadget's position, so the child never moves.
https://bugzilla.gnome.org/show_bug.cgi?id=762123
The gdkprivate-wayland.h header file is included from the top-level gdk
directory; this means that all included files referenced in the header
must be relative to the `gdk` directory, otherwise the build will fail
when the build directory is not equal to the source directory.
This commit fixes a build failure under continuous:
In file included from ../../gdk/gdkdisplaymanager.c:60:0:
../../gdk/wayland/gdkprivate-wayland.h:40:51: fatal error:
gtk-primary-selection-client-protocol.h: No such file or directory
#include "gtk-primary-selection-client-protocol.h"
^
compilation terminated.
Makefile:1155: recipe for target 'libgdk_3_la-gdkdisplaymanager.lo' failed
make[4]: *** [libgdk_3_la-gdkdisplaymanager.lo] Error 1
Except for the init function, all the visual related code is made
of gdkscreen vfuncs, so let's move it to gdkscreen-win32. This way
we avoid keeping other static variables and instead store the info
inside the screen struct.
It just looks wrong if the file chooser comes up with
"Other Locations" ellipsized. Treat it like the other
fixed entries. We only want to ellipsize bookmarks, because
their length is unpredictable.
We now draw real Windows 95 buttons.
Also split out a draw_edge() function that is supposed to emulate
Windows' DrawEdge() function. I guess we'll need it in other places,
too.
So far, this only reworks the tabs at top implementation.
Windows doesn't have support for theming tabs at left/right/bottom
so we need to figure out what to do there. Wine falls back to
unthemed code.
This is necessary for GtkNotebook so that the stack is always drawn
before the header.
And that is necessary so that the active tab can use negative
margins to overdraw the border of the stack to create a gap and
simulate old GTK2-style visuals for notebooks.
:active is reserved for "mouse button down on node", so we have to use
something else. And stack switcher and radio buttons use :checked for
the active widget, so it makes sense to use :checked for the active tab,
too.
Themes have been adapted.
TODO: Implement :active for tabs.
I am testing GTK+ master against mutter 3.19.90, so I'd
like GTK+ to survive even when the compositor does not
support the primary selection interface.
Implement it using the internal copy of the protocol. Otherwise,
we just deal with it the same than clipboard selection, just mapping
it to the PRIMARY atom instead of the CLIPBOARD one.
https://bugzilla.gnome.org/show_bug.cgi?id=762561
This protocol is an internal mirror of the primary selection drafts
being proposed for wayland-protocols. No changes besides prefix/suffix
changes.
https://bugzilla.gnome.org/show_bug.cgi?id=762561
1f74f12d9 rendered entry of keypad decimal mark unuseable for
several national keyboard layouts, this commit amends that, at
least for W32, and makes GTK+ behave more or less the same way
W32 behaves.
The patch works like this:
- When typing the first character at the keyboard or when switching
keyboard layouts, the decimal mark character will be cached in the
static variable "decimal_mark" within gdkkeys-win32.c
- in case of WIN32, gdk_keyval_to_unicode() asks gdkkeys-win32.c for the
current decimal_mark when converting GDK_KEY_KP_Decimal.
https://bugzilla.gnome.org/show_bug.cgi?id=756751
1) MSDN says that the coordinates of the maximized window
must be specified as if the window was on the primary display,
even if nearest display where it ends up is not the primary display.
So instead of using nearest display work area verbatim,
use it only to account for taskbar size, while using
primary display top-left corner (0:0) as the reference point.
2) MSDN says that max tracking size is a system property, we
should just call GetSystemMetrics() and use that.
https://bugzilla.gnome.org/show_bug.cgi?id=762629
This is a hack because we can't really rtesize the buttons.
Instead, we draw the background only over the area that they would
be drawn if they were drawn by Windows. The button is still selectable
outside of this area, but what can you do...
The way we were adjusting baselines if min-height forces
a size increase was not quite working as intended. Redo
it in a simpler way: just split up the excess and count
half of it for above the baseline and half below.
This fixes button labels in dialogs appearing too low.
It is clearly not the intention that the baseline of icons is at
the very top. The visible effect of this was that spin buttons were
higher than expeted, because the box gadget was trying to line up
the baseline of the text with the top of the buttons, forcing extra
height to be requested.
Just don't set a baseline at all for now.
That would imply the pixelcache monitors the style context for changes
and it doesn't do that.
Its only use case was opacity checks, so add
gtk_pixel_cache_se_is_opaque() instead.
We were updating the whole places sidebar when the trash changed.
This effectively removes all rows and create new ones for every trash
state change.
Although when using GtkTreeView it was somehow ok, with the new
implementation with GtkListBox this effectively locks the UI while the
trash operations are being performed.
When performing operations for i.e. 100 files, the UI can be locked
for more than 1 minute since gvfs-trash usually takes time.
To fix this just update the icon of the trash when the state of the
trash change instead of the whole sidebar.
https://bugzilla.gnome.org/show_bug.cgi?id=762677
This adds vendor and product id and axes. This reveals that
the GDK backends have quite different quality when it comes
to returning meaningful information here.
When size_allocate is overridden in widgets, but draw is not,
we can end up drawing a gadget that has not been given a size.
Warn about this, and limp along by drawing the gadget over the
full allocation of its owner widget.
https://bugzilla.gnome.org/show_bug.cgi?id=762614
Sigh.
Now that we've neutered the QEMU USB tablet, I'm finding that
spice is doing just the same nonsense. It has a fake "spice vdagent
tablet". Blacklist that as well.
Text handles use to connect to the first GtkScrollable up the hierarchy
so they can be repositioned when scrolling. It makes more sense to look
up the first child of a GtkScrolledWindow, it must be an scrollable too,
and will be the scrollable that can actually change the position of the
text handles.
https://bugzilla.gnome.org/show_bug.cgi?id=761676
... if the child is concealed and the transition type is set to NONE.
In this case, both preferred width and preferred height should be 0, but
we still can't use that to allocate a size for the child, so care about
the minimum size of the child in gtk_revealer_get_child_allocation.
https://bugzilla.gnome.org/show_bug.cgi?id=761760
We were using the enclosing location when connecting to a server, so
for instance if we were connecting to ftp://test/test it would actually
open ftp://test/ instead of the full path.
To fix it, use the full location when emitting the open location signal.
https://bugzilla.gnome.org/show_bug.cgi?id=756659
Remember the last source device we're generating multiple clicks for,
just so we can bail out if the device changed. That will just reset
the counting.
https://bugzilla.gnome.org/show_bug.cgi?id=723659
This prevents multipress sequences to possibly come from different mice.
Now the accumulated number of presses will be reset if the device changes
in the mean time.
https://bugzilla.gnome.org/show_bug.cgi?id=723659
We weren't using the open flags on the other locations signal, which
makes impossible for applications like nautilus to act in the same
way that for any other location where the user can choose between
opening in the current view, in a new window or in a new tab.
Add the signal missing parameter in order to allow it.
https://bugzilla.gnome.org/show_bug.cgi?id=754743
Previously we just checked the first character. And if that was a "-" as
in "-gtk-some-special-value", we assumed it was a number. Which it
clearly wasn't.
Test included
Containers with RESIZE_MODE_PARENT should never request layout and those
with RESIZE_MODE_IMMEDIATE should only request it for updating CSS.
Fixes clutter embeds (like the tray icon embed in gnome-shell)
continuously requesting relayout when all they want to do is relegate
relayout to Clutter.
https://bugzilla.gnome.org/show_bug.cgi?id=758893
On Visual Studio, unlike MinGW, manifest files are embedded via
including the manifest file as a resource file in the projects, not
via the .rc file. This means that the line in the .rc file that
specifies the manifest file would cause trouble, so that line gets
removed when the full gtk3-win32.rc is generated on Visual Studio builds,
otherwise 2010+ Visual Studio will complain when compiling the .rc file.
Also, the inclusion of winuser.h will cause warnings during the
compilation of the .rc file.
Fix this by isolating the Win32 resource portions of gtk-win32.rc.in to
gtk-win32.rc.body.in and:
-On MinGW, construct the full gtk-win32.rc by doing the winver.h and
winuser.h inclusion first, then append the contents of gtk-win32.rc.body,
and then appending the line to embed the manifest file.
-On Visual Studio, simply copy the gtk-win32.rc.body to gtk-win32.rc,
and generate the full libgtk3.manifest file.
https://bugzilla.gnome.org/show_bug.cgi?id=762311
The first check was the wrong way around.
The second check made the function look wrong. Invalid ID is actually
the special case that should be handled first, so write the function
like that.
We were forcing the size to be at least min-height, but we left the
baselines as they were, which had the effect of making text e.g
in entries 'stick to the top'.
With this change, we adjust the baseline to keep the ratio of
baseline to height unchanged.
The code for adjusting the center widget allocation in case
of uneven sides never worked right in RTL. This was finally
noticed for tabs with close button, which commonly use a
centered label.
The significant change here is a memory leak fix in init_xrandr15.
The rest of the changes makes init_xrandr13 and init_xrandr15 more
parallel, and simplifies init_multihead.
GdTaggedEntry needs that. Though there's probably a bunch of work left
inside GdTaggedEntry to make it look cute again (like storing the area
it reserves for itself to allocate tags in).
Add a gtk_shell.set_startup_id request, so the application can communicate
to the compositor the startup id that it received through the
DESKTOP_STARTUP_ID envvar, or other means.
When running with a Wayland compositor which doesn't support the
xdg_shell interface, gtk+ will segfault while trying to access the
corresponding wl proxy.
Check for xdg_shell support and do not use Wayland if not present, so
that it can fallback to X11, hoping that Xwayland is usable.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=762258
we use to animate "all" in the transition, this seems to trigger
some weird gtk sizing issue, restricting the transition to just
the needed properties fixes.
We were notifying when an unmount operation was performed. However,
creating notifications from the gtk+ library is not that expected, and
makes notification handling difficult to do from the application point
of view since we cannot dismiss those notifications.
This cause issues like notifications of unmount drives stay there after
a system reboot, which confuses the user.
Instead of that, remove the notification handling for mount operations
on gtk+ and instead create a new signal on the gtkplacessidebar in order
to inform applications using it about an operation about to start.
Only drawback about this is that the GtkFileChooser loses its
notifications when unmounting, that although we could use the new signal
to do it, we actually don't want to notify from any part of gtk+ for
now.
https://bugzilla.gnome.org/show_bug.cgi?id=753351
Some of the translated strings in the cups printbackend are short
and generic and might occur in other contexts. Give them disambiguating
message contexts to avoid translation problems.
There is no point in attaching and then committing the same buffer if
there was no damage. This will also make us do less unnecessary backfill
read backs, for the cases where we paint with an empty paint region.
https://bugzilla.gnome.org/show_bug.cgi?id=762120
If a after-paint was scheduled but nothing was painted, for example when
the it was scheduled by a subsurface wanting to update its position,
we'd still try to read back from the backfill cairo surface and update
the committed cairo surface reference even though no buffer was
attached.
Fix this by adding a new state, 'pending_buffer_attached', which is only
true if a buffer was attached during frame. Only when this is true will
the backfill be read back and the committed cairo surface reference be
updated.
https://bugzilla.gnome.org/show_bug.cgi?id=762120
The following changes were done to (hopefully) achieve backwards
compatibility while allowing themes to change the size of the indicator.
(1) Deprecate the property.
(2) Change the default value of the property to 0. If it is not 0,
use the property's value for the indicator size. This should make
all programs that actually set it keep the size they set it to.
(3) If set to other values than 0, use min-width/min-height of the
check/radio node to size the indicator. This allows themes to change
the size.
(4) Fall back to the previous default size of 16px. This way themes that
do not set the size keep the same behavior.
...the sizing is still off, waiting for Benjamin to add the magic,
probably the icon shadow is missing, not sure since it's blurry.
This needs to be reverted in case the sizing won't get fixed.
That way we can let ::cancel callers to override the visual
result of the operation (eg. when detaching notebook tabs on
NO_TARGET).
Also, document gdk_drag_drop_done() so it is mentioned that
this is a one-shot call.
https://bugzilla.gnome.org/show_bug.cgi?id=761954
We should conform to a minimal set of reasons for the gtk side to emit
a better GtkDragResult than GTK_DRAG_RESULT_ERROR. This fixes the notebook
tab DnD feature, where we rely on GTK_DRAG_RESULT_NO_TARGET.
In the wayland side, unfortunately we can't honor either NO_TARGET nor
USER_CANCELLED, we don't know of the latter, so we could return false
positives on the former.
https://bugzilla.gnome.org/show_bug.cgi?id=761954
Sometimes default tab labels ("Page <n>") get created on-demand,
and in that case, we were forgetting to put them below the tab
node in the CSS node tree. The visible result of this is that the
heuristics for when to give notebooks background in Adwaita fail
in some cases. So, make sure to always place the label below the
tab node.
Instead of drawing them as the background, use -gtk-icon-source.
Also size the marks properly.
Because Windows doesn't have indeterminate radio buttons, use a
cross-fade between checked and unchecked radiomark instead. But
unlike previously, use CSS cross-fade() syntax to draw it.
Padding adds up. A selector like "actionbar box" matches any box
inside an actionbar, so nested boxes accumulate more and more
padding. The intention clearly was to just give padding to the
topmost box that is the direct child of the actionbar's revealer.
https://bugzilla.gnome.org/show_bug.cgi?id=762036
Clip children to their window's size. That way no overdraw happens for
these widgets. But don't clip the handle.
We might in the future consider not clipping un-shrinkable children.
https://bugzilla.gnome.org/show_bug.cgi?id=762021
This requires adding code to do math on number values:
gtk_css_number_value_multiply()
and
gtk_css_number_value_try_add()
were added to achieve that.
Some tests are included.
GtkCssNumberValue is now a base class for numbers.
Actual numbers are now implemented in GtkCssDimensionValue. The name is
borrowed from the CSS spec, so there.
This is in preparation for calc(), as calc(50% - 5px) is valid CSS
but has 2 units. Instead, add a function to query a value's dimension
(so we can differentiate lengths from numbers) and add a function to
query if the value contains percentages.
Margins can be negative, and if we are not careful, then
content+padding+margin can end up with negative dimensions,
which can upset pixman and others. This commit ensures
that a gadget will not request or draw boxes with negative
dimensions, and get_border_allocation and get_content_allocation
will not return boxes with negative dimensions.
This fixes a crash in the paned separator drawing code that
can be reproduced by setting separator padding to 0.
https://bugzilla.gnome.org/show_bug.cgi?id=759657
With the location entry up in the header bar in save mode, we can
end up with the search model being in use when the user types in
the location entry. In this case, we don't make the Save button
sensitive as we should.
Having two entries in the dialog is somewhat confusing anyway,
so just stop the search when the user starts typing in the location
entry.
https://bugzilla.gnome.org/show_bug.cgi?id=761757
This reverts commit 572e9a0402.
_gtk_box_get_children was not doing exactly the same than
gtk_container_get_children does, because the latter uses the forall
implementation of GtkBox that takes into account the children pack mode while
the former just iterated the list of children. This broke the order of
the buttons in a GtkButtonBox when they were packaged with PACK_END.
Entries in treeviews and similar embedded situations don't really
work well if their height is forced to be big. Take out the min-height
for these.
https://bugzilla.gnome.org/show_bug.cgi?id=761686
It does no good to iterate through a series of mime types to call a
function when the eventually-called function,
_gtk_quartz_get_selection_data_from_pasteboard() in this case, gives the
wrong answer and stops the iteration on all but one especially if that
one isn't first.
The one is "image/tiff" and the quartz pasteboard function will return
any image type Quartz knows about for it, so lose the iteration and use
only "image/tiff".
A problem that has been observed in polari is that links in tags
are clickable all the way into the margin. This problem is caused
by gtk_text_view_get_iter_at_position ignoring the return value
of pango_layout_xy_to_index. Instead, pass it back as a boolean
return value. This is technically an API break, but we've allowed
ourselves to change return types from void to gboolean before.
Always have Since: annotations at the very bottom, use the correct
ClassName::signal-name/ClassName:property-name syntax, fix a few typos
in type names, wrong function names, non-existing type names, etc.
The first time a window is shown we should always call SW_SHOWNORMAL.
Understand whether to call SW_SHOW or SW_SHOWNORMAL and the specific
ones for the temporary windows depending on IsWindowVisible.
This also fixes the problem when calling gtk_window_present and
the window is snapped to the left or right of the screen.
This patch is based on the patches provided by Yevgen Muntyan
and Aleksander Morgado.
https://bugzilla.gnome.org/show_bug.cgi?id=698652
If the window is iconified we want to restore the window
to get the proper size instead of showing it normal which
would change the size of the window.
https://bugzilla.gnome.org/show_bug.cgi?id=698652
Things like color affect symbolic icons, but not colored icons, while
other css properties like -gtk-icon-effect affect colored icons, but not
symbolic ones.
If the theme has rounded corners for fullscreen, we don't tell the
window manager that we are now fully opaque, which then makes things
less efficient than they should be.
https://bugzilla.gnome.org//show_bug.cgi?id=761571
When we don't get a baseline passed in, we want to basically
center the children inside the allocation. There was an attempt
in the code to do 'internal baseline alignment', but it had the
side effect of moving the contents to the top when we don't get
a baseline passed in. Remove it for now, this needs some more
infrastructure to do properly.
https://bugzilla.gnome.org/show_bug.cgi?id=761363
These were affected by the recent change to level offset handling.
At the same time, make the test files more realistic by updating
the level offsets when we set a custom range.
We had some odd special-casing for the lowest and highest offset
that did not quite work. The new rule is simple: If the value
is between offset n-1 and n, it gets the style for offset n.
https://bugzilla.gnome.org/show_bug.cgi?id=761416
There are a couple of issues with the way that buffers are handled in
wayland in right. These issues mean that:
- buffers can get leaked at a fairly fast clip under the right
conditions. This leads to the OOM killer kicking in and
gnome-shell and gnome-terminal (for instance) showing memory
usage in the high gigabytes range.
- drawing can happen to a shared memory buffer at the same time
the compositor is reading out the pixels. This can lead to
glitching in drawing and other undefined behavior by the compositor.
This changeset reworks how buffer management is done in the code to try
to address both problems.
The first change (commit 2c300081) addresses the leak by dropping code
that has an unchecked cairo_surface_reference call. The code is dropped
rather than fixed, because it has a more serious issue: it's overarching
purpose is to deal with shared memory buffer contention with the
compositor, but it does it in a racy way and so fails at that mission.
The second change (commit 40e91195a) moves what layer of the code buffer
release events are handled. This is an organizational change in the
code, with no functional changes, but it's important for the last change
in the changeset.
The last change (commit c80dd549) adds back code for dealing with shared
member buffer contention in a race free way. The new code is careful to
never reuse a buffer that hasn't been explicitly released by the
compositor.
Right now we use one buffer for both staged changes (freshly painted
changes waiting for the frame clock to send to the compositor) and
committed changes (changes actively being read by the compositor
process). This creates a problem in the event we need to stage updates
at the same time the compositor is processing committed updates: we
can't change what the compositor is actively processing.
The current solution for handling this contention is to allocate a
temporary buffer on the spot at the time the updates are staged, and to
copy that buffer back to the shared buffer later. The problem, though,
is that the copy to the shared buffer currently happens as soon as
the updates are finished being staged, not when the shared buffer is
done being processed by the compositor.
In order to address that problem, this commit changes the code to always
stage changes to a dedicated staging buffer. The staging buffer is
used exclusively by the client until the client is done with it, and then
once that staging buffer is committed, the client never writes to that
buffer again. If the client needs to stage new updates, it allocates a
brand new staging buffer, draws to it, and back fills the undrawn parts
of the buffer from a copy of the contents of the committed buffer.
As an optimization, the compositor has the option of releasing the
committed buffer back to the client. If it does so before the client
needs to stage new updates, then the client will reuse the buffer
for staging future updates. This optimization prevents having to allocate
a new staging buffer and the associated cost of back filling
that new buffer with a readback of the committed buffer.
https://bugzilla.gnome.org/show_bug.cgi?id=761312
Right now we handle buffer releases coming from the
compositor in a central place. We add a listener when
first creating the shared buffers.
This is problematic because a buffer can only have
one listener on it at once so users of the buffer
can't get notified when it's released.
This commit moves the buffer listener code from the
centrally managed display code to the cursor and window
code.
https://bugzilla.gnome.org/show_bug.cgi?id=761312
The client and compositor share access to the window
pixel buffers. After the client hands off (commits)
the buffer to the compositor it's not supposed to write
to it again until it's released by the compositor.
The code tries to deal with this contention by allocating
a temporary buffer and using that in the mean time. This
temporary buffer is allocated by a higher layer of the code
when begin_paint returns TRUE. Unfortunately, that layer of
the code has no idea when the buffer is released, so it ends
up blitting the temporary buffer back to the shared buffer
prematurely.
This commit changes begin_paint to always return FALSE.
A future commit will address the contention problem in
a different way.
https://bugzilla.gnome.org/show_bug.cgi?id=761312
There are a few places where we destroy a cairo surface and
then nullify it. This commit changes those to use
g_clear_pointer instead.
It also drops a cairo_surface_finish call that is unnecessary
https://bugzilla.gnome.org/show_bug.cgi?id=761312
The name surface is really overloaded when dealing
with wayland windows.
To alleviate ambiguity, this commit changes the name
of the "surface" and "subsurface" members to have
a wl_ prefix.
https://bugzilla.gnome.org/show_bug.cgi?id=761312
Don't allow syntax like
at top left circle
but follow the spec about requiring the at <position> right before the
comma.
This is porbably because
circle at 10px 10px
could be interpreted as
circle 10px at 10px
with the now disallowed syntax, too.
Test included.
Don't hardcode 96 for dpi, but instead use the value of the -gtk-dpi
property (that mirrors the GdkScreen's dpi if it wasn't set explicitly).
This makes these values scale when the large font setting in
control-center is enabled.
During the gadget conversion, the drawing of discrete levelbars
was unintentionally changed to draw a wide trough but narrow
blocks, which does not look great. So go back to the previous
way of drawing things.
https://bugzilla.gnome.org/show_bug.cgi?id=761428
Now selecting a widget by class name no longer works.
This is probably most relevant for users outside of GTK that want to
style their own widgets. Those widgets should now either add their own
style classes (if they want to adjust existing CSS) or use
gtk_widget_class_set_css_name() themselves (if they want to get rid of
all "upstream" styling).
And reset the grab_location in the ::released handler of the multipress
gesture.
Previously, when leaving fine-tune mode, the ::released handler of the
multipress gesture would call stop_scrolling, which calls
range_grab_remove and resets the grab_location. The ::drag-end handler
is executed after that, and only unsets priv->in_drag if the
grab_location is MOUSE_OUTSIDE, which it never was, since the ::released
handler already reset it. This lead to priv->in_drag being set even
though no dragging was in progress anymore, which e.g. made shift
pressed after leaving the fine-tune mode entering it again.
https://bugzilla.gnome.org/show_bug.cgi?id=761402
The fallback behaviour of get_work_area () divides the
screen width and height by the window scaling factor, but
those values are already scaled down.
https://bugzilla.gnome.org/show_bug.cgi?id=761474
Calling _gtk_file_consider_as_remote() with a NULL argument
results in warnings being thrown.
Note that query->priv->location being NULL is a state that does
not seem to be invalid by itself.
This could happen if you do search-as-you-type in a filechooser,
which has a filter that does not match anything *and* the current
"place" selected is "Recent".
https://bugzilla.gnome.org/show_bug.cgi?id=761552
Instead of
/org/gtk/libgtk/theme/$THEME-$VARIANT.css
look at
/org/gtk/libgtk/theme/$THEME/gtk-$VARIANT.css
and that way mirror the directory layout of real themes.
Set _GTK_THEME_VARIANT to empty string when default theme variant
is used. This will allow to understand whether _GTK_THEME_VARIANT
is not supported or default variant is requested.
https://bugzilla.gnome.org/show_bug.cgi?id=761476
This test was failing in continuous, where the tests are running
in a VM with disabled animations. Make the test adapt to that
situation by changing the rui on the fly if we find that animations
are disabled.
This test was failing in continuous, where the tests are running
in a VM with disabled animations. Make the test adapt to that
situation by changing the reference ui on the fly if we find
that animations are disabled.
Make the preview command parse options properly, turn the ID into
an --id=ID option, and add a --css=FILE option that allows to
specify a css file to use for previewing.
This is useful for e.g. previewing the reftest .ui files with
their corresponding .css.
Since 39c2d12330,
priv->operation_mode == OPERATION_MODE_BROWSE no longer
guarantees that priv->browse_files_model is the current
model of the list - we are only switching the models after
loading the new directory. Avoid triggering the assertion
in show_and_select_files by checking if we have right model
before calling it.
https://bugzilla.gnome.org/show_bug.cgi?id=761209
Temp windows without parent are used frequently in our testsuite;
using g_warning on them causes the tests to fail, which is not
useful. Reduce the warning to a g_message.
This lets us do fallback in case an image format is not
supported, and also lets us provide solid-color images.
We don't support image fragment notations.
See ttps://www.w3.org/TR/css3-images/#image-notation
https://bugzilla.gnome.org/show_bug.cgi?id=761318
Instead of spamming stderr with g_warning, use the new
emit_error method of the GtkStyleProviderPrivate interface
to emit an error if loading an image fails.
Currently, GtkCssProvider can emit ::parsing-error only during
the actual parsing, although the documentation hints that it might
happen at other times.
This commit adds a emit_error method to the GtkStyleProviderPrivate
interface that will let us emit errors from the compute() implementations
as well, which can be useful (e.g. if an image fails to load).
In some situations (no header bar, save mode), hitting Escape
would not do anything because the entry ate the key event.
Fix this by telling the entry to only handle Escape when there
is something to do, such as switching back to the path bar.
https://bugzilla.gnome.org/show_bug.cgi?id=761026
We should not hardcode a scale of 1, this leads to
pixellated upscaled images at scale=2, even if the source
is an svg. By passing the proper scale, we can load the
svg at the correct size.
When creating icon info objects for unthemed files, we don't
really have a nominal size, so we pass 0 to mean 'load at
original size'. However, this is not what was happening.
To make this possible, add variants of some pixbuf loading
functions that take a scale factor instead of a desired size,
and use those when we don't have a nominal size.
Eventually, we should probably remove the examples that rely
on geometry support, since they probably don't work correctly
anymore. For now, just disable the warnings.
Grabbing must stay a bit longer until all other backends than x11/wayland
catch up with GDK DnD, so ignore deprecation flags are used on those. The
uses of GdkDeviceManager can be entirely avoided though.
People might put all sorts of gunk in their .XCompose file, in
the hope that XLib makes sense of it. Even if we don't make sense
of it, we shouldn't abort, but instead ignore the lines we can't
understand. Pointed out in
https://bugzilla.redhat.com/show_bug.cgi?id=1301254
We connect to the titlebar widgets change notification regardless
whether it is internally created or not, so don't make the signal
handler disconnection conditional on that either.
We need to unset the titlebar manually before chaining up
in destroy, otherwise we trigger the template invariant
checking - GtkWindow would eventually unset it, but too late
for the invariants checking code in gtk_widget_destroy.
Presently, Gtk will only send a startup notification completion message
for the first window that is shown. This is not good for the case of
GtkApplication, where we are expected to participate in
startup-notification for all windows.
We have avoided this problem by manually emitting the startup complete
message from after_emit in GtkApplication.
Unfortunately, this causes problems for windows that are shown with a
delay. It is also a dirty hack.
The reason for the original behaviour is simple: there is a static
boolean in gtkwindow.c which controls it. We remove this.
Instead, clear the startup notification ID stored in GDK when sending
the completion message. GtkApplication will re-set this the next time
an event comes in which needs startup-notification handling. In the
non-GtkApplication case, newly shown windows will still not send the
message, since the cookie will have been cleared.
Finally, we remove the hack from GtkApplication's after_emit.
This will probably cause some regressions in terms of lingering startup
notification messages. The correct solution here is to always use
gtk_window_present(), including when merely opening a new document (with
a new tab, for example).
https://bugzilla.gnome.org/show_bug.cgi?id=690791
gtk_editable_get_selection_bounds() returns UTF-8 character offsets,
but gdk_pango_layout_get_clip_region() wants byte ranges, so convert
from one to the other.
With English, this is especially visible for passwords, which use ●
as the invisible character.
https://bugzilla.gnome.org/show_bug.cgi?id=761128
This was a thinko - what we sometimes do for signal names is to
use I_() to intern them (to avoid a strdup), but I_() is not
currently available in gdk, so lets just skip this
microoptimization for now.
When the spinbutton grows larger, distribute horizontal size to the
entry and vertical size to the buttons.
Obviously, horizontal size only matters for horizontal spinbuttons and
vertical for vertical spinbuttons.
The font features demo started calling the Harfbuzz API directly
starting from commit 9de3b24c20. Harfbuzz
is an implicit dependency of Pango on some platforms, but it's not part
of the public dependencies; this means that we cannot expect to link to
Pango and automatically get Harfbuzz symbols to link against —
especially when things like --as-needed are in play.
This change triggered build failures on non-Unix platforms, fixed by
commit 2a9967731a, as well as build
failures in Continuous, with this error message:
/usr/lib/gcc/x86_64-gnomeostree-linux/4.9.3/../../../../x86_64-gnomeostree-linux/bin/ld:
font_features.o: undefined reference to symbol 'hb_tag_to_string'
//lib/libharfbuzz.so.0: error adding symbols: DSO missing from command
line
collect2: error: ld returned 1 exit status
In order to get the font features demo to build everywhere we should
take an explicit, though optional, check on Harfbuzz, and conditionally
build the font features demo with the right compiler and linker flags.
The fonts features demo now uses fontconfig APIs via PangoFT2, which makes
the code not build on non-Linux, so only include this demo in the build
on UNIX.
Add more features to the list, allow selecting script/language
from the set that is supported by the font, indicate which
features are present in the font for the selected script/language,
and expand the default specimen to cover latin, cyrillic and
greek.
It looks like the gnome-continuous headers haven't quite
caught up yet, so try __NR_memfd_create instead.
If that doesn't work, i'll likely just add in a fallback
code path.
The tmpdir is used for a wide assortment of things, and
can easily fill up. If it fills then desktop will start
crashing with SIGBUS errors.
This commit changes the shm pool allocation code, to use
memfd_create, instead, so the shared memory files will
be anonymous and not associated with /tmp
https://bugzilla.gnome.org/show_bug.cgi?id=761095
(1) Keep priv->text_allocation for the area used by the text
(2) Compute all text coordinates with the help of priv->text_allocation
As a side effect the get_text_area_size and get_frame_size vfuncs are
now unused. If we wanted them back, they should get a single use durig
size_allocate() and then their results should be stored for further
processing.
This complicates refactorings, so remove that feature. It's not used
anywhere and doesn't play well with nodes the way it's implemented.
If we want it back, we can add it back later.
Changing the visibility of child widgets in size-allocate does
not work well with out current allocation and layout machinery.
To avoid the visual fallout, just keep the arrow buttons visible
and only change their sensitivity.
https://bugzilla.gnome.org/show_bug.cgi?id=754868
We don't want to let baseline adjustment shift the child
out of the original allocation. This is purely a sanity
measure - in practice, the baseline should always be bigger
than the child_baseline.
We were adjusting the allocation to line up baselines before
calling gtk_widget_size_allocate_with_baseline, but that function
is doing this alignment internally anyway and expects to be given
a 'fill' allocation.
Move the allocation adjustment code down into
gtk_box_gadget_allocate_child where it only affects child gadgets,
not child widgets.
Make the theme follow our documentation for the various .csd and
.ssd style classes: They all go on the window node. For now, just
add the new selector; the old one will be removed when mutter has
been updated.
https://bugzilla.gnome.org/show_bug.cgi?id=760714
When measuring children while distributing a given height,
we must measure them for the given width that goes with
the height. Otherwise, things will go wrong if some of the
children do actual width-for-height. This was showing up
as misaligned images in anaconda.
https://bugzilla.gnome.org/show_bug.cgi?id=760967
The pointer position is queried to properly trigger the prelight
updates on the new row below it. We store the last coordinates
though, and track crossing events to unset these, so it's safe
to just update_prelight() here on these.
Check that non-native window are indeed children of the event window and
only then confirm that they should be drawn.
Fixes Glade thinking that it's okay to have the draw function do
different things depending on what window to draw. (This should really
be fixed in Glade.)
There's no reason to insta-crash when something goes wrong. Just don't
do anything stupid.
Also, remove the SPCIAL_CONTAINER() exception. Every case where special
containers needed this, it is wrong and made containers draw children
multiple times.
The text view draw function was leaving its cairo context
with a transformation after drawing to all the border windows,
which lead mis-drawing in gitg. Avoid this by moving the
gtk_cairo_transform_to_window call inside the existing
cairo_save/restore calls.
https://bugzilla.gnome.org/show_bug.cgi?id=760942
Add a query implementation to opacity property. Also fix the assert in
gtk_css_style_property_register() to allow registering properties with
query but without assign function.
https://bugzilla.gnome.org/show_bug.cgi?id=760933
The build glue for collecting all the assets in Adwaita as
resources was assuming that they are all pngs, and tried to
preprocess them into embedded GdkPixbufs.
Fix it to leave svgs unmolested, so they can be recolored
at runtime.
If we fail to load the image for a -gtk-recolor() expression,
fall back to using the image-missing icon instead of crashing,
and include more details in the warning message.
Previously, we were only showing the size of the allocation
and clip area. But there is no good reason to hide the position
of these rectangles, so add them, in the traditional format
of X geometry strings: wxh+x+y
GtkShortcutsWindow is among the 'cheating' containers that iterate
over indirect children in forall, and this is now triggering
an assertion in gtk_container_propagate_draw.
For now, just exclude the cheating containers from the assertion.
Eventually, this needs a better solution.
create_shm_pool doesn't need the width or height, it just needs
the total size. By passing it in, we're requiring it to redo
stride calculation unnecessarily.
This commit drops the width and height parameters and makes the
function just take the total size directly.
https://bugzilla.gnome.org/show_bug.cgi?id=760897
Right now, we assume the stride for the image surface needs to
be 4 byte aligned. This is, in fact, true, but it's better to
ask cairo for the alignment requirement directly rather than
assume we know the alignment rules.
This commit changes the code to use cairo_format_stride_for_width
to calculate a suitable rowstride for pixman.
https://bugzilla.gnome.org/show_bug.cgi?id=760897
create_shm_pool unlinks the temporary file a little,
too late. It should be unlinked before ftruncate()
is called for two reasons:
1) if ftruncate fails, the file is currently not
getting cleaned up at all
2) in theory, if the file is public some other process
could muck with it
This commit just moves the unlink call a little higher
up.
https://bugzilla.gnome.org/show_bug.cgi?id=760897
Button state was being kept in two separate variables, which lead
to slight confusions in DnD that caused the notebook to ignore the
first click after DnD happened from (within) it. Unify these two
into one, which helps us keep better track of the really pressed
buttons.
gdk_rectangle_union will happily add all the worlds pixels
to the union if the initial rectangle is initialized to all
zeros. Therefore, explicitly check for an empty rectangle
before calling it.
This function does not ignore empty rectangles. Since this
is a fairly subtle point about the behavior, it is worth
spelling this out in the documentation. We've had a bug
open about this for a long time:
https://bugzilla.gnome.org/show_bug.cgi?id=464528
Move code to properly reinsert the tab label to where it belongs.
The if has the distinction between reparented-to-dnd-window and
just-changed-the-gdk-window-to-draw-to right there.
https://bugzilla.gnome.org/show_bug.cgi?id=760754
The new function, gtk_render_background_get_clip answers the
question: what pixels are affected if I call gtk_render_background ?
The long-term goal is to have APIs that answer this question for
all rendering primitives.
Commit 8e975b2 (Bug 753969) introduced check of parent accessibility.
Consequently it is not possible to save file if executable attribute
is not set, which might happen for some gvfs backends. Let's assume
that the folder is accessible even if the attribute is not set.
https://bugzilla.gnome.org/show_bug.cgi?id=760881
The viewport itself doesn't move, so we cannot use it as the pixel
cache's background. Use the bottommost using element instead, which is
the viewport's child.
This might need adaptations in themes as we want the backgroud to be
opaque to speed up pixel cache performance.
Use gtk_box_gadget_reverse_children and gtk_css_node_reverse_children
to flip the children of the header_gadget and the tabs_gadget when
appropriate.
Add new CSS node tests to verify that the node order is updated
as expected in all cases.
These functions will be automatically called by the windowing backend.
The usual hooks to run this from in gtk/ shouldn't even happen, but
it is worth to document which calls are expected and which aren't.
If the grab window is destroyed the grab will be implicitly removed,
although we won't get GdkSeat:ungrab called in order to clear our
internal window<->seat relation entirely. Setting a weak ref will
nullify the pointer we keep on the seat to the window, avoiding the
expected crashes.
Due to implicit grabs, we basically can guarantee that the pointer
won't have any buttons pressed at the time of wl_pointer.enter.
Seems like a good place to unset any button modifiers that might
have been left stale by compositor grabs.
When this is in use, there's essentially a bunch of dead code here.
When all backends are ported, we'll be able to remove grab/cursor
management plus a bunch of source-side event handlers.
This includes managing input events and source-side DND events,
as well as setting the appropriate cursor and emitting the signals
that are expected in this mode of operation.
This function (most similar to gtk_drag_get_cursor() helps figure out
the right cursor that applies to a given action. To be used by the
various backends.
We've traditionally left GTK+ to handle the input side of things,
letting GDK only manage the windowing-specific messaging. This
way of splitting responsibilities is not compatible however with
some backends, we must fold then input management at the DnD stage
into GDK (and backends) domain.
The gdk_drag_context_manage_dnd() call is meant to be the entry
point for this mode of operation, if the drag and drop operation
becomes managed, the caller (i.e. gtkdnd.c) doesn't need to perform
grabs, nor manage input events itself.
As a consequence of this, different aspects now belong to the
backend GdkDragContext implementation:
- Because the caller doesn't see keyboard events anymore,
keyboard navigation must be managed in GDK, so is the decision
of the current action based on modifiers/button pressed.
- Because the caller won't see input events in general, the lifetime
of the drag and drop operation is now communicated through the
::drop-performed, ::dnd-finished and ::cancel events
- Because the caller doesn't participate anymore on the action
being chosen, the pointer cursor must be set by the backend.
The caller is rather notified of the final action through the
::action signal.
The caller is still responsible of dealing with the corresponding
GdkSelection, ensuring its ownership and communicating the supported
mimetypes.
... and remove the also forgotten void function that lingered around
with it.
Fixes opacity=0 parts like inactive spinners or sort indicators in
treeview headers being drawn since last commit.
Oops.
Previously, we had a special cae to draw subwindows of widgets.
This is not necessary as conformant widgets should be able to properly
render themselves when all windows need to be painted.
From now on assume that is the case.
We therefore paint nonnative GDK windows "inline" by just returning TRUE
for gtk_cairo_should_draw_window() for those windows.
This speeds up hilighting different rows in the listbox gtk-demo example
tremendously (by a factor of 10 or more) as the previous code was
O(<number of non-window subwidgets> *
<number of subwindows>) which in the listbox example were ~15,000 and
~2,000 respectively.
When using forall(), only list the revealer, which lists the box
containing all the children. When using foreach(), bypass revealer and
box and list all children added to the box.
Derived classes like GtkSourceView with their own ::key-event
handler need access to this, in order to make their keynav
as nice as the builtin one, wrt to caret visibility.
https://bugzilla.gnome.org/show_bug.cgi?id=760748
And use it to handle kinetic scrolling in the GtkScrolledWindow.
However, dropping the delta check causes the X11-based kinetic
scroll to break since we don't have the stop event here. Correct handling of
xf86-input-libinput-based scroll events is still being discussed.
https://bugzilla.gnome.org/show_bug.cgi?id=756729
This adds support for the new wl_pointer events available in v5.
The wl_pointer.axis_source events can be ignored for the purposes here, the
main reason they exist is so that the combination of axis_source=finger and
axis_stop triggers kinetic scrolling. We don't need to care about the source,
axis_stop is enough for us to tell us when we're scrolling.
The wl_pointer.frame events group events together and is intended as a
mechanism to coalesce events together. This for example allows us to now
send a single GTK scroll event for a diagonal scroll. Previously, the two
wl_pointer.axis events had to be handled separately.
The wl_pointer.axis_discrete event sends mouse wheel clicks where
appropriate, and is translated into up/down/left/right scroll events.
https://bugzilla.gnome.org/show_bug.cgi?id=756729
Since a41f02f9b1, GtkIMContextSimple
uses threads to load X Compose files. It does that every time a new
im context object is initialized, so we can easily end up with multiple
threads accessing the shared global_tables list at the same time.
Use a lock to prevent that.
https://bugzilla.redhat.com/show_bug.cgi?id=1276432
To ensure that the title moves to the other side as expected
in RTL, use GTK_ALIGN_START/END instead of GTK_ALIGN_FILL
when packing the title gadget into the vertical box, and
flip the alignment when the text direction changes.
This is mostly search and replace ala
GtkButton => button
GtkWindow => window
.button => button
or removing style properties that aren't used anymore like
-GtkButton-default-border: 0
Most uses of builtin icons (check and radio buttons,
expanders, etc) are placed next to labels, so they should
be properly positioned wrt to the baseline. Lacking anything
better, give the builtin icons a baseline that places the
center of the icon at the strikethrough position.
The 'mad hack' that GtkAccelLabel used to affect the GtkLabel
draw function broke with the introduction of gadgets, since
the positioning is no longer relative to the widgets' allocation
at the time of the call, but rather to the gadgets allocation.
Instead of coming up with an even madder hack to keep this
working, give the GtkLabel draw function knowledge about accel
labels.
https://bugzilla.gnome.org/show_bug.cgi?id=760663
Previously this setting would just invalidate the whole CSS tree and
thereby hopefully avoid all cache usage.
Now, we actually don't cause extra invalidations anymore, but instead
avoid ever inserting anything into the cache when this setting is set.
This essentially copies the previous cache implementation. With one
caveat: It is now attached to and maintained by the CssNode, not by the
CssStyle.
And this is important because styles may be reused in incompatible
situations which would cause cache collisions and lead to broken CSS in
weird situations.
For now, the split out style cache doesn't cache anything. This is
mostly to make sure that bisections of wrong caching behavior will
bisect down to the commit that actually adds caching.
Use a vertical box gadget for the overall expander, and a
horizontal one for the title row. This lets us get rid of
all the custom allocation code here.
So far, the box gadget is always allocating all children the
full size in the cross axis. This behavior corresponds to the
align-items: stretch behavior in
https://www.w3.org/TR/css-flexbox-1/#align-items-property
This commit implements the other modes described there.
While widgets have halign/valign properties that we can use for
this, the API for inserting gadgets has to change to take an
extra align parameter. All callers have been updated to pass
GTK_ALIGN_FILL, since that corresponds to the previous behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=760668
From gtk_widget_path_iter_set_object_name documentation:
"When set, the object name overrides the object type when matching CSS"
Update gtk_widget_path_to_string to match this behaviour.
This is sometimes needed, and calling into actual icon theme
code just for it is confusing - the resulting icon does not
depend on the icon theme at all.
https://bugzilla.gnome.org/show_bug.cgi?id=760536
This prevents WM from drawing shadows around tooltip windows,
which, in Adwaita, should have no shadow and are CSD-ish (which means
that tooltip window is larger than it looks, and WM draws the shadow
only on the outside, leaving a gap between the visible tooltip edge and
the shadow).
https://bugzilla.gnome.org/show_bug.cgi?id=759898
With Mingw-w64 fstat() can be an inline function that
calls _fstat32() or _fstat64(), depending on some macros.
And if LFS is enabled, fstat() is defined to turn into
_fstat32i64() or _fstat64(). And some/all of the above
might also be macros as well. Side-step all that mess
and excplicitly re-define fstat as _fstat32, which is
guaranteed to use a version of "stat" struct that
has 32-bit size and time fields, which is what we want.
https://bugzilla.gnome.org/show_bug.cgi?id=760615
While rescanning the object tree, we were emitting ::object-selected
signals, possibly causing wild blinking in the application window.
Don't do that.
https://bugzilla.gnome.org/show_bug.cgi?id=760572
Commit 0b96b8a1 set margins via css, but accidentally changed the
semantics of margins for separators in popovers so that any separator
in a gtkpopover had a margin. This meant that the separators in
GtkListBoxes in popovers also had a margin around their separators, and
this is not what we want because it doesn't match separators in
listboxes not in popovers.
https://bugzilla.gnome.org/show_bug.cgi?id=760427
If a GtkGestureSingle is set as touch-only, pointer events would be
discarded without giving an opportunity to the regular GtkGesture
handler to manage those.
Because the pointer events weren't actually managed by the gesture,
gtk_gesture_get_sequence_state() (rather unhelpfully here) will resort
to returning GTK_EVENT_SEQUENCE_NONE, which is in turn interpreted
by _gtk_widget_consumes_motion() as "may be handling the events for
this sequence", because gestures in this state presumably handle
the events, just that it's not "claimed" yet.
Instead, use gtk_gesture_handles_sequence(), which will perform the
expected check on the event sequence being managed, as we expect
here.
When a tab drag starts, we need to move the tab label into the drag
window via gtk_widget_set_parent_window().
If we don't unparent, but just unrealize the widget, we don't lose the
cssnode position.
GtkNotebook does not switch the current page if all pages are hidden. So
it may be that no visible page exsits, but there still is a current
page set.
We culd clear the current page, but I'm unsure about backwards
compatibility.
So instead, this new function handles that case.
This allows reworking the content node to do real height-for-width.
The content node also takes care of border width, but we might want to
have the toplevel do it or just get rid of it.
Deprecate initial-gap, tab-curvature and tab-overlap properties. All
their features can be achieved using CSS.
This CSS achieves the same effect as a 10px initial gap:
notebook header {
margin-left: 10px;
margin-right: 10px;
}
A tab overlap of 10px can be achieved via:
notebook tabs {
margin-left: 10px;
}
notebook tab {
margin-left: -10px;
}
And tab curvature is essentially the same as padding or border on a tab.
We skip sides with 0 border width in render_border, but when
we collect sides with the same style, we may pass the 0 width
down to render_frame_stroke anyway. So skip width 0 sides
there as well.
Instead of taking the border and manually removing it from the
allocation, render our background over all the border allocation box, as
that's more correct and does not take padding into account twice.
The GtkGesturePan behavior of locking onto certain orientations may
come across as confusing, and is not strictly necessary for mice and
other pointing devices.
As GtkGesturePan is also a GtkGestureDrag, we just use the same
callbacks on both gestures.
https://bugzilla.gnome.org/show_bug.cgi?id=759670
When a cursor is specified in gdk_seat_grab(), the cursor is reverted as
soon as the pointer enters or leaves another window.
To avoid this issue, store the grab cursor separately, so we force-apply
it in ::set_window_cursor(). Also, unset early the seat info from the
window on gdk_seat_ungrab(), so the next time switch_to_pointer_grab()
happens we end up picking the cursor set for the window underneath the
pointer window.
Based on a patch by Olivier Fourdan <ofourdan@redhat.com>.
https://bugzilla.gnome.org/show_bug.cgi?id=760213
the vertical padding from the headerbar has been removed, now the
sizing is done with min-height, this avoids title and subtitle
labels making the headbar.
We are getting the mime data destroy notify called when we
destroy the surface in finalize. Trying to set the XSync counters
at this time is a) pointless and b) yielding an X error because
the counters have already been destroyed.
To avoid this, unhook the damage tracking before destroying
the surface.
https://bugzilla.gnome.org/show_bug.cgi?id=760188
We are setting mime data with a destroy notify on the cairo
surface to get notified when cairo registers damage for the
surface (in that case, it clears the mime data, calling the
destroy notify). Unfortunately, the destroy notify is also
called when we remove the mime data ourselves, which was
not intentional.
Use a flag in the window impl struct to ignore the callback
when we are clearing the hook.
The assumption that MIN() takes care of all infinities here
turns out to be wrong. We were getting inf and -nan for some
combinations of 0 width/height and corners, leading to invalid
matrices and cairo errors.
https://bugzilla.gnome.org/show_bug.cgi?id=759668
Instead of creating an intermediate pixbuf, just render
the window surface onto the new surface. Doing things this
way lets us avoid the cairo_surface_mark_dirty() call in
gdk_pixbuf_get_from_window(), which is not generally safe
to call on 'random' surfaces - it asserts that the surface
has no mime data attached, and the X11 backend uses mime
data for damage tracking purposes...
We destroy the widget that is wrapped around the drag window
when the object data on the drag context gets cleared. Destroying
the window before that happens leads to unpleasantries. E.g. we may
try to access the frame clock, which doesn't exist anymore, and
things go downhill from there. So, keep the window alive for
a little longer.
We destroy the widget that is wrapped around the drag window
when the object data on the drag context gets cleared. Destroying
the window before that happens leads to unpleasantries. E.g. we may
try to access the frame clock, which doesn't exist anymore, and
things go downhill from there. So, keep the window alive for
a little longer.
Renaming the files from -dark to -inverse makes it more obvious
that this is not a dark variant in the sense of the 'prefer-dark'
setting, but rather a separate theme (sharing the same CSS).
Replace the cursor-color and secondary-cursor-color style
properties with the caret-color and -gtk-secondary-caret-color
CSS properties.
For the 'auto' value of these properties, we keep the same
behavior that we used to have when the style properties are
not explicitly set.
This property is defined in http://www.w3.org/TR/css3-ui/#caret-color.
We also add a -gtk-secondary-caret-color property, since GTK+ has
supported differently colored split cursors in the past. Unlike
CSS, we don't support the weakly defined auto keyword, and just
use currentColor as the initial value.
X11 has the notions of "transient for group", and while it's an ICCCM
violation, it's commonly used and documented that a window manager
would treat a window with transient_for set to None to transient for all
windows of its group.
gtk uses this when an application sets a dialog type window but does not
specify an explicit transient.
While this works on X11, there is no such thing as groups in Wayland and
the closest equivalent which is set_parent() in xdg-shell takes only one
parent. This is what is used for modal dialogs.
To get something similar in behavior to what is available on X11, a
solution is to update the parent() of the dialogs without transient when
the active surface changes.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=759161
Quite a few applications use GTK_WINDOW_POPUP to create various
temporary windows and place then on screen. That works fine on X11 but
on Wayland there is no global coordinate system for regular surfaces.
If the application is using a gdk temp window and set a parent with
gtk_window_transient_for(), the gdk wayland backend has all it needs to
create a subsurface that can be placed at will by the application.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=759738
If the background is transparent, we can't use it for the input shape,
since that will be empty. Draw a box with rounded corners irectly
instead, in fully opaque black.
https://bugzilla.gnome.org/show_bug.cgi?id=759905
I misunderstood what the overlay is good for: We need to allocate
it the full size of the widget. since we are using it to render
a background gradient *over* the application-rendered color.
At the same time, save some 100 lines of code by using an icon
helper as gadget, instead of handling the icon manually.
gtk_render_content_path is expecting the full box dimensions,
not just the content area. So, add the border before calling it.
Note it is still possible to have some separation between the
color and the border, by setting padding.
Recent gettext has a feature to allow consumer projects to supply their
own string extraction rules for XML files, in ITS format.
Gettext still ships the rule for *.ui, but it would be better
maintained in the upstream project.
https://bugzilla.gnome.org/show_bug.cgi?id=760202
Transitioning between linear gradients like
linear-gradient(to top, yellow, green) and
linear-gradient(to left, yellow, green) was yielding
nonsensical results, with the gradient line jumping around
wildly. Fix this by falling back to stupid image interpolation
for these cases.
Always returning a left_ptr if we can't find anything better
broke firefox application-specific fallback for missing cursors.
Keep that working by only doing the fallback for the CSS cursor
names, not for things like hashes.
https://bugzilla.gnome.org/show_bug.cgi?id=760141
Always returning a left_ptr if we can't find anything better
broke firefox application-specific fallback for missing cursors.
Keep that working by only doing the fallback for the CSS cursor
names, not for things like hashes.
https://bugzilla.gnome.org/show_bug.cgi?id=760141
This tests that horizontal boxes flip their child nodes
according to text direction to maintain the left-to-right
ordering of child nodes for both text directions.
CSS nodes have a linear sibling relationship; this is supposed
to correspond to left-to-right placement in horizontal arrangements.
This commit explicitly sets the text direction to rtl if the
filename ends in .rtl.ui, so we can test differences in node
tree layout between text directions.
Follow the generally white background we use everywhere else.
This is not perfect, we get double borders when the search bar
is shown, as can be seen in gtk3-widget-factory.
Gadgets don't connect to style-changed for widget nodes, and
GtkImage uses its widget node for the icon helper. The visible
effect of this is that symbolic icons don't change color when
switching to the dark variant of Adwaita.
Fix this by manually invalidating the icon helper.
Instead of the weird PathElt struct, generate a quick-n-dirty parser
that parses CSS selectors into GtkWidgetPath elements.
Based on a patch by Benjamin Otte.
In https://bugzilla.gnome.org/show_bug.cgi?id=601425 the annotations
were changed to int as they not only take the predefined enum values
but also user defined values registered through gtk_icon_size_register()
As a result the typelib doesn't contain any information about
GtkIconSize for those arguments and the Python docstring only
shows the corresponding Python type "int".
This changes the argument docs to mention the type explicitly
so the Python doc generator can add a link to Gtk.IconSize
which contains the most useful predefined values.
https://bugzilla.gnome.org/show_bug.cgi?id=757411
The Visual Studio versions that we support supports locking functions in
their CRT, so support that to optimize things a bit. Also update the
config.h.win32.in so that its entries are more in line with the ones in
the autootols builds, and make sure that we use UNIX line endings.
Use a custom, empty theme and stop importing reset-to-defaults.css.
This avoids overwriting initial values, so our initial value
filtering works better.
Drop the custom style printing implementation in gtkcssnode.c and
instead reuse the existing gtk_css_style_print function, extending
it a bit to suit our needs.
Instead of computing values, just recognize initial values by
having no CSS section. Also do away with the show-initial flag, and
just always filter out initial values. The flag can come back when
it is needed.
The node declaration has all the information we are printing
here (except for visibility). At the same time, redo the format
to print the information in selector format, and indicate
(in)visibility by enclosing the selector in square brackets.
The previous way of manually juggling the visibility of the
labels doesn't work anymore, now that gadgets of invisible
widgets don't allocate space anymore.
This uses the same function for dumping CSS nodes and styles
as the CSS node test. It can be used to test aspects of inheritance
and matching, as well as initial values.
No actual tests yet.
Add a gtk_style_context_to_string function that can serialize
a CSS node or tree of nodes, optionally including CSS properties
as well.
This will be useful in writing tests.
It turns out we don't really need to use a separate gadget for the
infobar, if all we do is chaining up to the parent GtkBox which already
uses a gadget.
Just remove all the boilerplate.
The notion of a separator being wide or not does not make sense when a
theme can set any CSS property on it, and
separator-width/separator-height are on their way out for
min-width/min-height.
Instead, just rely on the CSS gadget; we can stop using wide-separators,
separator-height and separator-width, and at the same time deprecate the
space-size style property of GtkToolbar.
67ab00e01e removed the fake configure code in gtk_window_show() and
replaced it with a simple gtk_widget_realize(). The initial allocation
code in realize() only allocates the natural size or the last requested
size which now no longer is set, resulting in a too small first allocation.
This builds a configure request to compute the allocation size instead
which includes default size, CSD etc..
This problem could be seen in case of a GtkPaned in a GtkWindow with a
default size set and the pane position set as well. The first allocation
would be the natural size of the GtkPaned which would clamp the pane
position if too larg. Only the second allocation would fill the parent
window using the now wrong pane position.
https://bugzilla.gnome.org/show_bug.cgi?id=759705
In that case, code expects an arrow gadget to be present but we're not
creating it in every occurrence.
Fix it by ensuring there will be an arrow gadget when reserve_indicator
is TRUE.
GtkViewport currently tries to draw a background over the bin window.
The feature is a bit broken at the moment, as it does not take into
account padding that might have been set on the GtkViewport, but in
general it does not seem very useful, and goes somewhat against the CSS
box model where every widget/gadget is responsible to draw its own
background. For a fix, we could either have the viewport gain a "bin"
gadget, or we could stop drawing the background.
As it isn't clear that there are any users of this feature, stop drawing
the background; a client can achieve the same effect by drawing the
background on the widget inside the viewport itself.
As GtkCssNode has the visibility concept, it makes sense to mirror it in
gadgets.
Do what visibility does in widgets: Hidden gadgets can't be drawn or
allocated and request a 0x0 size.
Note that just like widgets, gadget visibility must not be changed in
size request, allocate or draw handlers.
GtkWidget::child-visible has no equivalent yet, code will have to
emulate that manually.
Previously, the ID was only set on the CSS node as a side-effect
of calling gtk_widget_get_style_context. This was showing up
in CSS style tests as nodes lacking their IDs.
The test needs to be updated for the renamed :dnd pseudo class.
We also need to add a .errors file for the deprecation errors
that we are now producing.
Putting the deprecated class behind the official variant does
not work for the case of :focus and :focused - we were matching
:focus and leave a dangling 'ed'. So, put the deprecated classes
before the official variant, and explicitly mark them as deprecated.
Split the CSS docs off from the GtkCssProvider docs and
give them their own chapter. Among other things, this commit
introduces more or less complete definitions of the syntax for
the supported selectors, a complete list of all supported
properties, and definitions for their values. This includes
documentation for GTK+-specific properties such as -gtk-icon-source.
I hadn't noticed the :drop() pseudo state in the CSS4 Selectors
spec when I added this a while ago. This commit renames
GTK_STATE_FLAG_DND to GTK_STATE_FLAG_DROP_ACTIVE and adds
:drop(active) as equivalent to the :dnd pseudo state.
We don't actually do anything when the label is not selectable
except for consuming the event, which breaks for instance titlebar
drags with labels that contain links. Simply deny the gesture in
that case to allow the event to bubble up normally.
https://bugzilla.gnome.org/show_bug.cgi?id=759798
... on older Visual Studio versions, where isinf() is not available, and
copy the isinf() implementation from gdk/fallback-c89.c to
gtk/fallback-c89.c.
gdk_widget_get_frame_clock can return NULL. In particular,
this can happen when the drag window is destroyed at the end
of a DND operation. Handle this gracefully when it happens.
This adds tests for animation-name, animation-duration,
animation-timing-function, animation-iteration-count,
animation-direction, animation-play-state, animation-delay
and animation-fill-mode.
we have to do some assumptions for css selectors limits for this
particular case, so for split headerbars to work correctly the
actual haderbars need not to have the titlebar class applied.
The gtk_builtin_icon_get_default_size_property returns a const char *,
in a way such that some compilers insist that something that is of a
pointer value be returned, so fix that by replacing 0 with NULL.
When clicking "Cancel" on the "Do you want to use GTK+ Inspector?"
dialog, unregister the update_debugging idle handler. Also, steal
reference to 'inspector_window' while gtk_destroy_widget(), to make
further gtk_window_update_debugging() calls as a no-op.
https://bugzilla.gnome.org/show_bug.cgi?id=759764
The GetSize callback *can* assume that minimum and natural are
non-NULL. Buy minimum_baseline and natural_baseline can and
will be NULL, so handle that. This was causing crashes e.g. in
pavucontrol.
applications with split headerbars has a container in the titlebar
slot so the .titlebar style there needs to be reset. Since we can't
go backward with selectors I assumed that any csd application
sports a headerbar hence relying on that styling and resetting
the .titlebar styleclass.
Move the gtk_css_gadget_allocate call before the
gtk_label_update_layout_width call. This fixes the
statusbar label in widget-factory page 2 coming
up fully ellipsized.
Transient nodes should not propagate style-changed signals
that can cause widgets to get reallocated. This was causing
treeviews and iconviews with pixbuf cells to be constantly
resized and redrawn.
Clearing the icon doesn't appear to be necessary with
todays code, and it has the unfortunate side-effect of
temoorarily hiding the icon's window, which breaks grabs
and makes us miss the button release event when the icon
is changed from a button press handler.
We're going to add back the original struct definition removed by
a6e4de28, because using the typedef breaks all sorts of things like
gtkmm and WebKit, and having separate struct definitions allows us to
change the types in GdkBorder from gint16s to gints without breaking
ABI.
Functions requiring CoInitialize are called just in two places:
- the filechooser thread which calls its own CoInitializeEx
- the dnd code
Moving CoInitialize in the dnd specific init is cleaner and
we can pair it with the corresponding CoUninitialize since
CoUninitialize should be called as many times as CoInitialize.
Note that it is ok to call this function multiple times, so it
will not break if another codepath will need it in the future.
The patch also replaces the deprecated CoInitialize with the
equivalent call to CoInitializeEx (already used in the filechooser).
Empty boxes end up setting the clip to { 0, 0, 0, 0}, so warning
for a width or height of 0 triggers false positives. Instead,
initialize the clip to clearly invalid values.
As part of this conversion, remove the hardcoded padding around
the label.
Unfortunately, we cannot use the main gadget for drawing the frame
decoration, since we want to draw a custom border instead of the
stock css border that gadgets insist on drawing for us. Therefore,
add an extra gadget with name border and use it just for rendering
the frame.
Otherwise the gtk_grab_remove() calls on widget destruction will happen
on the default window group, which may leave the real window group
of the popover with a dangling pointer if it is not the default one.
This could be seen on the inspector, open a popover in the properties
list and close the window with alt-F4.
Invisible nodes don't change the first/last-child status of the nodes
after/before them. That means we don't have to just check the state of
the adjacent node when modifying this state, but all their siblings
until we hit a visible node.
The same way, a node is not the first child if it has no previous
sibling, it is the first child if it has no previous visible sibling.
This is important for caching in the global lookup cache.
CSS min-width and min-height on the slider node fit this
perfectly. We still fall back to the slider-width and
slider-height style properties if the CSS properties are
not set.
In most places, we can do with the pointer/keyboard of the default seat
instead of the client pointer. We can also remove some code from
gdk_input_init() because we know for sure there's no floating devices to
care about here.
There's places where we still need to deal with floating devices, which are
unseen by seats. Ignore deprecations and keep using GdkDeviceManager until
we can forget about floating devices.
There's places where we still need to deal with floating devices, which are
unseen by seats. Ignore deprecations and keep using GdkDeviceManager until
we can forget about floating devices.
There's places where we still need to deal with floating devices, which are
unseen by seats. Ignore deprecations and keep using GdkDeviceManager until
we can forget about floating devices.
There's places where we don't set a seat yet, plus the places
outside GTK+ where events are created, we should warn and fall
back to the master device seat with these.
1e1064398c broke the build.
When I run make, I should make sure to run it in the right directory.
And not in the gtk/ subdirectory that will never build widget-factory...
The clipboard emit events after the button we connected it to was
already destroyed (on application close for example), so make sure we
don't try to use that dead button.
Gdk Wayland backend walks up the transient windows tree, but does not
check for cycles when doing so.
As a result, if two or more windows are transient to each other, the
Wayland gdk backend will enter an infinite loop.
While this is clearly a bug in the application, gtk+/gdk should be more
robust and handle such errors more gracefully.
To avoid looping infinitely at various point in the code, check for a
possible loop when setting the transient relationship and deny the
request to set a window transient for another if that would create a
loop.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=759299
gdk_pixbuf_get_from_window() paints the given window onto a new cairo
surface. Create that new surface with the same device scale as the
window so that the result is not scaled down on hidpi screens.
This is similar to 657a43e (which was reverted), but doesn't modify the
behavior of gdk_pixbuf_get_from_surface().
https://bugzilla.gnome.org/show_bug.cgi?id=757147
When doing a gtk_widget_show_all() on the shortcuts window,
accelerators for both RTL and LTR directions are being shown.
Make sure that no-show-all is set by default on hidden shortcuts, and
updated if the widget direction changes.
https://bugzilla.gnome.org/show_bug.cgi?id=759541
This was causing problems in the case when only one of the paned
children is visible - we would use uninitialized memory, leading
to invalide clip regions. Concretely, the signal tab in the inspector
would sometimes not render at all.
Make min-width/height have preference over the set default size. This
allows shrinking the widget. The default size is only used if min-width
is not set (or explicitly set to 0.
Drop the margin misuse and use the border allocation of the
handle gadget. We use negative margins to make the border allocation
larger without pushing the paned children out.
Size of the progress element now grows also when it's close to 0 size.
Previously the size was clamped to the minimum size, now it starts
growing from the minimum size.
So for a 100px trough with a 10px min size progress, the sizes of the
progress element change like this:
old new
0% 10 10
5% 10 14
10% 10 19
20% 20 28
50% 50 55
100% 100 100
Our actions on ::device-removed only actually applied to master
pointers, so listening to GdkDisplay::seat-removed and operating
on the seat pointer is equivalent.
We were not supporting plural form of the available space, which
is a problem in some languages.
However in this case is kind of a difficult matter, since we use a
formatted string from glib with g_format_size.
To fix it, use the same behavior as g_format_size to decide when
it should be used a plural form or not.
https://bugzilla.gnome.org/show_bug.cgi?id=759491
gtk_css_node_insert_before/after can easily create cycles
which later lead to stack overflows. Even if we're not
catching all cycles here, at least we can detect obviously
invalid arguments, such as inserting a node next to itself.
This was already mostly done by inheritance from GtkCheckButton.
To complete it, stop using the draw_indicator vfunc for radio
buttons, and instead make the indicator gadget draw either a
check or radio.
Use a gadget for the button, and for the indicator.
A complication here is that GtkCheckButton (and
GtkRadioButton) have a totally different appearance
depending on the ::draw-indicator property. If an
indicator is not required, we just reuse the
GtkButton gadget.
This mostly works; some minor sizing issues left, e.g. cranking
up the indicator-size causes the checkbutton grid in testgtk
to overlap.
This removes some hairy code handling with borders and padding,
which may or may not be correct. The examples in testheightforwidth
all continue to work, and min-width now works for labels.
This gives us min-width/height support. Currently, the spinner
still has a hardcoded minimum size of 16 and doesn't grow beyond
32. We may want to revisit that at some point.
When things change in the iconhelper, queue a resize on the owner widget
so that it automatically resizes.
Only do this for iconhelpers that are used as gadgets though, not for
temporary helpers - and to check this, check if the node is transient.
A gadget is halfway between a widget and a CSS node. It's supposed to
provide the minimum convenicence around CSS nodes until we've figured
out how to integrate them with widgets.
Build the gtk-update-icon-cache, gtk-builder-tool and gtk-query-settings
tools and run gtk-update-icon-cache as part of the post-build
"installation" process.
Pointed out (and reminded) by Paolo Borelli in bug 759436 that we should
build, "install" and run gtk-update-icon-cache in the MSVC builds as well.
Constructing GtkCssStyleChange objects without styles is forbidden, so
don't do it. Instead untangle the callback from the actual update
function and call that untangled function directly.
When we reuse styles that didn't change across changes to the source
CSS, make sure we clear the caches. Otherwise child nodes will pick up
styles from the old source CSS.
We no longer need a grabbed seat, instead we'll just use the default
seat if this happens, not without first warning and recommending
gdk_seat_grab() for the operation.
https://bugzilla.gnome.org/show_bug.cgi?id=759309
This allows GDK to unset the grab itself. Also, make sure we unset
the "pointer emulating" touch on the device if this is the
pointer emulating sequence.
https://bugzilla.gnome.org/show_bug.cgi?id=759309
GdkWaylandDeviceData conceptually gathers the data that belongs to
a seat, so it's been renamed (although the old typedef stays, plenty
of refactoring is due here...).
The methods in GdkSeatClass have also been implemented, the most
remarkable is ::grab, which ensures the grab is performed on all
the relevant "master" devices.
https://bugzilla.gnome.org/show_bug.cgi?id=759309
On some systems, the gtk settings are not used properly for wayland.
Indeed, g_settings_schema_source_get_default is used, and as the docs says it,
"all lookups performed against the default source should probably be done
recursively.".
https://bugzilla.gnome.org/show_bug.cgi?id=759409
Remove some now unused includes and dead code, and rename
gtk_drag_set_icon_window to gtk_drag_set_icon_widget_internal,
since it is no longer restricted to toplevel windows.
Under Wayland, the compositor does it, so there is no need
for us to move the window ourselves. For X11, we are now
doing the animation from the X11 backend. Trigger that by
calling gdk_drag_drop_done().
What changes here is that we have to keep the icon_window
alive for as long as the drag context exists. Use a weak
reference to do so.
Showing the drag cancel animation can be done in the X11
drag context implementation now that we hold the drag
window there, and have the start coordinates.
Since we can't control if and when the application destroys
the drag widget, we take a snapshot of the window contents
and display that during the animation. This should be good
enough for all practical purposes.
Add a variant of gdk_drag_begin that takes the start position
in addition to the device. All backend implementation have been
updated to accept (and ignore) the new arguments.
Subsequent commits will make use of the data in some backends.
In commit 2c61316677 we avoided emitting
the style-changed signal if no CSS property changed.
Unfortunately, this also caused CSS styles to not be updated when
animations started if those animations did not change any CSS value
immediately. In those cases the animation would just never start.
The obvious example was the spinner.
Catch the case where a CSS style did not change and don't emit the
style-changed signal in that case.
This saves not only the emission of the signal, but also doesn't cause
invalidation in child nodes, which would previously get a PARENT_STYLE
Instead of having old and new style, now have a GtkCssStyleChange opaque
object that will compute the changes you are interested in for you.
This simplifies change signal handlers quite a bit and avoids lots of
repeated computation in every signal handler.
We were only storing the dialog size on unmap, but resetting to the
stored default value more often, e.g. on focus-out. This was causing
the dialog to 'jump back' to its remembered size after the user
manually resized it, leading to frustration and bug reports.
Instead, save the dialog size on every ::size-allocate of the toplevel.
To avoid needlessly spamming dconf, only write the new value if it
changed.
In Wayland, the hotspot of a DND icon is set using the buffer offset in
wl_buffer.attach. To implement this, add a private API to cause the
next wl_surface.attach to offset the new buffer with a given offset.
Setting a DND icon hotspot sets this offset while also queuing a redraw
of the window to trigger the wl_surface.attach.
https://bugzilla.gnome.org/show_bug.cgi?id=759168
...in the process simplified the touch-selection styling, check
and radios not fixed there since I'm going to add proper osd assets
for those (istead of forcing the dark variant assets there as before).
The name gtk_text_*_begins_* was used only for begins_tag(). All other
similar functions use "starts": starts_line(), starts_word(), etc.
So for consistency, add gtk_text_iter_starts_tag() and deprecate
gtk_text_iter_begins_tag().
Also change (allow-none) to (nullable), to use the new annotation.
https://bugzilla.gnome.org/show_bug.cgi?id=759092
In Wayland, the hotspot of a DND icon is set using the buffer offset in
wl_buffer.attach. To implement this, add a private API to cause the
next wl_surface.attach to offset the new buffer with a given offset.
Setting a DND icon hotspot sets this offset while also queuing a redraw
of the window to trigger the wl_surface.attach.
https://bugzilla.gnome.org/show_bug.cgi?id=759168
Otherwise rounding errors fool the "tab under coordinates" checks on
crossing events, which will be triggered close enough to the window
rectangle if the pointer moves slowly enough.
With this, the tab_prelight() function correctly figures out we've
moved the pointer outside the tab area when called in
gtk_notebook_leave_notify().
https://bugzilla.gnome.org/show_bug.cgi?id=759091
After removal of the selectable header and separator from the combo box,
the method to update the menu sensitivity must be changed as it assumes
at least two items within each sub menu and contains special handling
for the separator. Removing this fixes bug #759079.
Since we're no longer doing geometry widgets, don't send
base size and increments to the window manager anymore either.
This avoids an ugly 2 pixel gap to the right and bottom of half-tiled
terminals under gnome-shell.
We were getting the "New Accelerator" text mixed with the
content of the underlying cell, since plain labels don't
have a background. Go back to putting the label in selected
state, and fix the theme to render that white-on-blue. This
was lost when we switched to using a selection sub-node.
Showing two lists in a paned was a bit awkward, and space was
getting too limited. Go back to showing just the node list at
first, and make the CSS properties available via a stack. At
the same time, add a right-click context menu to the node list
to make the name and class editing more easily available.
The gesture functionality was taken over by GtkShortcutsShortcut,
so this widget is no longer needed, and it never was in a stable
release, so lets get rid of it.
GtkFontChooserWidget is using a GThemedIcon in its template,
so we need to ensure that the type is registered before
loading it. This was causing the defaultvalue test to fail.
GtkStatusIcon tests don't work well under xwayland either, so just
skip them unconditionally.
GtkEntry now fails because the update of the im-module is no longer
deferred to an idle, and (gtk-im-simple) is not a valid module
name, so skip this property.
The subscript was affecting the vertical alignment too much,
so tweak the rendering of the L/R markers to avoid that. Also,
mark these as translatable.
Instead of creating an icon source, making sure no state is set and
therefore the icon-effect will be applied and then rendering that icon
source, just call the icon-effect apply function.
Also, the new way isn't deprecated.
On Wayland, for tooltips to work as expected, the type hint must be set
to tooltips, otherwise the popup window won't be translated as a
subsurface.
Fix the test do work as expected under Wayland.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=759018
In Gdk, a GdkOffscreenWindow parent has to be the root window. This is
problematic on Wayland because the root window doesn't necessary have the
right information with regard to scale factor.
This patch proposes to rely on the embedder, if available, to derive
surfaces as well as getting the scale factor.
https://bugzilla.gnome.org/show_bug.cgi?id=758936
Applying the client-side decorations in the configure routine greatly
increases the chances of having the right size for the GtkHEaderBar and
border shadows.
Yet, it may be possible that these sizes change at a later point in
time, if for example the GtkHeaderBar grows in height while adding new
controls.
Mention this possible pitfall in the documentation for
gtk_window_resize().
https://bugzilla.gnome.org/show_bug.cgi?id=756618
The entry code passes GTK_DEST_DEFAULT_HIGHLIGHT when setting
up the drop target, but that is ineffective because of the
custom drag_motion implementation. Instead, call
gtk_drag_[un]hightlight ourselves.
This borrows heavily from the CSS4 fonts draft's font-palette, currently
found at https://drafts.csswg.org/css-fonts-4/#font-palette-control
The palette is mainly meant to trigger invalidations when colors used for
symbolic icons change, to potentially allow extending supported colors
in symbolic icons and to recolor all colors of a symbolic icon, not just
the main one.
The syntax for the property goes like this:
Name: -gtk-icon-palette
Value: default | name <color> [ , name <color> ]*
Initial: default
Applies to: all elements with icons
Inherited: yes
Animatable: yes, each color animated separately
The property defines a list of named colors to be used when looking up
icons. If a name is not defined, the value of the current "color"
property is used. Which names are relevant depends on the icons in use.
Currently symbolic icons make use of the names "success", "warning" and
"error".
"default" is the current behavior of the GTK when coloring symbolic
icons and is equal to the string
success @success_color, warning @warning_color, error @error_color
Animation is crudely implemented by animating colors that are in both
palettes that are animated and otherwise keeping the color from the
palette that defined it. Note that this can cause a sharp cut at the
beginning or end of the animation when the color goes away and will
therefore be replaced with the color property.
You can see an example of animations at
http://gfycat.com/CautiousPeacefulIaerismetalmark
When we start a drag cancel animation, we can just keep the existing
window. The reset was only necessary to convert from cursor icon to
window and we removed the cursor handling.
Just like we did for the default size, that reduces the chances of
having the headerbar missing or wrongly sized when computing the client
side decorations controls.
https://bugzilla.gnome.org/show_bug.cgi?id=756618
The Wayland dnd surface must remain in place until the drag
is over. Setting it directly as the hardcoded window of the
widget we construct carries the danger that it might get
destroyed prematurely, e.g. when the application calls
gtk_drag_set_icon_name more than once and we recreate the
widget.
Instead, create a dedicated toplevel, and reparent the widget
into it. To keep the code simple, we use the same approach
under X11 as well, and make it the responsibility of the
GDK dnd code to keep the window position updated. We already
pass the current pointer position to gdk_drag_motion, which
makes this very easy.
As a side-effect of these changes, it is now possible to use
non-toplevel widgets as drag icons.
https://bugzilla.gnome.org/show_bug.cgi?id=748763
If that sounds confusing, it's because GTK and CSS can sometimes not
agree on naming.
:active for CSS means that a button is currently pressed on an element.
And that is clearly not the case for spinning spinners.
This removes the dependency on state, which should be used for selection
CSS styles, not for actually applying them.
And image-effect does exactly what we want already, so we can start
using it.
The size of icons is a property that is relevant to who is rendering the
icon, not to the icon itself.
Example: Starting a DND operation from an entry icon should cause the
icon to resize (from the entr icon's size to the DND icon size).
Make gtk_icon_helper_ensure_surface() a private function that just
ensures the surface was loaded.
Add gtk_icon_helper_load_surface() that is called by the above function
and the dnd code to actually load the surface.
Just do the invalidation check once, there's no need to do it in every
branch of the switch.
Also remove useless checks: These functions will not be called if we
already have a rendered surface.
Just do the invalidation check once, there's no need to do it in every
branch of the switch.
Also remove useless checks: These functions will not be called if we
already have a rendered surface.
It seems this branch is not needed anymore. It was originally added in
1999 to support gtk_widget_realize(), but all those reasons seem
obsolete today.
Instead just call gtk_widget_realize().
If you end up at this commit when bisecting:
There is no bug that made me remove this code, it was purely meant to be
cleanup / dead code removal. I seem to have introduced a new bug or
bisecting wouldn't have let you here. So it seems we should just revert
this commit.
Under X11, popovers are always constrained to the toplevel
window. Under Wayland, they aren't. This commit adds a
property that allows to explicitly constrain popovers to
the toplevel, giving them the same behavior under Wayland
as under X11.
https://bugzilla.gnome.org/show_bug.cgi?id=757474
Widgets such as gtkfilechooser may be saving their size and position on
the unmap callback, if the client-side decoration header bar is removed
first, the reported size will be wrong.
https://bugzilla.gnome.org/show_bug.cgi?id=756618
gdk-wayland backend would not re-configure a surface when its size and
scale match the known size and scale.
But there might be a pending xdg_surface_configure() that would revert
this change so we should re-configure even if the currently known
size/scale match, otherwise we may end up with a wrong size after the
xdg_surface_configure() is received.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=758901
If we "release" the button first, the drag will be eventually cancelled,
we must first signal GDK_DROP_FINISHED, and then release the button so
the success status prevails.
It doesn't make a lot of sense to have this stored as data offer data,
rather together with the source_targets array, which is what we're
poking here in the end.
https://bugzilla.gnome.org/show_bug.cgi?id=758713
Dissociate ownership from our maintenance of wl_data_source objects.
The only place where ownership must be updated together is
data_source.cancelled, for the other places GDK should take care of
setting up the right ownership, even if at a different order than
we'd expect here.
This fixes GTK+ apps on wayland being locally confused about the
current selection ownership. Because gtk_selection_add_targets()
results in a wl_data_source being created, and ownership being
updated right away, early callers of this will change the ownership
even if the widget it's being called on didn't explicitly request
the selection ownership yet.
https://bugzilla.gnome.org/show_bug.cgi?id=758660
'win.lines' contains the same content as the GtkTextBuffer, so to find
@match_start, forward_chars_with_skipping() is called with
skip_decomp=FALSE (the last parameter). So far so good.
On the other hand, the content 'lines' (the needle split in lines) is
casefolded and normalized for a case insensitive search. So,
forward_chars_with_skipping(..., skip_decomp=TRUE) must be called only
for the portion of text containing the needle.
Since 'start_tmp' contains the location at the start of the match, we
can simply begin at that location to find the end of the match.
Unit tests are added.
https://bugzilla.gnome.org/show_bug.cgi?id=758698
Doing things the other way around seems to cause problems in
some cases where children want to do different things depending
on the window position.
https://bugzilla.gnome.org/show_bug.cgi?id=758563
Instead of just listing the return type of get_plus_button() and
get_minus_button() in the documentation, we can use the (type)
annotation to ensure that the introspection data reflects the actual
type of the returned widget.
Fix a regression introduced by:
commit 6866d1c widget: Make gtk_widget_queue_allocate() not resize
Where the dropdown menu in Firefox would not be relocated after the
toplevel window is moved.
bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=758609
While searching for the cause of bug 746745 it was discovered that one could
not set WS_EX_TOPMOST extended window style with SetWindowLong(),
but must use SetWindowPos() for that purpose.
This was never a problem most likely because it is highly unlikely for windows
to acquire/lose WS_EX_TOPMOST after they are created, by means other
than SetWindowPos() (which GTK does use to raise/lower windows and
set/remove keep_above), and because trying to set/unset WS_EX_TOPMOST with
SetWindowLong() results in WS_EX_TOPMOST merely not being set/unset (that is,
other styles are still set/unset within the same call and no error is
signalled).
https://bugzilla.gnome.org/show_bug.cgi?id=758483
Instead of having our own copy of the pointer gestures XML file, use
the one installed by wayland-protocols.
Since pointer gestures is an unstable protocol, it went through the
unstable protocol naming convention changes, which is reflected in this
commit.
https://bugzilla.gnome.org/show_bug.cgi?id=758634
Just like it happens for window dragging, we're likely to not see the
matching button release for this event, so we must reset the controller
manually here.
https://bugzilla.gnome.org/show_bug.cgi?id=758661
Before calling gdk_window_move_resize(), store the full configure
request, not just width and height.
Fixes firefox randomly losing position of its dropdown windows.
https://bugzilla.gnome.org/show_bug.cgi?id=758609
After the grab is finished, we would expect an enter event, and
GDK updating internally the cursor for that window and device.
This means there is no need at all to store it separately in the
backend.
As a side effect, animated cursors are now also possible on grab
icons.
https://bugzilla.gnome.org/show_bug.cgi?id=735847
The way master devices detach from their other master counterpart is
vulnerable to infinite recursion due to the way we first recurse on
the other device before clearing the pointer, this may happen if
that last reference to the other master device is held by the
device->associated field.
https://bugzilla.gnome.org/show_bug.cgi?id=732742
Other backends take care of the cairo surface destruction in
GdkWindow::destroy. We must do the same here, or the cairo_surface
and its corresponding wl_buffer are left dangling.
https://bugzilla.gnome.org/show_bug.cgi?id=747295
tracker:uri-is-descendant/parent has the unfortunate side effect of
rendering the collation mechanisms in the database useless, so those
require full table scans to be validated.
Performing these as pure string comparisons will perform much better,
as those allow the underlying sqlite to rely on its own collation
to perform the search, which can be significantly faster with many
elements in the database.
https://bugzilla.gnome.org/show_bug.cgi?id=758407
It turns out that it is nicer in glade to have just a single
widget that can show either a shortcut or a gesture, so make
GtkShortcutsShortcut do it both.
GtkShortcutsGesture is now redundant and will be removed before
the next stable release.
The current code in gtkshortcutswindow.c is good enough to
construct a widget once from a .ui file, but fails to handle
changes at runtime, as happen e.g. in glade. Fix this by
listening for changes to section-name and title.
This prevents normal application windows (and other kinds of windows)
from being moved up in Z-order to be above windows that have the
always-on-top bit set. Doing so would make the previously-normal windows
in question also always-on-top implicitly.
Windows that are already always-on-top will be restacked on top of other
always-on-top windows too.
https://bugzilla.gnome.org/show_bug.cgi?id=746745
Empty underlines are hard to make out. Since we get somewhat
unreliable section information from the CSS parser, we just
make sure that we always underline at least one character.
The builder syntax for tags was invalid here (why did this not
get flagged as error ?!). While we're at it, give the warning
underline a nice, orange color.
If the buffer of a cursor is NULL, for example if its an empty cursor,
just set the cursor surface to NULL as well. Not doing this we'll use
uninitialized hotspot coordinates, dimensions and scales.
https://bugzilla.gnome.org/show_bug.cgi?id=758025
We can't use up_panel and down_panel as differentiators for the buttons,
because these window system resources don't exist before realize().
Just use a one-off enum for this purpose.
https://bugzilla.gnome.org/show_bug.cgi?id=758094
This GdkDragContext should be created even if we don't have pointer
capabilities. Make it created on add_seat(), and only set the device
on wl_seat.capabilities, so it can be set to either master pointer.
https://bugzilla.gnome.org/show_bug.cgi?id=741066
This is wrong by all accounts there, as we can do no tricks there to show
a "drag failed" animation, which is performed by the compositor itself
on wayland.
We use the high-level gdk_device_get_window_at_position() to figure
out the window, although this one actually tries to find out the
current window under the device coordinates, which might well fall
outside the window, so NULL is returned in those cases.
Fix this by using the lower level _gdk_device_window_at_position()
that will return the toplevel without further lookups, so is more
desirable here.
https://bugzilla.gnome.org/show_bug.cgi?id=758250
Now that we have multiple master pointers, this call may pick the wrong one.
Instead, pick the GdkWaylandDeviceData from the first device, and pick the
master pointer from there.
The common GDK code accounts for "pointer emulating" touch sequences to be
synchronized with the pointer position by the windowing system.
However on Wayland pointer and touch are completely independent, the backend
attempts to implement pointer emulation, but doesn't account for the
possible crossing events happening when the user switches from pointer to
touch or the opposite.
In order to fix this, and to ensure we don't have to interact with the
master pointer (which backs the wl_pointer), separate the touch interface
to have its own master pointer, and ensure crossing events are emitted on
it, so the picture of an "emulated pointer" is complete above the backend.
Inspired in a former patch by Jonny Lamb <jonnylamb@gnome.org>
https://bugzilla.gnome.org/show_bug.cgi?id=750845
The window button setup depends on properties of the toplevel window.
Instead of updating the setup on realize, do it when the toplevel
changes.
This makes sure that when a GtkHeaderBar is added to a window
all the widgets are present and get_preferred_height() will return
the height the widget will have when finally shown. This allows
the logic in gtkwindow to select the right window size so that
the content size will match the requested default size.
https://bugzilla.gnome.org/show_bug.cgi?id=756618
Before the resulting window size would differ if the default size was set
before adding a headerbar vs after. Now the saved state is again the actual
requested size and it is adjusted at the time we request a window size.
https://bugzilla.gnome.org/show_bug.cgi?id=756618
GtkHeaderBar will not show the maximize button if the window in not of
type normal or not resizeable.
Use the same restriction for double-click actions as well.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=757530
Currently GtkStack has some G_PARAM_CONSTRUCT properties. That means,
the properties are set with its default value after the initializacion
of the object.
When using GtkBuilder to build objects, GtkBuilder creates them and
after that sets the properties found on the xml definition.
However, this is not true for templates because the template is initialized
in the init() function of the actual object, and after that, the construct
properties will be set.
This is a problem when someone wants to use templates with GtkStack and
set those properties, since they will be set on the tempalt initialization
and set again to its default values afterwards.
To fix this, make those properties not G_PARAM_CONSTRUCT.
https://bugzilla.gnome.org/show_bug.cgi?id=758086
There is no GNU Lesser General Public License version 2; it's either GNU
Library General Public License version 2, or GNU Lesser General Public
License version 2.1.
Copy-pasta from GPL instead of LGPL.
Also, there is no GNU Lesser General Public License version 2; either
it's the GNU Library General Public License version 2, or it's the GNU
Lesser General Public License version 2.1.
If the window has not yet been created, then we can't set the invisible
cursor yet. This can happen in situations where the widget is in a
revealer with type-to-search functionality.
An application may use gtk_window_get_size() to retrieve the current
window size and later reuse that size with
gtk_window_set_default_size().
gtk_window_set_default_size() and gtk_window_get_default_size() should
also take client side decorations offset into account.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=756618
We were using that range for the extra buttons after left/right/middle,
while this is harmless for clients not handling extra buttons (we
used to translate those button events into scroll events in x11 anyway)
this will be unexpected for clients that do handle additional mouse
buttons themselves (eg. back/forward buttons present in some mice).
In order to remain compatible with X11, those need to be assigned from
button 8 onwards.
Also, include input.h, and stop using magic numbers here.
https://bugzilla.gnome.org/show_bug.cgi?id=758072
Commit 1266d15c4 also broke Xwayland, as it does the same trick
than VMWare pointers. Let's extend the heuristic to check for "pointer"
in the device name, what can possibly go wrong...
https://bugzilla.gnome.org/show_bug.cgi?id=757358
We currently just look for a master device with input source MOUSE.
After recent changes to the way input devices are classified, xwayland
on my system comes up with a virtual core pointer that has input
source TOUCHSCREEN. This was causing assertion failures. Be a little
more careful and accept a touchscreen as core pointer, if there is
no mouse.
Use G_PARAM_DEPRECATED with deprecated style properties.
This will make it easier to identify and remove such stale
properties from css, since it will now trigger warnings.
When loading a nonexisting CSS file using
gtk_css_provider_load_from_file() or gtk_css_provider_load_from_path()
we would emit the error using a NULL scanner. Don't do that, because
we'll have a NULL section in that case and error handlers don't like
that.
Testcase attached.
https://bugzilla.redhat.com/show_bug.cgi?id=1277959
VMWare seems to create mouse devices with abs axes which confuses
our detection of single-touch touchscreens. Those have though a
name we can match on ("VirtualPS/2 VMware VMMouse"), it should
be pretty safe to assume that no real touchscreens have "mouse"
in their name...
https://bugzilla.gnome.org/show_bug.cgi?id=757358
The prime example for direction-dependent shortcuts is using
<Alt>Left or <Alt>Right to go back. Support this by adding a
direction property to GtkShortcutsShortcut, and filtering by
the current text direction.
https://bugzilla.gnome.org/show_bug.cgi?id=757888
Getting the shadow width must not call gtk_style_context_set_state()
because that will invalidate the node and cause a style-updated emission
which can cause gtk_widget_queue_resize() calls.
And calling queue_resize() from get_preferred_size() essentially means
the size is permanently invalid because you invalidate it while
querying it.
This causes flickering of windows when going from/to backdrop state. To
avoid this we either need to fix the theme to not have different shadow
sizes in those cases or we need to ensure the window doesn't flicker in
the first place.
Only use the hard-coded build-time path given by X11_PREFIX on X11 and
Wayland where a X11 package is normally available. On other platforms,
get the datadir of the running system and mimic the behavior by
constructing the path dynamically. This avoids hardcoding the path for
searching for compose tables where we want to have relocatability.
This fixes the build on Windows/MSVC as well, where we don't normally have
any X11 packages available.
https://bugzilla.gnome.org/show_bug.cgi?id=757984
Since we are now interpreting button press events and
make our own double-click determination, we should not
handle double-click events that are generated by GDK.
https://bugzilla.gnome.org/show_bug.cgi?id=757950
A follow up on the previous patch. We should use DestroyWindow
directly since it has a different calling convention than
the expected callback for g_clear_pointer
Adapt to the changes in the previous commit. In particular, fix
the handling of low and high offsets. Anything below the low offset
gets warning color, anything below high gets selected background,
and anything below the new full offset gets success color.
Avoid crashes when passing an invalid location to a
gtk_text_buffer_get_iter_at_*() function.
A first attempt added boolean return values to know if @iter has been set to
the exact location, but it breaks Python and JS bindings because the out
parameter is already a return value in those languages.
Unit tests are added.
https://bugzilla.gnome.org/show_bug.cgi?id=735341
This reverts commit a9a1c00cc9.
Unfortunately, adding the boolean return broke both the python
and javascript bindings, since they now return a tuple consisting
of the boolean and the out argument.
glib-compile-resources have been updated to ensure that the symbols
generated are referred to, so that they will not be optimized out by the
linker in release builds. We can change from /opt:noref to /opt:ref,
which should improve optimization a bit.
This partially reverts de16a4e.
As we now ensure that items using GResources and GConstructors are always
referenced so that the linker does not optimize them out in a default
Release build, we no longer need to enforce the use of /LTCG, so
/LTCG:incremental will work as well.
Its very easy to get extra references to the NativeDialog so that
when you release your last reference any visible dialog is not
hidden. We handle this by adding a destroy method similar to how
you destroy regular toplevels.
It's not a hugely complicated file, but it's easier to deal with some of
the details of tooltip windows styling if we have a UI file to edit,
instead of source code.
Use the text CSS node for rendering text, and the selection node
for rendering selected text, avoid gtk_style_context_save, update
states of all CSS nodes, and use the proper states when querying
style properties.
Use a CSS node with name selection, like we do for entries
and labels. Unlike those widgets, we currently don't user
gtk_render_background, but just use the background color.
That will require more effort.
Calling gtk_render_background for each rectangle in the region
leads to suboptimal and sometimes weird results. Getting this
right requires more work in Pango first. Go back to just rendering
a single background, and clip it to the selection region. This
matches what GtkLabel does.
At the time gtk_window_move() or gtk_window_resize() get called, there
is no way to predict if a popup window will actually draw its shadow, so
applying an offset in this case may end up with a wrong size or
positioning for such windows.
Changing the logic in gtk_window_should_use_csd() as previously done to
address that issue will cause some other breakage as popup windows may
not draw a shadow but still need CSD.
So best is to actually apply client side decorations offset for regular,
top level windows only. This is actually a lot simpler and safer and
less likely to cause additional breakage.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=756618
Adapt to the changes in the previous commit. Note that tooltip
appearance is currently affected by tooltips having lost their
csd nature, due to a regression.
* Cover letter
Having a single header file for all autocleanups definitions was a
reasonable stop-gap measure, but now GTK+ is starting to use G_DECLARE_*
macros. This means that every class using a G_DECLARE_* macro will need
to include "gtk.h" to avoid compiler warnings, which is not acceptable.
By moving the G_DEFINE_AUTO* use to the header that defines the type we
allow using the G_DECLARE_* macros without sacrificing the ability to
include only the needed files when deriving from a class.
* Commit
This commit changes all includes relative to GtkWindow to define their
own autocleanup macros.
When I added the draw_layer vfunc it accidentally got passed a cairo_t
that was configured with to draw in the viewport coordinate space (rather
than the buffer coordinate space). This makes things unnecessary complex,
because you have to convert between the two.
The pixel cache is shared between the text and the layers, so there is
no way to use draw_layer to get a stationary overlay effect. Thus it makes
much more sense for the draw_layer vfunc to draw in the buffer space.
Just changing this would break ABI for existing code, so this is fixed
by adding new layer types and deprecating the old ones.
Also, we use the new layer types to fix gtk3-widget-factory.
https://bugzilla.gnome.org/show_bug.cgi?id=757856
When moving/scrolling a child window we can't use the current clip
region to limit what is invalidated, because there may be a pixel
cache that listens for changes outside the clip region. Instead
invalidate the entire area and rely on the invalidation code to limit
the repaint to the actually visible area.
git commit a5b1cdd0 introduced a regression where CSD windows are not
resizable with metacity.
Reason being that metacity does not support "_GTK_FRAME_EXTENTS" and
therefore gtk_window_supports_client_shadow() would always return FALSE.
This explains why it works with window managers which support
"_GTK_FRAME_EXTENTS" such as mutter/gnome-shell or xfwm4.
Partially revert commit a5b1cdd0 to reinstate the logic in
get_shadow_width().
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=757805
It is not necessary for the users of this API, and causes things
to not work as intended. Without this transient node, styling
"notebook header tabs arrow" has the desired effect on notebook
arrows.
We were just catching the previous sibling before. Now we properly
invalidate all previous siblings (and also all other wiblings, but we
can think about optimizing that later).
Adapt to the new CSS nodes for trough rendering. This commit
also brings back visible fill-level rendering for scales, which
was not working for a while. The styling provided for that
(scale trough fill) is just a placeholder to aid in debugging
the implementation.
For now, always warn when
gtk_style_context_get()/get_padding()/get_margin()/get_border()
get called with the wrong state.
We used to hide this behind an env var because the warnings were
too frequent, but with the recent refactorings, this warning has become
rather important for detecting bugs.
If it's still problematic, we might want to revert this patch before
3.20.
This is a base class that essentially mirrors GtkDialog, but
it is not a GtkWindow, as the actual implemetation will be using
native code.
The base class has show and hide vfuncs, as well as a helper function
to run the dialog in a modal fashion.
This will be later used by the native file chooser dialog.
Before all GtkFileChooser implementations had to be a GtkWidget,
but we want to introduce one for native implementations that
is not a widget.
This is technically an ABI break, because some code could rely
on the guarantee that GtkFileChoosers are GtkWidgets and do
unchecked GtkWidget calls. However, that does seem unlikely,
and this has not really been documented anywhere.
The introduction of the trough node was not properly carried
into the code constructing stepper nodes, and was causing
assertion failures there. This was only showing up on Windows,
since Adwaita and HighContrast don't have steppers.
We were not queuing a draw (and not updating the CSS node) when
the slider visibility changed. This was exposed by the Trough
button in tests/testscale.
Fix this by taking slider visibility into account when deciding
whether to queue a draw in response to adjustment changes.
We only allocate a size to the currently visible child, so we obviously
need to rerun allocation when the visible child changes.
In the case where the stack is not homogenous, we also need to queue a
resize because our size request just changed.
Using lookup_icon() and lookup_by_gicon() with a size multiplied by a
scaling factor is almost certainly going to get worse results than using
their for_scale() variants.
A GdkPixbuf has no scaling factor, so drawing directly from it can only
using a scale of 1, to avoid blurry, fuzzy icons.
You should be using gtk_render_icon_surface() anyway.
We've by now disabled and then remved all of the tests that use these
functions because they never worked properly. So let's depecate these
functions before somebody starts using them.
It looks like the param spec for interpolate-size was
copied from the line above it, which is a read only property.
There is a setter for interpolate-size, and it is implemented in
set_property().
When setting the parent of a widget, queue_resize() on the widget will
be optimized away if the widget already had a resize queued.
Plus, we do not need to resize the widget as its size request is not
going to change.
This makes sure that hidden widgets always have priv->alloc_needed set
on them.
The constructor sets that flag, so we want to have it back when we
revert to this state.
This fixes GtkWindow skipping a size_allocate() when reshowing a
previously hidden window and thereby not updating its allocation and
clip. And that in turn would lead to draws not happening and us beig
left with a black window.
There was still style context saving in the draw function,
and the CSS node was not always properly updated and positioned.
Fix these things, and use the same CSS node for the arrow
drawing as well.
Similar to buttons-in-toolbars, it can make sense for listbox rows
to not take away the focus from the main application view, for
instance when used for navigation. Support this by taking the newly
added GtkWidget:focus-on-click property into account.
https://bugzilla.gnome.org/show_bug.cgi?id=757269
The differences between the existing properties and the newly added
GtkWidget:focus-on-click property are minimal (different owner_type
in GParamSpec), so it is extremely unlikely that dropping the former
would break anything.
https://bugzilla.gnome.org/show_bug.cgi?id=757269
There are currently three widget that implement such a property, and
there are other widgets for which the behavior can make sense. It
seems like a good time to add the property to GtkWidget itself so
subclasses can choose to respect it without adding their own property.
https://bugzilla.gnome.org/show_bug.cgi?id=757269
The list of popovers will specify the stacking order, a
_gtk_window_raise_popover() private call has been added so popover
widgets can request being on top.
Also, the stacking on popovers is ensured on gtk_window_size_allocate(),
after the size/stacking changes on the child widget have finished, this
will ensure popovers are kept on top of window contents.
https://bugzilla.gnome.org/show_bug.cgi?id=756670
Those won't have ABS_MT_* axes, so won't be reported has having
XITouchClassInfo. Fallback on these to checking whether abs x/y axes are
available. After the Wacom checks, any remaining device with absolute axes
should be touchscreens, and GDK_SOURCE_MOUSE does indeed just make sense on
devices with relative axes.
https://bugzilla.gnome.org/show_bug.cgi?id=757358
Previous commit 305b34a "GtkWindow: fix move/get position with CSD"
introduced a regression because some windows presumably use shadows but
actually don't, resulting in a negative offset being wrongly applied.
Problem is that get_shadow_width() would return non-zero shadows even
for windows that have no shadow, thus causing the negative offset.
Fix the logic in get_shadow_width() and gtk_window_should_use_csd() so
that get_shadow_width() returns accurate values.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=756618
Use the element name menuitem for GtkMenuItem, GtkCheckMenuItem
and GtkRadioMenuItem. GtkSeparatorMenuItem gets the name separator.
Add a subnode with name arrow if a submenu is attached.
Give the radio and check menu items a subnode with name check or
radio.
Use the element name menu for the main node, and use two subnodes
with name arrow and style classes .top and .bottom for the arrows
of scrolling menus.
GtkMenu and GtkMenuBar, the two implementations of GtkMenuShell in GTK,
already draw it.
Furthermore, rendering a background here will overdraw any rendering
that the subclass will do, such as arrows for scrolling menus.
This is kind of a hack the way it's implemented, but it's necessary
for performance to ignore transient nodes as they get created all the
time (via gtk_style_context_save()) and invalidate the whole treeview.
And that causes resizes and redrawing of the treeview and performance of
the inspector would go down the drain now that we display a larger part
of the node tree.
Use combobox as the element name for the main CSS nodes of
GtkComboBox and GtkComboBoxText. Add the .combo style class
to the button and entry. in a GtkComboBox or GtkComboBoxText.
Unfortunately, GtkFileChooserButton is different from the other
pickers in that it is not a button, but rather has a button.
We ignore the difference for styling purposes, and just add
a .file style class to the button.
When the CSS style of a node changes, we want to display the new values
in the inspector.
This for example allows to see how styles update on hover or during
animations.
Instead of handling WM_DISPLAYCHANGE on every GdkWindow, only handle
it on an ad-hoc hidden window we create when opening the display.
This has two reasons:
1) we want emit the display::size-changed signal even if there are no
gtk windows currently open
2) we want to emit the signal just once and not once for every window
https://bugzilla.gnome.org/show_bug.cgi?id=757324
Use a .activatable style class on the color swatch and tie the
hover effect to it. The color editor simply removes this class
now to get an inert color swatch.
This is more flexible and lets us avoid referring to the
GtkColorEditor type in the theme.
Adapt to the new element names in the previous commit.
This also adds back a selected state which gets used
for when the focus is placed on the separator with F8,
just so this functionality is not forgotten.
The current situation is somewhat sad, with the path
label totally misaligned throughout the rows.
This is fixed by using a size group for the path labels,
so they all have the same allocated size (with the max
of 15 chars). Also, instead of hiding the eject button,
set it child-invisible, so it is hidden and yet it's size
is allocated by GtkBox.
https://bugzilla.gnome.org/show_bug.cgi?id=757303
Follow the same approach as used for the toggle button family:
Keep the button element name for button-like rendering, and
use a distinct modelbutton name otherwise, and add a subnode
for the indicator with name check or radio.
Convert GtkToggleButton and its subclasses to CSS nodes.
Keep the button element name for when we want to render
these button-like (but with .toggle, .check and .radio
style classes for differentiation).
When we want to render them with an indicator, use distinct
element names checkbutton and radiobutton, and add a subnode
for the indicator with name check or radio.
Mirror the behavior of gtk_widget_queue_resize() and always queue a
redraw. If we ever want to cause allocates without redraws we can add
gtk_widget_queue_allocate_no_redraw() then.
I had initially assumed gtk_widget_size_allocate() would take care of
queueing redraws, but it does not do that when neither size nor position
change. And that is obviously what's happening after
gtk_widget_queue_allocate().
Fixes buttons sometimes not redrawing (the record button in
widget-factory after locking it, all buttons when switching to the dark
theme).
We have to remove the page itself from the intermediate box
first, before removing the box from the notebook. Otherwise,
reffing the page to keep it alive is ineffective: the box
gets destroyed, and that destruction recurses over the page.
This fixes the problem in
https://bugzilla.gnome.org/show_bug.cgi?id=756385
This commit creates entry and button subnodes for the buttons
in GtkSpinButton. The nodes are ordered like this for horizontal
spinbutton
+ entry
+ image.left
+ image.right
+ progress
+ button.down
+ button.up
and like this for vertical ones:
spinbutton
+ button.down
+ entry
+ button.up
This arrangement requires cooperation from GtkEntry to place
the entry subnodes correctly, and some small changes in the theme.
This commit also fixes progress rendering in vertical spin buttons.
When gtk_widget_show() or gtk_widget_hide() is called, don't queue a
resize on the widget itself but on the parent.
The widget itself may already be marked as in need of a resize and
the call would be optimized out and never reach the parent.
The parent size will change though because a child widget just changed
its visibility.
Fixes a bunch of issues with menus appearing black, toolbas not hiding
in widget-factory and also various reftests.
This commit toggles the big switch. We now don't run size_allocate()
from the toplevel up anymore in cases where we don't need to.
Things might be broken in subtle ways as a result of this commit. We'll
have to find them and fix them.
Widgets that already have a resize queued don't need to walk the whole
parent chain and queue another resize. It's enough to do it once per
resize.
This also means that sizegroups cannot use the shortcut of just
invalidating the first widget in the group anymore. That widget might
already have a resize queued while others don't.
This happens way too much, so it's disabled unless GTK_DEBUG=geometry is
on.
Also, we can't detect it in the call to queue_resize() yet, only during
size_allocate(), so the warning comes after the signal emission.
... and API to set and unset it.
It is set when gtk_widget_queue_resize() is called.
It is unset when gtk_widget_get_preferred_width/height() is called.
So far it is not used.
Before this commit, a widget tree like this:
Window
AnyContainer (part of SizeGroup1)
GtkClutterEmbed
SomeWidget
when calling gtk_widget_queue_resize(SomeWidget), would invalidate
SizeGroup1, when it should have stopped at the GtkClutterEmbed (which is
a RESIZE_IMMEDIATE child).
This is so widgets can queue a rerun of their allocation logic, but
without triggering resizes everywhere.
For now, it just calls gtk_widget_queue_resize().
Ignore the geometry widget passed to gtk_window_set_geometry_hints().
Usind the widget itself was a hack that complicates the size request
machinery.
It is also incorrect in that it doesn't respect height-for-width.
Last but not least, it was only used by gnome-terminal and that
application can easily work without it.
And remove the API to set that variable.
If you want the entry to not fill its whole allocated area,
gtk_widget_set_valign (entry, GTK_ALIGN_FILL);
will give you the old behavior.
Make sure the wayland backend sets a new geometry when the client
resizes itself, otherwise the compositor won't be notified and may
revert to the old size on state changes.
Thanks to Jasper St. Pierre <jstpierre@mecheye.net> who pointed out the
problem in gtk+.
bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=755051
When printing a "compound selector", make sure the name and universal
selectors are printed at the beginning and class, id, etc. selectors are
printed last.
If the svg pixbuf loader is not available, we end up with criticals
from gtk_css_image_icon_theme_draw because gtk_icon_info_load_symbolic
returns NULL without setting an error.
Avoid this by propagating the load error.
gdk_pixbuf_get_from_window() paints the given window onto a new cairo
surface. Create that new surface with the same device scale as the
window so that the result is not scaled down on hidpi screens.
https://bugzilla.gnome.org/show_bug.cgi?id=757147
Sadly, interned string properties cannot be handled generically
at all - GObject insists on inserting a strcpy in any attempt
to set a string property with generic api, destroying the
internedness of the string.
Therefore, we have to special-case GtkCssNode in the property
editor code :-(
This changes widget paths for widgets with a CSS name to return that CSS
name, now that we have added API for it.
This means that style properties are now matches using the CSS name.
Also fix the theme to use the correct name when matching style properties.
... and gtk_widget_path_iter_get_object_name(). This allows applications
that still use widget paths to use the new object names to get the
correct styling.
Mutter and webkit-gtk are examples here.
The search window of a tree view was implemented by showing without
making it visible by by positioning it outside the screen edge. This is
not possible on Wayland, so implement another method for being able to
enter text into a non-visible entry.
The new method is implemented by, before showing the window, pass the
key event directly to the IM context backing the entry. If the key
event triggered the context to commit new text or change the preedit
content, the search window is shown, and from that point the key events
are forwarded directly to the entry widget.
https://bugzilla.gnome.org/show_bug.cgi?id=756780
If a GtkMenu (or something else that is mapped as a xdg_popup) tries to
use a subsurface window as a parent, it will be terminated by the
compositor due to protocol violation. So to avoid this, if a parent
window is not a xdg_popup or xdg_surface, i.e. a wl_subsurface, then
traverse up the transient parents until we find the right popup parent.
https://bugzilla.gnome.org/show_bug.cgi?id=756780
Take into account and compensate for the size of the client side
decorations widgets in gtk_window_move() and gtk_window_get_pos()
including gravity.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=756618
When client side decoration is used, the size passed to
gtk_window_resize() or retrieved from gtk_window_get_size() for top-
level windows also accounts for the client side decorations widgets
such as the title bar or the shadow borders.
Add up the size of these additional controls to the given size to get
the size expected.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=756618
It makes sense that you should be able to type numbers that are
correctly formatted and parsable according to the current locale,
using just the keypad. This patch makes it so by translating
GDK_KEY_KP_Decimal to the decimal separator for the current locale,
instead of hardcoding a '.'.
https://bugzilla.gnome.org/show_bug.cgi?id=756751
gdkcursor-quartz.c uses the instancetype keyword, which doesn't seem to
be supported in the version of Objective C that Snow Leopard uses.
Replacing that keyword with the thing it represents makes it build.
Patch by Ryan Hendrickson,
http://bugzilla.gnome.org/show_bug.cgi?id=756770
gtk_inspector_object_tree_find_object accesses the type information
of the object, so we can't safely use it on an already decaying
object when we get a weak notify. Instead just walk the tree and
compare pointers, that is safe.
https://bugzilla.gnome.org/show_bug.cgi?id=756852
Create css nodes for icons in entries, with name image, and use
gtk_style_context_save_to_node() for them. We still set the
style classes .left and .right on them.
MSVC 2015 changed its default link-time code generation setting to
/LTCG:incremental, which causes problems if /opt:noref is to be used,
meaning that some code will be optimized out by the linker.
Avoid this situtation here by enforcing the use of /LTCG for MSVC 2010+
builds.
Use the new element names instead of the type name and style
classes.
Note that there is one problem with moving away from type names
here: it turns out that style properties only work if the selector
uses the type name.
See the previous commit for why this is necessary.
Also make gtk_widget_class_set_css_name work by looking at
the correct class for the name.
Note for future reference: GTK_WIDGET_GET_CLASS() does not
work in the instance init function.
The widget path machinery assumes that we always have types,
and without this change, it will start spewing warnings when
we start to introduce node names.
A GtkWindow's allocation includes the titlebar, borders, and shadows; we
only want to draw our custom alpha content over the child allocation of
the GtkWindow.
https://bugzilla.gnome.org/show_bug.cgi?id=756886
If a window is decorated, we need to draw the frame and shadow, even if
it is app-paintable - it's just nonsense to have a frame that we handle
events on, but expect the app to paint it. (We paint the titlebar in
any case.) If a client wants to handle all painting, it should use an
undecorated window.
https://bugzilla.gnome.org/show_bug.cgi?id=756886
This commit add some more keyboard shortcuts to gtk3-widget-factory,
and adds a help overlay documenting them. This examle uses the
automatic resource loading support in GtkApplication.
When the $(resource_prefix)/gtk/help-overlay.ui resource exists,
load a GtkShortcutsWindow from it for each GtkApplicationWindow,
and set up a win.show-help-overlay action with accels <Primary>F1
and <Primary>? to show it.
Tooltips tend to be placed on top of a parent surface with a given
relative coordinate, and without any input focus. So lets map them as
subsurfaces.
https://bugzilla.gnome.org/show_bug.cgi?id=756496
Restructure the mapping procedure so that its known up front what the
expected way mapping is to be done (subsurface, popup or stand alone),
and warn if it fails to actually map in such a way (for example a popup
without a parent or device grab, a tooltip without a parent).
https://bugzilla.gnome.org/show_bug.cgi?id=756496
This is a variable holding a ref to an object, so it is
a great case to use g_set_object and g_clear_object.
# Please enter the commit message for your changes. Lines starting
Use CHILD1/CHILD2 instead of 0 and 1, always use the same order and
don't check for child NULL-ness, because it will be done in
gtk_paned_set_child_visible anyways.
Avoid crashes when passing an invalid location to a
gtk_text_buffer_get_iter_at_*() function.
A boolean is returned to know if @iter has been set to the exact
location.
Unit tests are added.
https://bugzilla.gnome.org/show_bug.cgi?id=735341
When the search entry is shown, the 'special' nature of
., ~ and / should not trigger the location entry, because
that interrupts the search and is likely not what the
user intended.
https://bugzilla.gnome.org/show_bug.cgi?id=756505
Disclosure triangles are usually used pointing down, however
in this case the popover spawns in the upper direction, which
makes it odd looking.
Instead of pointing always down or up, point down when not toggled and
animate a rotation when toggled.
https://bugzilla.gnome.org/show_bug.cgi?id=756568
Since the change to use GtkPlacesView we don't want to show
internal storage on the sidebar.
In our case we were checking for drive_can_eject and
drive_is_media_removable.
However for some external hard drives it's reported that they
are not ejectable nor the have removable media. So the only
attribute that they have different from internal drives is that
they can be stopped.
So check for if the drive can be stopped to decide if it is
external or internal.
On the way realized we don't need to check for the mounts associated
with the volume to know if the volume can be ejected or not. So remove
that code.
https://bugzilla.gnome.org/show_bug.cgi?id=756589
It is assumed that border.top is the same than pointing_to.height (which
equals the strong cursor position), which is not since some time ago.
The border calculation has been move on top too, it is now used in the
Y position one, and doesn't depend on anything we calculate later.
Text handles are subsurfaces on wayland, so sort of their own toplevel.
This made gtk_widget_translate_coordinates() to bail out there, resulting
in text handles being mispositioned and jumpy. To fix this, translate to
toplevel GtkWindow coordinates manually, and translate coordinates from
there.
Along the way, the coordinates reported in ::handle-dragged have been
fixed so there is no small jumps in either axis (most noticeable in the
X axis when you started dragging, and in the Y axis when moving between
lines of different heights.
Make it what it is - the enum - so that that it is sure that the hint
will fit in the field. Without this, any hint that doesn't fit in 3
bits will be truncated to the 3 least significant bits, causing
unexpected behaviour.
https://bugzilla.gnome.org/show_bug.cgi?id=756496
Using a NULL GAppInfo with g_app_launch_context_get_display() will
generate a critical warning in gio.
Use the display name instead as we don't have any valid GAppInfo to pass
to g_app_launch_context_get_display().
bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=756439
Otherwise the popopver will be automatically unmapped in
_gtk_popover_update_child_visible() when the X axis (coming more
or less directly from events) goes outside the textview.
GDK_NOTIFY_ANCESTOR would happen when the pointer crosses across a direct
parent/child. However nonlinear events are more likely, specially when
the pointer moves across toplevels (either different apps, or menus being
popped up over the pointer position).
This makes popping up comboboxes and other menus that fall over the pointer
position possible. With the previous detail the GtkMenu code misinterpreted
the crossing event, making it think the button release coming right after
should dismiss the popup, which made menus just flash on the screen unless
you kept the button pressed.
Use $(GlibEtcInstallRoot) when invoking glib-compile-schemas, as CopyDir
is not GlibInstallRoot for GTK+ (due to quoting issues), meaning that the
glib-compile-schemas tool may not be found in certain cases.
Issue pointed out by Ignacio Casal Quinteiro.
we used to consider every button inside osd containers linked,
this is not true anymore, now those buttons behave normally.
This will clearly cause breakage in applications.
According to http://datatracker.ietf.org/doc/rfc2911/, The 'name'
attribute syntax is essentially the same as 'text', including the
REQUIRED support of UTF-8 except that the sequence of characters
is limited so that its encoded form MUST NOT exceed 255 (MAX) octets.
CUPS will not print jobs with names exceeding 255 characters.
https://bugzilla.gnome.org/show_bug.cgi?id=755988
Passing GTK_ICON_LOOKUP_GENERIC_FALLBACK to the icon lookup doesn't work
for GIcons, so we have to make sure we use the right GThemedIcon.
Fixes image-icon-name-use-fallback reftest.
After figuring out what the actual problem is, name the reftest
properly.
The actual problem is that the use-fallback property is ignored when
using an icon-name on GtkImage.
Fallback seems to be working in the GtkIconTheme test suite, but fails
in GtkImage itself.
This is a test for a bug in the Bluetooth settings. An icon named
"phone-apple-iphone" should fallback to "phone" if the
gnome-icon-theme-extras package isn't installed.
If the shared context is in legacy mode, or if the creation of a core
profile context failed, we fall back to an EGL context in compatibility
mode.
Since we're relying on a fairly new EGL implementation for Wayland, we
don't fall back to the older EGL API, and instead we always require the
EGL_KHR_create_context extension.
https://bugzilla.gnome.org/show_bug.cgi?id=756142
If GLX has support for the GLX_ARB_create_context_profile extension,
then we use the GLX_CONTEXT_COMPATIBILITY_PROFILE_BIT_ARB; if it does
not, we fall back to the old glXCreateNewContext() API.
We use the shared GdkGLContext to decide whether the GLX context should
use the legacy bit or not.
https://bugzilla.gnome.org/show_bug.cgi?id=756142
If we're using modern GLSL, then we should stop using deprecated
modifiers, like 'varying' and 'attribute', as well as deprecated global
variables, like 'gl_FragColor'.
On the other hand, with legacy contexts we should be using older GLSL
shaders, to maximize compatibility.
https://bugzilla.gnome.org/show_bug.cgi?id=756142
We want to have the ability to fall back to legacy GL contexts when
creating them. In order to do so, we need to store the legacy bit on the
GdkGLContext, as well as being able to query it.
Setting the legacy bit from outside GDK is not possible; we cannot
create GL contexts in 3.2 core profile *and* compatibility modes at the
same time, and if we allowed users to select the legacy mode themselves,
it would break the creation of the GdkWindow's paint GL context.
What we do allow is falling back to legacy GL context if the platform
does not support 3.2 core profiles — for instance, on older GPUs or
inside virtualized environments.
We are also going to use the legacy bit internally, to choose which GL
API we can use when drawing GL content.
https://bugzilla.gnome.org/show_bug.cgi?id=756142
If the last tag toggle is the end iter, the function returned the wrong
tag toggle.
This resulted in some bugs where the view wasn't relayout/redrawn
correctly.
The function also always returned TRUE, probably because the return
value is used nowhere. But for consistency with
_gtk_text_btree_get_iter_at_first_toggle(), it's better to keep the
return value, and also because otherwise the function would be wrong (it
doesn't always return a tag toggle, if there is none).
https://bugzilla.gnome.org/show_bug.cgi?id=755413
keyboard_handle_leave() might be called with a NULL surface resource
(for example if the surface was destroyed after the event was sent). If
so, we should still deal with the keyboard focus lost event, otherwise
we will both leak (the keyboard_focus GdkWindow reference) and miss
stopping the key repeat timer.
https://bugzilla.gnome.org/show_bug.cgi?id=755927
_gtk_accessibility_init() only gets called if the default
display changes, but in case gdk_init() is called before gtk_init()
the default display is already set and no property notification occurs.
This can happen quite easily in pygobject where
"from gi.repository import Gdk, Gtk"
will call gdk_init() followed by gtk_init() in the Python overrides.
This fixes it by checking for a default display in all cases.
Removing pages from the assistant with gtk_widget_destroy() used
to work. It broke with the recent interposition of a box between
each page and the notebook. Fix this by cleaning up when the box
child is removed.
https://bugzilla.gnome.org/show_bug.cgi?id=756042
In fact there were two issues:
1. GtkFlowBoxChild with "can-focus"==FALSE should pass the focus
to its child immediately.
2. GtkFlowBox with "can-focus"==FALSE should cease its custom keynav
implementation and fall back to the default GtkContainer behavior
which is more natural.
Thanks to these changes the flow box can act as a better replacement
for GtkGrid and similar containers.
https://bugzilla.gnome.org/show_bug.cgi?id=753371
Replace checking if the NSView is really a GdkWindow, which will crash
in the likely event it's not a GObject, with ensuring that the parent
GdkWindow is really a GdkWindowQuartz.
Move focus to list when search results appear to make it
possible to select the first search result by just hitting
Enter. To keep this from interfering with keynav, we need
to make sure that we still handle Escape to search. And when
search comes up empty, we need to move the focus back to the
entry.
https://bugzilla.gnome.org/show_bug.cgi?id=755926
The stack calls gtk_widget_grab_focus on the last focus widget,
which selects the text in the entry, so we need to make sure to
move the focus there first to keep that from happening.
https://bugzilla.gnome.org/show_bug.cgi?id=755931
Once a window is maximized/fullscreen, resize increments should be
ignored otherwise the window may appear smaller than the screen size.
That also applies to configure requests as well.
https://bugzilla.gnome.org/show_bug.cgi?id=751368
We were calling gtk_container_should_propagate_draw
twice for each child. We can avoid this by splitting
out an gtk_container_propagate_draw_internal function.
Almost all callers of _gtk_widget_draw already did their own
cairo_save/restore, so drop the save/restore calls inside
_gtk_widget_draw and instead fix the last caller, gtk_widget_draw,
to do the same.
Call gtk_popover_update_position instead which will pick up the new
transition_diff value and pass it on to
_gtk_window_set_popover_position, which in turn will move the window
correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=755435
Check whether the given popover even changed size in
_gtk_window_set_popover_position. If not, just move its GdkWindow
without calling gtk_widget_queue_resize. Using popover_get_rect here is
still relatively costly, but popover_size_allocate would be doing that
anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=755435
We can use gdk_window_peek_children here, instead of copying
the list. Note that we preserve the bottom-to-top ordering by
iterating the list from the end.
gdk_window_get_children_with_user_data was doing a list
reversal while filtering the list.
The string we were using is the representation of the internal text
in the popover entry. However that can be freed before setting the
bookmark label, if i.e. the row is destroyed and therefore the popover
as well.
To avoid that, duplicate the label in a local variable.
One of the consequences is that for those people using development version
we migth screwed its bookmarks file, since the bookmark manager wrote
garbage from the already freed label.
https://bugzilla.gnome.org/show_bug.cgi?id=755215
Update the notes that this is also used for Visual Studio 2015 support,
and correct the MSVC_VER_LONG for MSVC 2015, which is 14, not 2015.
Also add a note that this can be used for other projects that have
Visual Studio build support.
We are passing widget coordinates to gtk_text_view_window_to_buffer_coords()
which expects coordinates to be relative to the text window in this case.
This may result in drop coordinates being displaced if the side windows to
the top/left sides are visible and taking space, so the DnD indicator will
point to the wrong position.
This can be seen on gnome-builder and gedit when displaying line numbers.
Some distributions (MSYS2, Debian) call autoreconf on a tarball because
they change the autotools artifacts.
In order to rebuild the Broadway generated files, we need to ship the
scripts that we use when disting a release.
The row and rename popovers are always relative_to a row.
We also keep a pointer to them so we can interact with them in
callbacks.
However, if the row is destroyed its associated popovers will be
destroyed as well as relative_to destroyes and frees memory of its
associated widget when its relative_to widget is destroyed.
If we, for example, update the places while the popover is shown we are
going to access and invalid widget on the next time.
To avoid that, connect to the destroy signal of the popovers and clean
the sidebar pointers when that happens.
https://bugzilla.gnome.org/show_bug.cgi?id=755444
The patch did not check for Visual Studio 2008 correctly, plus it
would break the build on later Visual Studio versions, as it should
be __popcnt(), not __popcount(). Fix that.
The popcount builtin was added in GCC after version 4.2 (which is what
some *BSDs are using), which means we need to be more specific when
using it than just asking for GCC.
While we're at it, we can improve the compiler detection, and use a
builtin popcount on Clang ≥ 3.1 and MSVC 2008.
https://bugzilla.gnome.org/show_bug.cgi?id=755455
Instead of handling the horizontal and vertical peers separately
(and often, duplicatively), collect all peers in one go. At the
same time, avoid creating and destroying hash tables more often
than necessary.
The recent changes to build/win32/vs9|10/Makefile.am fixed 'make distclean'
but broke 'make -jN dist', so fix that by listing the *.headers and using
that list as a dependency and to remove those files in one single command
right after we generate the gtk-install.vsprops template, so that we don't
have to worry about them in 'make distclean'.
At the time we populate the model "initially" in constructed(),
it has already been filled and cleared a couple of times (we do
that every time one of the construct properties gets set). So
we can't assume that the model is empty, and have to clear it
first. Otherwise, we add duplicates to the list.
https://bugzilla.gnome.org/show_bug.cgi?id=748080
Plug and Socket require X11 windowing. Often times this is compiled
on systems with both wayland and x11, but not always. Quartz is an
example where it is usually not compiled.
GTK cannot depend on libcanberra-gtk which depends on GTK. This causes
a circular dependency and is especially neat if installed GTK is
different enough from uninstalled GTK.
The default event bubbling paths are prone to just running event controllers
even after the widget was potentially unrealized/destroyed in an event
handler callback, so bail out early if that's the case.
https://bugzilla.gnome.org/show_bug.cgi?id=755352
To GtkGesture machinery, if an event triggers a controller/gesture signal,
and gesture reset/cancellation as a result, the event has been managed
after all.
Commit e3bd895667 effectively changed the return value of the
wrapping gtk_event_controller_handle_event() function, which broke some
paths (eg. gtk_popover_button_press() wouldn't while the GTK+ grab was
active for this reason because the button press event was consumed early
on gtk_window_check_handle_wm_event()).
That patch is not too off-track given potential child widgets' behavior,
we want nonetheless to distinguish the denied vs cancelled paths here
(because GtkWindow itself relies on the GtkGesture behavior described in
the first paragraph on the begin_move/resize paths), so just reset
gestures after the event has already gone through the GtkEventController
so the return value is unaffected.
This updates the Visual Studio Project GUIDs so that they don't repeat with
the GTK+-2.24.x ones, as the 3.x projects can be used with the 2.24.x in a
all-in-one solution file (such as when one wants to use a complete GTK+2
and GTK+3 stack when porting Windows applications from GTK+2 to GTK+3), and
each project in a solution file is expected to have an unique GUID.
Traditionally a sequence is set to GTK_EVENT_SEQUENCE_DENIED state when
it is to be ignored, which means it is dormant, but still managed by the
gesture (accounting, "denied" sequences still make "slots" in multitouch
gesture busy, etc...).
This gesture will run for all button presses and releases in the window
though when presses happen on the "window content" region, and we can't
account for every children to be as educated as setting the proper mask
on every window, or ensuring events will be propagated as they should.
In order to cater for this, just reset the gestures, we can live without
such accounting in these specific GtkGestureSingle gestures.
https://bugzilla.gnome.org/show_bug.cgi?id=754098
We do not know what happened to this surface outside of GDK.
Especially for foreign windows, they will have been modified
by external applications.
So be on the safe side and tell Cairo to clear all its caches.
https://bugzilla.gnome.org/show_bug.cgi?id=754952
Instead of using a fixed size, use a factor of the surface size. This
helps in situations where animations of surrounding widgets are used
and cause a rapid rate of surface destroy/create cycles.
gdk_wayland_device_update_window_cursor() is inconsistently returning
TRUE/FALSE, despite the timeout being always replaced for new cursor
frames. This could end up in these timeouts being "leaked" and running
as long as the window has an animated cursor.
Fix this by making it really sure we return G_SOURCE_REMOVE, although
now we keep track of animation delays, so the timeout will be reused
for constant time animations.
It makes no sense to skip denied sequences here, the gestures are
still carrying out the accounting for these, which must be also put
to an end if we're possibly not receiving any further events from
this sequence.
https://bugzilla.gnome.org/show_bug.cgi?id=754098
At the time event_check_cancel_sequence_on_hierarchy() is called, the widget
has been already unparented. Given the widget itself is being destroyed,
cancellation on it is impending in one way or another, we still must
propagate cancellation across all parents, so retrieve it early before
possible widget destruction.
https://bugzilla.gnome.org/show_bug.cgi?id=754098
Otherwise it's attempted through a timeout, which gets cancelled early after,
and the slider disappears after a while with no mouse activity despite the
ongoing implicit grab.
Once the grab is finished, check_update_scrollbar_proximity() will be called
again on both scrollbars, and the fade out animation will be triggered as a
result.
https://bugzilla.gnome.org/show_bug.cgi?id=754745
When right-clicking in an empty folder, you should get a context
menu, not a crash. The code for positioning the popover was not
handling the eventuality of no row under the pointer. Just position
the popover right at the click location in this case.
https://bugzilla.gnome.org/show_bug.cgi?id=755021
A lot of time was spend rendering the shadows on windows with CSD, in
particular the corner pieces, since they are the largest parts. This
patch catches this particular case and caches the pre-rendered blur
masks.
This makes the shadow code go from 25% to 8% of the time when resizing
gtk3-demo.
"Add" Visual Studio 2015 projects by what we did before: Copy the Visual
Studio 2010 project files and replace the items in there as needed, as
the formats of the 2010 and 2015 projects are largely the same.
We need to rename the projects so that when these projects are added
into an all-in-one solution file that will build the GTK+ 2/3 stack,
the names of the projects will not collide with the GTK+-2.x ones,
especially as GTK+-2.x and GTK+-3.x are done to co-exist on the same
system. This is due to the case that the MSVC projects are directly
carried over from the GTK+-2.x ones and was then updated for 3.x.
We still need to update the GUIDs of the projects, so that they won't
conflict with the GTK+-2.x ones.
Use the common automake module from the previous commit in the
Makefile.am's, which means that the Makefile.am's in gdk/ and gtk/ can be
cleaned up as a result. As a side effect, the property sheet that is used
to "install" the build results and headers can now be generated in terms of
the listing of headers to copy during 'make dist', where we can acquire
most of the list of headers to "install", so that we can largely avoid the
situation where the property sheet files are not updated in time for this,
causing missing headers when this build of GTK+ is being used.
Also use the Visual Studio Project file generation for the following
projects:
gtk3-demo
gtk3-demo-application
gtk3-icon-browser
gdk-win32
gdk-broadway
gail-util
So that the maintenace of these project files can be simplified as well.
https://bugzilla.gnome.org/show_bug.cgi?id=681965
This adds a common autotools module that can be used by various projects to
generate the Visual Studio projects as needed, and if necessary, generate
the headers listings to "install" for that project, based on items passed
in to this. This is modeled on the Makefile.introspection autotools file
that is used by many GNOME projects to generate the introspection files.
https://bugzilla.gnome.org/show_bug.cgi?id=681965
Initially the subsurface will be in synchronized mode and we will leave
it like this until the first time the parent surface has been committed.
The reason for this is because the subsurface position will be applied
as part of the parent surface state, and we need to synchronize the
initial position with the initial frame, so that we don't accidentally
draw the subsurface at the default position (0, 0) which would happen in
desynchronized mode if the subsurface content is committed before the
next parent surface commit.
https://bugzilla.gnome.org/show_bug.cgi?id=754839
The GtkEventController event mask is private, and set early by GtkGesture
implementations. Being this private data, there is no corresponding
property, so this code is a no-op, there is just no need to listen to
changes there.
We use to rely on grab broken events for most of the event sequence
lifetime, this breaks though on GDK_BUTTON_RELEASE/GDK_TOUCH_END, as there's
no longer a grab at that time.
For these cases (and all others where there's destroy/unrealize calls
involved during event dispatching), catch this on the late
WIDGET_REALIZED_FOR_EVENT calls on widget event handling functions.
https://bugzilla.gnome.org/show_bug.cgi?id=754098
This avoids a lot of overhead in the common case where a signal
is not connected and we're just using the class vfunc (which is true
for all in-libgtk widgets). Additionally it makes backtraces in
debuggers and profiles much much nicer to look at.
https://bugzilla.gnome.org/show_bug.cgi?id=754986
These days exposure happens only on the native windows (generally the
toplevel window) and is propagated down recursively. The expose event
is only useful for backwards compat, and in fact, for double buffered
widgets we totally ignore the event (and non-double buffering breaks
on wayland).
So, by not setting the mask we avoid emitting these events and then
later ignoring them.
We still keep it on eventbox, fixed and layout as these are used
in weird ways that want backwards compat.
There is no need to ref the windows we're ignoring, so collect and ref
only the affected child windows. Also, use a on-stack array rather
than allocating a linked list.
Also, we don't need to ref during the event emissions too, as we
already hold a ref.
https://bugzilla.gnome.org/show_bug.cgi?id=754687
It turns out that xgettext does not understand translatable="1",
so don't make gtk-builder-tool produce this, even though
GtkBuilder can parse it just fine.
https://bugzilla.gnome.org/show_bug.cgi?id=754928
This changes textview to share the style context with the pixelcache.
Doing so allows pixel cache to optimize the surface creation and use
a CAIRO_CONTENT_COLOR instead of CAIRO_CONTENT_COLOR_ALPHA when
appropriate.
https://bugzilla.gnome.org/show_bug.cgi?id=754658
We can take a fast path if the background for a widget is opaque by using
a CAIRO_CONTENT_COLOR instead of a CAIRO_CONTENT_COLOR_ALPHA surface. Most
blit'ing backends have a fast path for this, including Pixman and Quartz.
https://bugzilla.gnome.org/show_bug.cgi?id=754658
This new private API, _gtk_style_context_is_background_opaque(), is meant to
be used by internal Gtk+ wigets to optimize fast paths for cases where
applicable. One such use would be to use a CAIRO_CONTENT_COLOR surface
instead of CAIRO_CONTENT_COLOR_ALPHA.
https://bugzilla.gnome.org/show_bug.cgi?id=754658
This avoids a bunch of allocations, and additionally it has better
cache behaviour, as we don't follow pointers to the separate GList
node memory areas during traversal.
From Christian Hergert:
This machine is a Retina mac book pro so I've been working on getting
GtkTextView (GtkPixelCache) up to our performance level on
X11/Wayland. I'm seeing a jump from about 43 FPS to about 50 FPS.
https://bugzilla.gnome.org/show_bug.cgi?id=754687
Merge it into GtkWidgetPrivate. In my measurements, about half
of all widgets have a non-default auxinfo struct, and we use this
information in size allocation, so it is nice to avoid the gdata
overhead.
We only use widget paths for a few widgets nowadays (notebook,
treeview, pathbar, combobox), so we can save some space by
not having this field in GtkWidgetPrivate.
The hash table is only accessed at creation and destruction time,
and many widgets don't use templates at all, so no need to have
this permanently occupying space.
This reverts commit 3eacfa88f2.
Apart from the patch not being correct, we don't want to expose private
structures in header files if we can avoid it.
And this type-checking overhead is not an optimization that is even
measurable.
https://bugzilla.gnome.org/show_bug.cgi?id=754932
Statistics for the gtk3-demo listbox example show that the
vast majority of calls to _gtk_allocated_bitmask_resize go
from a size of 2 to 2. Don't needlessly call realloc() in
this case.
The previous code was crashing when used as the returned classes array
would have been invalid after the first deletion. So if a 2nd class
would be deleted, invalid memory might have been referenced.
In order to retrieve the user options for a printer, the respective
printer name is used.
This fixes the comparison of printer names to avoid that the options of
another printer are accidently read whose name starts with the same
letters, but is longer (e.g. "myprinterlongername" instead of
"myprinter").
This fixes Bug 753628.
This function is getting called a lot. Statistics for the gtk3-demo
listbox example show most calls with 0-4 classes. Unrolling the cases
a bit brings the instruction count in callgrind from 93M to 52M.
The same trick that was applied to _gtk_css_change_for_child in
the previous commit can be applied to _gtk_css_change_for_sibling
as well, and that is what this commit does.
With both functions converted, gtk_css_change_translate is no
longer needed and gets dropped.
The function to translate GtkCssChange enum values to the PARENT
ones is called very frequently. This patch speeds it up tremendously.
The callgrind instruction count for this function in the listbox
demo goes from 108M to 7M.
My statistics show that more than half of all calls end up
with 0 matches, so we can avoid some overhead by not allocating
an array at all in this case.
We are dealing with really short lists here.
95% are < 10 matches, and the longest I've been able to record was 19.
So just do away with the hash table and do sorted insertion in
the array directly.
Otherwise the outer loop control variable is messed up, and we end
up with uninitialized axes if there were any more valuators after
the XIKeyClass one.
This bug was sneakily introduced by fdb9a8e14, many thanks to
Carlos Soriano for helping spot the source of this bug.
https://bugzilla.gnome.org/show_bug.cgi?id=753431
The logic here is that G_ENABLE_DEBUG is for compiling out
debug spew that can be triggered at runtime with the GTK_DEBUG
environment variable, while G_ENABLE_CONSISTENCY_CHECKS is for
consistency checks that are applied unconditionally.
Use a separate G_ENABLE_CONSISTENCY_CHECKS define to guard internal
consistency checks that are applied unconditionally if they are enabled,
such as the widget invariants checking. Interactive debug spew that can
be triggered at runtime with the GTK_DEBUG environment variable is still
guarded by the G_ENABLE_DEBUG define.
The mapping from enable-debug levels to defines is as follows:
yes: G_ENABLE_DEBUG G_ENABLE_CONSISTENCY_CHECKS
minimum: G_ENABLE_DEBUG G_DISABLE_CAST_CHECKS
no: G_DISABLE_CAST_CHECKS G_DISABLE_ASSERT G_DISABLE_CHECKS
The speed-up in 7da1f8a1ce was wrong in
certain conditions, even though it didn't trigger the existing
testsuite.
New testcase /bitmask/invert_range_hardcoded included.
Add a --run option which takes the name of an example and
launches it. Also add a --autoquit option which can be used
to quit after a given number of seconds.
If we are using gl for drawing, we don't have a shm surface,
so don't assert that we do. Instead, only call shm-specific
apis when they make sense.
This fixes a crash when showing popovers over a GtkGLArea,
as seen in gdkgears.
https://bugzilla.gnome.org/show_bug.cgi?id=754143
Instead, inherit style from toplevel (because that's the default way,
not because it makes lots of sense).
This way, popovers don't inherit the styling from the widget that popped
them up, which is a problem in selected listbox rows, selection-mode
headerbars.
It also doesn't inherit styling where we might want it, like the osd.
But we can only have one of the two things.
- reshuffled the stylesheet to easily allow having a thicker
border, but decided to keep the 1px borders on entries
as it makes easier to spot the buttons despite being flat.
https://bugzilla.gnome.org/show_bug.cgi?id=753129
If the position of the children is always relative to the box
then we should not take the allocation of the box into account
when flipping the children for RTL text direction.
This patch also removes unused assignments to child_allocation.
https://bugzilla.gnome.org/show_bug.cgi?id=754559
Same as we did for the entry in the previous commit.
Previously, we just hid the cursor if a key event was adding text,
but not when you used backspace, or Ctrl-V. Rearrange things so that
we obscure the cursor whenever the buffer contents change while we
are handling key events.
https://bugzilla.gnome.org/show_bug.cgi?id=754535
Previously, we just hid the cursor if a key event was adding text,
but not when you used backspace, or Ctrl-V. Rearrange things so that
we obscure the cursor whenever the buffer contents change while we
are handling key events.
https://bugzilla.gnome.org/show_bug.cgi?id=754535
When the places view is finalized before the network loading
is finished, the async operation is cancelled, and the callback
accesses the places view while it is already in a state of
disrepair. Avoid that access.
When receiving a selection or when a drag icon enter a window, it was
targeted at a specific window. Lets emit the GDK_OWNER_CHANGE event
only for this window, instead of broadcasting.
Broadcasting has some nasty side effects. For example, if there was n
GdkWindows, and one would for every "owner-change" signal handler
receive n signals about the owner being changed.
An example of where this went a bit out of hand was gnome-terminal,
which added one listener per terminal window. This meant that if
one had m number of terminal windows, each time any one would loose or
gain keyboard focus, O(m^2) owner-change events would be emitted.
https://bugzilla.gnome.org/show_bug.cgi?id=754158
The purpose of this patch is to fix regressions in GtkTextView
scroll behaviours due to commit d138156.
( addition of padding and margins to the view )
Adding some padding is done by, for example, in inspector css tab with:
GtkTextView {
padding: 10px 10px 10px 10px;
}
and adding margins, by changing one of *-margin properties
( * standing for left/right/top/bottom ) or the corresponding
accessor functions.
Understand that none of these bugs are easy to trigger.
What's happened is that a old and wrong version of the code of the code
( lost in the mean time ) was pushed.
These bugs are best seen with wrap mode set to off.
The commit 8baab8f fix a first regression.
This one is about:
- Cursor going out of the view at line ends instead of being visible
or triggering the horizontal scroll.
- Padding not displayed correctly
when moving cursor at beginning/end of lines
- When horizontal scroll position not at left, cursor can make scroll
by more than one character (you need left padding to see this )
- Moving the cursor arround, the rendered text can be shitted in x or y.
( fixed by converting adjustment float values
to integer before calculations )
It can be observed by going down with the cursor more
than the view height then going up
- retval return value of _gtk_text_view_scroll_to_iter wrong in some cases
In addition, this patch re-factor priv->top_border
in screen_dest.y calculation
Of course, all GtkTextView and GtkSourceView based app were impacted
by these bugs ( gedit for example, see bug 754147 )
https://bugzilla.gnome.org/show_bug.cgi?id=753815https://bugzilla.gnome.org/show_bug.cgi?id=75815
This is a 'developer mode' feature, and it can and does interfere
with preexisting key bindings in some applications, so keep it
off by default in stable releases, at least.
http://bugzilla.gnome.org/show_bug.cgi?id=754115
Until now the code was not very clear about why the loading property is
needed, since we didn't forced all the async operations to mark the
view as loading. This cause that clients are not aware when the view
is busy on those situations.
For instance Nautilus uses the property for a few things, one of it
is to show a busy spinner on the tab title.
To improve the situation, mark as loading when a volume operation,
a mount operation or a connect to server operation is being performed.
https://bugzilla.gnome.org/show_bug.cgi?id=754150
We are showing a GtkSpinner on the networks header to provide feedback
to the user if we are fetching networks, therefore we have to modify
the spinner state when doing it.
However GtkListBox doesn't give guarantees about the widgets
set by gtk_list_box_set_header, and we could access an invalid
widget.
To avoid to access invalid widgets, bind the fetching networks
view property to the networks header spinner active property instead
of modifying directly the spinner in the private structure.
Not having the spinner in the private structure also makes the code
cleaner.
https://bugzilla.gnome.org/show_bug.cgi?id=754150
We were filtering out placeholders if the list box filters
while not searching, which is not what we want, since placeholders
should only be hidden if the view is searching.
https://bugzilla.gnome.org/show_bug.cgi?id=754150
The application demo had a "Blue" and a "Bold" menuitem both with
the Ctrl-B accel. This is confusing, since only one of them works.
Change the accelerator for bold to Ctrl-Shift-B, so they both work.
Make this function harmless to call without an open display connection.
This happens during gobject introspection, which instantiates GTK+
types without calling gtk_init.
It needs to open a display connection, which is obviously going to fail
miserably on any headless build machine.
Instead, we need to find where we started requiring to initialize GTK
when calling a get_type() function, and stop doing that.
This commit and commit 15cc85db29 fully
revert commit 6838861d26.
GCC will not do the right thing, and it will just break the build when
trying to include gtk.h first.
We'll have to live with the warning from the compiler about a missing
gtk_init() — though it would be better not to have to init GTK at all to
generate the introspection data.
This commit unbreaks the build in GNOME Continuous introduced by commit
6838861d26.
Having these extra spaces in the accel string is a bit awkward,
since they will be included in text decorations such as underlines.
Removing them has no visible effect.
Calling our get_type functions without prior gtk_init() is not ok,
and causes warnings now. Avoid that by teaching g-ir-scanner to
put a gtk_init() call into its generated code.
Otherwise, we end up using different metaphors in the place view
and in the sidebar, and nobody is going to know what the disconnect
icon means in this context.
http://bugzilla.gnome.org/show_bug.cgi?id=754022
The code in _gdk_wayland_window_dispose was not safe against
being called twice - it would call g_hash_table_destroy twice
on the known_globals hash table, the second time operating on
freed memory. It was also leaking the list of async_roundtrips.
After fixing both of these issues, the displayclose testcase
now works on Wayland.
We call gdk_wayland_window_hide_surface when the window gets
destroyed, and in this case, the frame clock might not exist
anymore.
This was showing up in the displayclose testcase.
While we do not have subwindows in Wayland, we do create an
artificial root window. When the display is closed, the root
window gets destroyed, causing recursing to be true for the
toplevel windows.
Since being 'activatable' istead of 'button' now that reset
is not needed anymore, the patch is pretty noisy since sass
interpreter changes, those look innocuous though.
A * selector applies to all widgets, so even GtkBox or GtkGrid - and
most importantly GtkListBoxRow - need to recompute their style because
of the * selector.
By using a more specific one, these common cases aren't affected
anymore.
Fixes slowdowns in gtk3-demo's listbox demo and in gnome-software.
That way, the GTK engine doesn't think that the general .button CSS
might potentially apply to it.
And because combobox button is overly complex and stupid, it cannot be
cached.
So buttons thought they cannot ever cache anything because they might
suddenly end up inside a combobox without noticing and then they'd need
to round their corners differently. Of course they're just regular
"Remove" buttons like all the other 100s of "Remove" buttons in
gnome-software. But hey, better not cache anything for them and
recompute their CSS every time the :hover state changes on one of the
rows.
We can actually share :first-child/:last-child related things now,
because we special case them. So the only positions we cannot cache are
nth-child/nth-last-child.
This should take care of a lot of Adwaita's styling.
This example populates a flow box with buttons, and makes the
flow box children unfocusable, with the intention that the focus
moves directly between the buttons. Currently, keynav does not
work at all in this case.
This way, we can live without row references.
A side effect is that opening the inspector on the gtk-demo list box
example now only takes 0.5s instead of the previous 3 minutes.
Instead of queueing a new idle handler every time we call
gtk_window_update_debugging(), only queue one if none is queued that.
Saves a lot of work, in particular when templates create context menus
for every row in a large listbox as in the gtk-demo listbox example.
Do not use .button anymore.
This is for 2 reasons:
1. The styling is seperate in our themes, so it doesn't make sense to
share the style class.
2. Due to the shared styling of .buton, listbox rows inherit all the
special case styles that exist for buttons - such as linked buttons,
header buttons, entry buttons, spinbutton buttons, etc. This means
that the code has to check all these special cases all the time and
for listbox rows, this is very slow.
Defer a11y initialization until we have a display. A11y initialization
causes widget classes to be initalized, which in turn needs some
backend-specific information about modifier masks that can't be
obtained before we have a display.
https://bugzilla.gnome.org/show_bug.cgi?id=736125
Add all 388 tweets of the @GTKtoolkit account. This shows the
performance behavior of the listbox (not good with that many rows) and
allows us to quickly notice when things get worse (or better).
And just so I have a place where I can dump how I generated this file:
First, I got Timm Bäder to download me the json for the twitter feed
into a file gtk.json, then I ran the jq tool on it like this:
jq ".[] | if .retweeted_status then .retweeted_status.user.name + \"|\"
+ .retweeted_status.user.screen_name else .user.name + \"|\" +
.user.screen_name end + \"|\" + .text" gtk.json | cat -n | sed
"s/\\s*\([0-9]*\)\t\"\(.*\)\"/\\1|\\2/" > messages.start
jq ".[] | .created_at" gtk.json | sed "s/\"\(.*\)\"/\1/" | while read
in; do date +%s -d "$in"; done > dates
jq ".[] | \"0|\" + if .retweeted_status then .user.screen_name else \"\"
end + \"|\" + (.favorite_count | tostring) + \"|\" + (.retweet_count |
tostring)" gtk.json | sed "s/\"\(.*\)\"/\\1/" > messages.end
paste -d\| messages.start dates messages.end > messages.txt
This whole machinery of going through 3 intermediate files was only
necessary to onvert the dates from ISO format to unix timestamps,
otherwise this could have been a single line.
If we manually enter an unaccessible path in the entry, e.g
"/root/foo.txt", we should receive an error saying that the
folder is not accessible instead of showing the replace
confirmation dialog.
https://bugzilla.gnome.org/show_bug.cgi?id=753969
Previously we were assuming that only list box rows could occur
as focus children of a list box, and would crash if that wasn't
the case. This commit handles this case, and integrates focusable
headers into directional keynav and the focus chain.
The typical case of using separators as headers is not affected
by this change.
https://bugzilla.gnome.org/show_bug.cgi?id=753694
State that the overlays are placed wrt to the GtkOverlay, not
with respect to the main widget. This makes a difference for
small main widgets which are not configured to fill the entire
GtkOverlay.
When an operation is cancelled it's never safe to access
the object itself or the private struct, since it could be
called (and probably is) during finalize.
In case the operation is cancelled, just bail out to fix
the crashes.
Add a spinner when networks are being fetched and make
the network section permanent and show a placeholder with
a message that no networks were found in case there are no
networks. In this way users from previous versions won't be
confused with the fact that no networks are shown.
https://bugzilla.gnome.org/show_bug.cgi?id=753786
Previously we had a network item in the sidebar, which now
is replaced by the network section on other-locations view.
However we were not exposing the networks in network:///.
Fetch them and add them in the network section of other-locations
view.
https://bugzilla.gnome.org/show_bug.cgi?id=753786
As the protocol is still considered unstable (meaning not backward
compatible), we should, as stated in the protocol, only bind the version
advertised is the version we implement.
https://bugzilla.gnome.org/show_bug.cgi?id=753856
Code exists in the wild that calls this function after the widget has
been destroyed (and the pixel cache released). Simply check that the
pixel cache exists to preserve the existing state.
When you move line by line, only padding is
automaticly shown and you need to use Page key to show margin.
This commit also fix cursor going out of the screen bug.
The extra reference will be held from GdkEventPrivate data, so there's
a common place to all events. Without this, events queued after devices/
capabilities disappear (eg. on TTY switch) might hold invalid pointers.
Windowing level operations on those devices (queries, grabs...) are
expected to fail at that time, but we should hold meaningful data for
the regular event handling paths.
https://bugzilla.gnome.org/show_bug.cgi?id=753185
In order to play along with child widgets that use scroll events for anything
else than scrolling, it will be better to do this in the bubble phase, so
the child widget has an opportunity to GDK_EVENT_STOP the event before we
trigger kinetic scrolling.
This of course won't work for widgets that choose to reimplement scroll event
handling themselves, they should be smart at resorting to GtkScrolledWindow's
scroll event handling.
This fixes kinetic scrolling kicking in too pervasively on widgets that eg.
implement zoom on scroll events.
https://bugzilla.gnome.org/show_bug.cgi?id=753495
By assigning an URI to Other Locations item, we
can programaticaly select it. Fixes a bug in Nautilus,
where the Other Locations item is unselected imediately
after being clicked.
GtkPrintOperation was emitting paginate only if a signal was
connected, this meant that subclassing and overriding the
paginate vfunc lead to the unexpected result that paginate did
not run.
Instead we always emit the signal and use a custom accumulator:
if there is a signal we just run that and avoid the default
handler, otherwise we run the default handler which can be the
one by the subclass or the default handler that just skips
pagination.
Patch by Yevgen Muntyan, fixes#345345
Prior to this patch, the ID of the GtkApplication was always used for
clients which were GtkApplications. This would only be guaranteed to be
correct for D-Bus activatable programs. As a result, all
non-D-Bus-activatable applications would set the wrong ID making the
shell unable to find the corresponding .desktop file.
This change makes it so that the GDK backend always uses the name
passed to g_set_prgname, or the default value if not explicitly set, as
this more often corresponds to the .desktop file.
This means that in order to make D-Bus activatable applications set the
correct application ID, they must, for now, manually call
g_set_prgname() with their application ID (basename of the .desktop
file).
If g_get_prgname() returns NULL, fallback to gdk_get_program_class()
even though it will most likely never be correct according to the
xdg_surface.set_app_id specification.
https://bugzilla.gnome.org/show_bug.cgi?id=746435
We were not allowing to cancel the operation at all, and at
most the operation was cancelled only when clicked connect again.
Also due to gvfs bug 753735 we actually weren't cancelling
at all, and therefore creating multiple dialogs.
We don't want to leak references if the widget created to represent the
item in the model does not have a floating reference — which is usually
what happens in bindings, as they automatically sink references when
creating new instances.
See commit 6e03e7e8 for the similar change in GtkListBox.
Sorry, the last commit added a generated file instead of the
template.
G-I has been updated to not require a Windows GCC installation
anymore to generate the .gir files, so update the NMake Makefiles
that are used for this purpose.
As a result, it is no longer necessary to define time_t for the .gir
generation as we are on the same compiler throughout the process.
G-I has been updated to not require a Windows GCC installation
anymore to generate the .gir files, so update the NMake Makefiles
that are used for this purpose.
As a result, it is no longer necessary to define time_t for the .gir
generation as we are on the same compiler throughout the process.
GTK+ now uses pango_attr_foreground_alpha_new, pango_attr_background_alpha_new,
PANGO_ATTR_FOREGROUND_ALPHA, PANGO_ATTR_BACKGROUND_ALPHA,
pango_renderer_set_alpha, pango_renderer_get_alpha, which were all added
after 1.37.2.
wl_log() currently logs using G_LOG_LEVEL_ERROR
(which is fatal). The wayland client library doesn't
expect this behavior. It uses wl_log to log recoverable
errors.
This commit changes the log level to G_LOG_LEVEL_DEBUG
instead.
https://bugzilla.gnome.org/show_bug.cgi?id=753635
On wayland, the gestures protocol defines a wl_pointer_gestures global
object, that will match in number with wl_seats, swipe and pinch
interfaces can be obtained from it, which events are translated into
GdkEventTouchpadSwipe/Pinch events.
These will be mutually exclusive with touch events, so it won't
be possible to trigger gestures through mixed input and whatnot.
The accounting of touchpad events is slightly different, there
will be a single internal PointData struct, stored in the hashtable
with the NULL event sequence/key (same than pointer events in
this regard), just that the events stored will be GdkEventTouchpad*,
so will hold information about all fingers at once.
But this difference is just internal, the GtkGesture API doesn't
make explicit assumptions about the number of points (the closest
to a per-point query API is gtk_gesture_get_sequences()). All
signals emitted just contain the last changed GdkEventSequence,
and API takes GdkEventSequences, so everything is consistent with
sequence=NULL for touchpad events.
Along the code, we're basically asking for 1) the total count of
touchpoints, and 2) the number of active touchpoints (not denied
nor ended).
Wrap both usecases into a _gtk_gesture_get_n_physical_touchpoints(),
and replace all occurrences.
The gestures that don't want touchpad gesture events are majority,
even those that want such events will only listen to subsets (eg.
pinch, swipe,...).
So it makes sense to ignore touchpad events by default, and let
subclasses opt those in.
This will be used right before handle_event() in order to filter
out events, useful to make the previous "no touchpad events" behavior
the default, and have gesture subclasses include manually the touchpad
events they handle.
For all other events, we run the bubble phase deep in the specific
::motion/button-press/release/touch handlers.
For touchpad events, it doesn't make sense to use GtkWidgetClass
slots if the intended way to deal with these are gestures, so we
run the bubble phase directly from gtk_widget_event_internal().
Each gesture type has its separate GdkEvent struct, and begin/update/
end/cancel event types.
There is support for multi-finger swipe (3-4 fingers), and 2-finger
rotate/pinch gestures.
Do not call _gtk_icon_helper_clear explicitely when the properties
are set, since the corresponding _gtk_icon_helper_set_* method
already calls clear internally.
While at it rename the reset function to make it clear that it
is calling notify for the previous image type and avoid the
notification if the image type is not changing.
We have a testcolorchooser test, with a --edit option. It was
supposed to make the color chooser come up in edit mode, but
it didn't work ever since we dropped the ::response handler.
Fix it by resetting show-editor on unmap, instead of on map.
This way, users can set show-editor before showing the dialog,
and it will take effect.
Since we're dealing with networks, terms like "Eject" or
the eject button are misleading, since we're not actually
ejecting but disconnecting.
Fix that by showing the appropriate icon and tooltip.
We are not showing the URL of network locations
anymore, since they are distracting and not
necessary.
The code, however, forgot to cleanup the URL,
so we are still showing the URL for network
locations.
Fix that by properly cleanup the URL for network
locations.
The .button:link .label selector matches any label "inside" a
link button. And a label inside the context menu counts as inside
for this purpose. This causes the text-decoration property to
leak into the context menu, even though the property is not
inherited. Avoid this by tightening the selector to
.button:link > .label.
https://bugzilla.gnome.org/show_bug.cgi?id=753451
When we connect to a server, the default and expected
behavior is going to the default location, which usually
is the home directory or a writable directory.
GtkPlacesSidebar behaves properly, while GtkPlacesView
doesn't.
Fix that by jumping to the default locations instead of
the root location.
Don't use gtk_widget_show_all() on row widgets because that would
unconditionally show all of its children. This might be unwanted in case
the row implementation wants to keep some of its children hidden.
This commit changes it to use show() instead of show_all() and relies on
the row widget to control the visibility of its children itself as
appropriate.
https://bugzilla.gnome.org/show_bug.cgi?id=753392
GtkFileSystem has a complicated way to handle cancellables.
You keep the cancellable pointer that is returned by
_gtk_file_system_get_info and similar methods so that you can
cancel the operation, but you do not own a reference to it.
The only place where it is ok to unref a cancellable is in
your callback, which gets handed a cancellable that you need
to unref at the end. You are expected to compare it to the
pointer you stashed away to find out if the operation has
already been superseded by a newer call, in which case you
disregard the results.
GtkFileChooserButton was following these rules for most of
the cancellables it keeps around, but it was sometimes unreffing
the cancellables that are stored in the model, which could lead
to refcount confusion and crashes. This commit makes it follow
the rules for that case too, which fixes the crash in the bug
below, and does not show up any leaks in valgrind under light
testing.
https://bugzilla.gnome.org/show_bug.cgi?id=737804
The recent change to the enum declaration for GtkCssChange actually
relied on compiler-dependent behavior, which also breaks the build on
some non-GCC compilers, such as Visual Studio. As noted in the
G_STATIC_ASSERT line just beneath this declaration, we need to change
this enum declaration to #define's, in order to fix the build in such
situations.
https://bugzilla.gnome.org/show_bug.cgi?id=752814
It works just as well here as it does in the file chooser, and
this lets us unify the right-click and long-press behavior a bit.
We used to switch directly to the editor on long-press, now we
can show the popover, just as we do on right-click.
Only a drag context which was created with 'drag_begin' will be
guaranteed to have a source window at all times. Thus, in finalize we
cannot assume we can retrieve a GdkDisplay from the source_window
pointer since it may be NULL. Though, the display is only needed for
contexts created via 'drag_begin' thus we can retrieve it after
checking that is the case.
https://bugzilla.gnome.org/show_bug.cgi?id=749339
This is implicitly done for us in the case of grabs on windows from other
groups, but we must perform this check explicitly for grabs with
owner_events=True on windows from the same group, in that case the window
would handle the events as if there was no grab.
https://bugzilla.gnome.org/show_bug.cgi?id=752327
We need to be mapped to have a gtk_surface and thus be able to do
requests on it so we need to save the modal hint and apply it when we
get mapped so that code that sets the hint before showing a window
doesn't get ignored.
https://bugzilla.gnome.org/show_bug.cgi?id=753138
We only load thumbnails when we find that the row is in the visible
range of the treeview. It seems that animated scrolling makes it so
that the bottommost row stays out of the visible range until it is
too late. To work around this, extend the range by one row in each
direction.
http://bugzilla.gnome.org/show_bug.cgi?id=753142
Properties like transition-property might change when hovering over
something, even if the property itself does not change. These properties
don't affect drawing, so don't queue redraws for them.
Since a lot of Adwaita sets transition: all, it's easy to end up in a
state where we're making dummy transitions for all of the icons, most of
which we'll never be showing.
Interpret a unmodified primary click on the selection like a double
click. This makes it possible to activate a file or open a folder
without using double-click.
The visibility toggling happening on ::click() relied implicitly
on the popover animation, but breaks on disabled animations. The
recursion happening within gtk_toggle_button_set_active() (which
triggers ::clicked when changing state) makes this vfunc to run
again, inverting the visibility of the popover in result.
Fix this by explicitly checking about recursion, we want the
button to be toggled to the right state, but we don't want the
callback running again.
https://bugzilla.gnome.org/show_bug.cgi?id=752577
Instead of putting it inside the button manually, put it there properly
by adding a box containing the cell view and the arrow.
Do the same thing in list mode, instead of creating an event box that
tries to behave as a button.
This is unnecessary - all the recent files are in the model already.
It also leads to duplicates, since our duplicate filtering is based
on g_file_equal, which does not consider recent:///blabla with
target-uri=/my/example to be the same as file:///my/example.
The "Computer" row from places view is an abstract volume
that represents the root of the current partition. As such,
it cannot be mounted or unmounted.
Remove the related item on context menu for Computer row.
We were previously mixing the model used when filtering with an iter that
has been resolved to the backing model.
This results in both an invalid row index as well as an invalid
iter->stamp.
Since we started adding a persistent Computer item,
all the code related to the view modes became obsolete,
since the view is never empty anymore. So, drop this
dead code and use the plain stack to manage the empty
search results view.
Also, this patch fixed a very annoying keyboard navigation
issue where we couldn't go from the On This Computer to Networks
lists, because they were two separate widgets. Merge the two
lists into a single one, and update headers accordingly.
The places sidebar rows' labels were missing a proper
xalign, which caused the labels to keep shaking while
the sidebar was resized.
Fix that by setting the label's xalign to 0.
The GFile containing the Computer item was not
properly dereferenced, so plug that leak by both
dereferencing it and adding some reference management
on GtkPlacesViewRow.
GtkPlacesView widget manages persistent locations,
factoring out GtkPlacesSidebar functionality.
It, however, does not completely shows all sidebar
locations, since Computer is still missing.
Add a Computer item, adjusting some internal behavior
to make that possible.
The doc for gtk_places_view_get_search_query was being
set twice, while gtk_places_view_set_search_query was
never set.
Fix that by correcting the wrong getter documentation.
Use the same explanation of why GtkPlacesSidebar::show-connect-server
was deprecated and its replacements on getter and setter.
Also, fix a mistakenly deprecated function.
When dealing with selection events, we might see windows from
other screens in the requestor field. The current x11 backend
code fails to wrap these in a foreign GdkWindow, since we
don't have the corresponding GdkScreen anymore. Work around
this by creating such 'foreign screens' on demand. We still
maintain the 1:1 relation between the display and the screen
returned by gdk_display_get_default_screen().
https://bugzilla.gnome.org/show_bug.cgi?id=721398
GtkCssProvider was using the wrong unref function for GtkCssKeyframe
objects. Funnily, this didn't crash at all, the refcount was at the
same place in the struct - it just didn't free all the memory, causing
valgrind to complain.
Instead of storing the dnd icon as a pixbuf store it
as a cairo surface and transfer the device scale
when converting it to a NSImage. In the pixbuf/stock/named
setters convert to a surface instead (no hidpi support yet)
The shadow will be drawn in the wrong place in those cases so all we can
do is disable it. This fixes double shadows drawn around menus, popups
and tooltips.
https://bugzilla.gnome.org/show_bug.cgi?id=734984
Previous commits removed from places sidebar the code related
to displaying the Computer item, which should be shown when
the sidebar is not displaying the Other Locations item.
Add back the item when the sidebar is not in Other Locations'
mode.
Make GtkSearchHit carry a GFile instead of an uri. Most of the
search engines already have the object around, and converting
to an uri and back is unnecessary extra work.
Add a helper function that says whether a location should be
considered remote. To determine this, we look at the filesystem
type reported by gvfs, and say 'remote' for sftp, webdav, ftp,
nfs and cifs.
It is a bit pointless to have the file chooser get a uri from an
existing GFile to put in the query, only to have some of the search
engines reconstruct a GFile from it.
It was a special case and it's not used by themes anymore.
Plus, in the CSS world, if a theme wants a separator, it can just
style the button's border to create one.
If a drag ends inside a known window, set the dest_window field
in the drag context. This information is needed to implemented
notebook tab dragging.
https://bugzilla.gnome.org/show_bug.cgi?id=752638
Without properly cleaning up GtkMenu private attach state
(GtkMenuAttachData) when the attached widget is freed, we would end up
with an invalid pointer to a freed widget. Trying to detach from that
widget would cause a segmentation fault.
https://bugzilla.gnome.org/show_bug.cgi?id=752761
-1 means that we have no specific preference for an initial
fullscreen monitor, and -1 is less than the number of monitors,
so we would end up accessing invalid memory. Prevent that.
https://bugzilla.gnome.org/show_bug.cgi?id=752875
Call chain:
- input_data_cb
- broadway_server_read_all_input_nonblocking (input)
- broadway_input_free (input)
(now input is invalid)
attempt to use input->active -> use-after-free
Make broadway_server_read_all_input_nonblocking return a boolean, TRUE
if the input was valid, FALSE otherwise. This allows input_data_cb to
detect whether the input was gone or not.
https://bugzilla.gnome.org/show_bug.cgi?id=741685
Rewrite gtk_places_sidebar_set_show_enter_location docs, add
references to the relevant signals, remove mentions of
GtkPlacesView from the docs, since it is not public at this point.
https://bugzilla.gnome.org/show_bug.cgi?id=752633
The deprecated and a11y sources of GTK+ were spun off some time ago into
their own Makefile.inc, which is then included by gtk/Makefile.am. Fix the
generation of file sources for the GTK+ .gir.
When the dialog is as narrow as possible, we still want some
space between the entry and the search button, so use margins
around the entry and label instead of box spacing.
This ensures that windows appear in the inspectors tree when
they are created, and it prevents GTK_DEBUG=interactive from
coming up with an empty object tree.
https://bugzilla.gnome.org/show_bug.cgi?id=752664
The previous fix was falling into the crack between
realized and mapped - we would apply the state when a window
is just realized, then unset the _initially flag, and then
when the window gets mapped, we'd undo the state. To fix
this, go back to the way things were when these flags were
first introduced.
https://bugzilla.gnome.org/show_bug.cgi?id=752765
Windows does not send any release key event for one of the shift keys
when both shift keys were pressed together. This commit solves
the problem by sending the extra release key event for the shift key
which was released as first, when the other shift key is released.
Other modifiers (e.g. Ctrl, Alt) do not have this problem.
https://bugzilla.gnome.org/show_bug.cgi?id=751721
So a window can be maximized/zoomed again after being moved away from
its maximized position. This makes the zoom button on non-CSD windows
work as before.
Instead of using the default zoom behaviour use the internal
maximized state for selecting our own zoom target. This makes
zooming work for CSD windows where for some reason the
given default zoom target is the current window frame itself
resulting in a shadowless window of the same size.
While this makes the zoom button behave a bit different as expected
it makes things more consistent with other platforms and fixes CSD
zooming.
When using the location popup to complete to a directory name
(with a trailing /), we should not punish the user by making the
Open button insensitive and preventing the Enter key from doing
the expected thing (switching to that directory).
https://bugzilla.gnome.org/show_bug.cgi?id=752708
Make sure entering the three special strings ".", ".." or "~" in
the location entry works as expected. They already worked correctly
if you append a '/' to force them to be recognized as the 'folder'
part, but that should not be necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=752707
Go back to use these variables only for pre-mapped state changes.
Their use got muddied over the years, and it was hard to keep track
of what is acutal state, and what just a queued request.
The save_widgets_create function was not safe against
being called multiple times in save mode, calling
gtk_file_chooser_set_create_folders was a way to trigger
this crash.
Previously, we would pango_font_describe() every time the code ran and
we wouldn't ever hit the optimized quick exit.
The code now is a lot more complex because the
compute-actual-value-when-required-the-first-time approach is not
supported out of the box in GtkTreeModel (or GValue).
When the search is cancelled, we may end up with a tracker
dbus reply coming in after the GtkSearchEngine object is
already gone, and bad things happen. Prevent this by
using g_signal_connect_object instead of g_signal_connect.
We generally have const getters for strings, and the two users
of this API were promptly leaking the (unexpected) copy they
got from gtk_query_get_location and gtk_query_get_text.
I invadvertendly introduced a dependency on a recent GLib recently,
by cherry-picking a fix that used new GLib API. This commit will
help catching such errors before release, by using the versioned
deprecation machinery to turn such events into build-time
warnings.
Makefile.decl does not work well with scripts that stay
in srcdir, so generate test-simplify from test-simplify.in,
just os that it ends up in builddir.
I forgot to clean up the long press gesture, and in additon, creating
the rename popover from the ui template was causing the tree view
to not be disposed when the file chooser goes away. Work around this
by manually unsetting the relative-to widget of the popover in dispose.
Prior to this patch, the hotspot would be passed in buffer coordinate
space. Where this were ever tested, i.e. in a patched mutter, the
server interpreted them incorrectly, which meant it went undiscovered.
In the updated mutter patches the incorrect behavior in GTK+ was
discovered due to the behavior in mutter was corrected.
In the themed cursor case, the dimensions were not correctly scaled
either, but this had no negative visible effect because the dimension is
only used for reporting damage tracking, and passing a bigger damage
region than surface has no negative visible effects.
https://bugzilla.gnome.org/show_bug.cgi?id=752616
We are trying to scroll the header in view together with the
focus row. The way this is implemented works fine when scrolling
up, but falls short when scrolling down. Fix this by making sure
that both the row and the header bar visible.
We automatically pick up an adjustment from our parent
scrollable, but we failed to update it when it changes.
This is happening in the places sidebar, and it was causing
the focus-tracking to fail there, letting the focus move
out of view. With this change, the focus remains visible.
Remove the code in the sidebar keypress handler that imperfectly
reproduces what GtkListBox already does: moving selection and
focus in response to arrow keys.
1. This confuses the code as it's using the old type hint with the new
type hint on GDK window creation
2. It only existed as a workaround for old code that directly accessed
window->type_hint which hasn't been possible since 3.0.
I believe that first_column can only ever be NULL here if
last_column is NULL too, in which case we'd exited already.
But coverity doesn't see that, so add an explicit exit.
We don't care about the error here, but we were relying on
g_resources_get_info to zero the size even in case of error.
No need to do that, we can just check the return value. Plus,
it makes coverity happy.
The way this code is written, we know that there is an item in
the hash table and the iter_next call will give it to us, so
no need to check the return value. Annotate the call to tell
coverity.
Previously, the (1<<31) value evaluated to the 64bit value
0xFFFFFFFF80000000
instead of
0x0000000080000000
Avoid this by explicitly casting the value to unsigned long long.
Also cast all values to unsigned long long to achieve consistency
and hopefully in the future get new values added the same way.
We "fix" this signal the same way we did for GtkEntry and
GtkTextView: slightly change the signature so that the passed
widget may be a container other than a GtkMenu, and add a
property to explicitly opt in to receiving the signal in
this case.
With the name entry being in the header bar now, we no longer
get bindings working by just letting the key event bubble up,
we have to explicitly apply them on key events that the save
entry is not handling.
They were updated in style-changed, causing the label to get set to
(None), then to the actual file name again a frame later, both of the
updates cause the GtkFileChooserButton to resize, possibly to the
minimal width, causing the layout to jump. Fix this by only updating
icon/label in style-updated when the icon theme actually changed, which
is the only case we care about here.
https://bugzilla.gnome.org/show_bug.cgi?id=752509
"Yo, we heard you like traversing NULL-terminated arrays to operate on
them, so we called g_strv_length() as the for condition, so you can
iterate the array while iterating the array."
Instead of making famed rapper and television producer Xzibit proud, we
should avoid calling g_strv_length() on an array while looping on the
array, to avoid quadratic complexity.
We do this in various places that deal with arrays of strings that we
cannot really guess are short enough not to matter — e.g. the list of
CSS selectors in the inspector, or the required authentication
information for printing.
Previous commits changes the behavior of GtkPlacesSidebar, as it stops
handling persistent devices and only manages mounted networks, XDG
directories and bookmarks.
By radically breaking the previous behavior, we may have trouble
since we provide no alternatives to that besides the private widget
GtkPlacesView.
Fix that by showing the persistent devices when not showing Other
Locations item.
We need to check on realize if we have access to a GL context, before
calling GL functions. We use gtk_gl_area_get_error() for that.
We also need to tear down the resources during unrealization, instead
of leaking them.
Commit 7db399d975 introduces
the Other Locations item, as well as some behavioral changes
to GtkPlacesSidebar. It, howevers, wrongly changes the section
of code that handles the Connect to Server item, with various
side effects depending on the environment setup.
Fix that by adding the Connect to Server at the right section
of code.
gtk_css_node_set_after/before() are now called
gtk_css_node_insert_after/before().
This brings them in line with other similar APIs (ie GtkListStore). And
it allows easier usage of the API (see changes to gtkbox.c).
Previous patch modified places sidebar widget to stop handling
fixed devices by adding an "Other Locations..." item. Up to now,
however, these changes are isolated from each other since the
bundled file manager widgets ignore the sidebar requests for
external management of fixed devices and networks.
To fix that, make the file chooser widget be aware of the
GtkPlacesSidebar::show-other-locations signal and, when requested,
show places view to manage the fixed devices and networks.
https://bugzilla.gnome.org/show_bug.cgi?id=752034
Places sidebar is a widget that enabled the user to select
XDG directories, bookmarks and mounted network locations,
as well as manages permanent and removable devices.
The new design that aims to look less clutered makes the
sidebar display only removable devices, as well as mounted
networks, bookmarks and XDG directories, and delegates the
management of permanent devices such as hard drive partitions
to GtkPlacesView, a newly introduced widget for this specific
purpose.
To delegate it, add an "Other Locations..." item to notify
when the permanent devices manager is required. Besides that,
don't show these fixes devices on the sidebar itself, as they
are not supposed to be handled by the sidebar anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=752034
Places sidebar shows XDG directories, mounted and unmounted devices,
connected networks, bookmarks and actions like 'Connect to server'
and 'Insert location', which causes the sidebar to grow very quickly
and look cluttered. Because of that, new mockups for the sidebar try
to simplify it.
To make the sidebar simpler, the new mockups propose that it should
only handle connected networks and removable devices such as flash
drives and USB devices, and delegates other devices for external
widgets through the 'Other Locations' item.
To handle fixed devices and manage network connections, add a new
widget named GtkPlacesView, based on Nautilus mockups to keep
consistency between GNOME file management tools - in this case,
between Nautilus and the bundled Gtk's file chooser.
https://bugzilla.gnome.org/show_bug.cgi?id=752034
When using frame times from _NET_WM_FRAME_DRAWN and _NET_WM_FRAME_TIMINGS, we
were treating them as local monotonic times, but they are actually extended-precision
versions of the server time, and need to be translated to monotonic times in the
case where the X server and client aren't running on the same system.
This fixes rendering stalls when using X over a remote ssh connection.
https://bugzilla.gnome.org/show_bug.cgi?id=741800
With the previous approach, we could only show the spinner
before we had any results. With the new approach, we can just
leave the timeout in place and always show the spinner until
the search is done.
We were showing things like "Searching in (null)" if the current
folder is not in the sidebar. Avoid that by falling back to using
current_folder.
Pointed out by Carlos Soriano.
Avoid using a stale timestamp (from the last user interaction with the
application) when a message arrives from D-Bus requesting that a new
window be created.
In this case the most-correct thing that we can do is to use no
timestamp at all.
We modify gdk_x11_display_set_startup_notification_id() to allow a NULL
value to mean "reset everything" and then call this function
unconditionally on receipt of D-Bus activation requests. The result
will be that a missing desktop-startup-id in the platform-data struct
will reset the timestamp.
Under their default configuration metacity and mutter will both map
windows presented with no timestamp in the foreground. This could
result in false-positive, but there is very little we can do about that
without the original timestamp from the user event.
https://bugzilla.gnome.org/show_bug.cgi?id=752000
Lots of applications often use GtkFrame as a giant toplevel container,
and that means that they get size allocated often. When frames get size
allocated, they invalidate their entire widget tree, even if they
haven't changed size or anything like that happens at all. This is
because the shadow / label needs to be redrawn if the child changes
size. We can optimize this out and only mark ourselves for a redraw if
the child has actually changed its size.
GtkButtonBox adds the "linked" class to its style context when its
layout is set to GTK_BUTTONBOX_EXPAND. It shouldn't ever make sense to
have spacing between buttons in that case, as themes generally draw
linked elements with a continuous border.
Thus, always set spacing to 0 and ignore GtkDialog's button-spacing
style property when the layout is set to EXPAND.
Also remove the now-redundant css rules which set button-spacing to 0
for message dialogs.
https://bugzilla.gnome.org/show_bug.cgi?id=752131
Change things around so that warp-to-click and jump-by-pages are
bound to left-click and shift-left-click, depending on the value
of gtk-primary-button-warps-slider. Autoscrolling is bound to
right-click.
To achieve this, reorganize gtk_range_multipress_gesture_pressed
so that the functions are clearly separated.
Make shift right-click on the trough start autoscrolling. The
autoscrolling is similar to the way steppers operate now, with
the difference that we vary the scrolling speed based on the
distance of the pointer from the widget.
Clicking on steppers does different things depending on which
button you use. We used to scroll to the end on secondary click
and use high-speed autoscrolling on middle-click. Switch these
two around, since the scroll-to-end functionality is less likely
to be useful, and the seconary button makes the autoscrolling
more easily available.
Even if we only ever hit the code with a singleton selection,
calling gtk_tree_selection_get_selected is not ok if the tree
selection mode allows multi-selection. Replace all calls to
gtk_tree_selection_get_selected in the file chooser code with
callback loops iterating over the selection. This problem
was introduced with the recently added rename and delete
menuitems.
Whenever we change directories, we unset the model, and then
we set a new model. This causes several emissions of
GtkTreeSelection::changed, for each of which we do a bunch
of work to update the path bar, the location entry, etc.
We can savely ignore some of these signals, and do less work.
There is no need to animate things when we are just setting up
the startup mode, so disable transitions in the revealer and
the stack. Pointed out by Carlos Soriano
There was some code that lead to the places sidebar loosing track
of the row being dragged if a motion event came in between letting
go of the button and the drag snap-back animation ending. This would
cause us to not show the row again, giving the appearance that it
was 'lost'.
https://bugzilla.gnome.org/show_bug.cgi?id=751448
If we don't find Xft values in the X resource db, simply fall
back to the values that are hardcoded in /etc/X11/Xresources
anyway. Extra trickery with likely-made-up screen dimensions
is not going to yield better results, and only makes for a
deeper rabbit hole when debugging.
Support was added for GDK_HINT_ASPECT in
gdk_quartz_window_set_geometry_hints though with one restriction:
min_aspect and max_aspect have to be equal, which I believe corresponds
to the most common usage. A warning will be printed if this condition is
not met but min_aspect will be used anyway.
The menu tracker does a better job of this than we can, so move over to
using it instead.
This fixes issues with './testgmenu --import' not properly displaying
the language submenu.
https://bugzilla.gnome.org/show_bug.cgi?id=752016
The current widget lookup code bails out on insensitive widgets, there's
however legit cases where we want DnD handled by a parent of the insensitive
widget, so just keep going upwards in that case.
We also use now the widget state flags, because get_sensitive() doesn't
propagate across hierarchies, so we could conceivably find a drop site
inside an insensitive widget.
https://bugzilla.gnome.org/show_bug.cgi?id=751793
This behavior has been made optional on add_popover() time, text handles
will keep being able to overflow the window, in order to allow text
selection on views too close to the window edge.
Regular GtkPopovers are reinstaurated to the previous size positioning
logic though, that is, limited by the visible area of the window.
For now assume that if those flags change for a node, they also changed
for all sibling nodes. This is not strictly true but simplifies
invalidation.
The reason it simplifies invalidation is that when removing or adding a
node, we can just invalidate the first node (for NTH_LAST_CHILD) and the
new node (for NTH_CHILD) and all the other nodes will be invalidated
automatically.
Instead of GTK_CSS_CHANGE_POSITION we now have 4 values:
GTK_CSS_CHANGE_FIRST_CHILD, GTK_CSS_CHANGE_LAST_CHILD,
GTK_CSS_CHANGE_NTH_CHILD and GTK_CSS_CHANGE_NTH_LAST_CHILD
Nobody is using them directly yet.
# YourProject_HEADERS_EXCLUDES = ... # <list of headers to exclude from installation, separated by '|', wildcards allowed; use random unsed value if none>
#
# dist-hook: \ # (or add to it if it is already there, note the vs9 items will also call the vs10 items in the process)
if exist ..\..\..\MSVC_$(Configuration) goto DONE_GDKCONFIG_H
if exist ..\..\..\gdk\gdkconfig.h del ..\..\..\gdk\gdkconfig.h
if exist ..\..\..\GDK_BROADWAY_BUILD del ..\..\..\GDK_BROADWAY_BUILD
if exist ..\..\..\MSVC_$(Configuration)_Broadway del ..\..\..\MSVC_$(Configuration)_Broadway
if exist $(Configuration)\$(Platform)\bin\$(GtkDllPrefix)gdk$(GtkDllSuffix).dll del $(Configuration)\$(Platform)\bin\$(GtkDllPrefix)gdk$(GtkDllSuffix).dll
if exist $(Configuration)\$(Platform)\bin\gdk-$(ApiVersion).lib del $(Configuration)\$(Platform)\bin\gdk-$(ApiVersion).lib
if "$(Configuration)" == "Release" del ..\..\..\MSVC_Debug
if "$(Configuration)" == "Debug" del ..\..\..\MSVC_Release
<GenerateGtkDbusBuiltSources>cd ..\..\..\gtk & $(PythonPath)\python $(GDbusCodeGenCmd) & cd $(SolutionDir)</GenerateGtkDbusBuiltSources>
<GenerateGtkDbusBuiltSourcesX64>cd ..\..\..\gtk & $(PythonPathX64)\python $(GDbusCodeGenCmd) & cd $(SolutionDir)</GenerateGtkDbusBuiltSourcesX64>
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.
