And with it, gtk_widget_get_visual() and gtk_widget_set_visual() are
gone.
We now always use the RGBA visual (if available) and otherwise fall back
to the system visual.
The cursor was set using gdk_window_set_cursor() even in
gdk_window_new().
So instead of having yet another flag, just make the users of that flag
call gdk_window_set_cursor() directly after the window was created.
X11 was the only backend to support it and people can just override it
using XSetClassHint() directly.
The docs already advertised the function as "Do not use".
Keep the existing call to XSetClassHint() in place, so that we keep
setting the same values as in GTK3.
gtk_widget_destroy() removes widgets from their container. However
_internal_ widgets must be unref'ed using gtk_widget_unparent() instead.
This is symmetric with the fact that these widgets were ref'ed by direct
call to gtk_widget_set_parent(). It's also the method that was used in
gtk_headerbar_destroy().
https://bugzilla.gnome.org/show_bug.cgi?id=772859
> Due to Gtk+ keeping a reference to the window internally,
> gtk_window_new() does not return a reference to the caller.
> To delete a GtkWindow, call gtk_widget_destroy().
Caller(s) aren't expecting a need to delete help_overlay themselves
once they've installed it. (E.g. see gtk_application_window_added()).
I didn't notice any direct precedents, but there's a parallel in the
current implementation of gtk_container_destroy() which uses
gtk_widget_destroy() on any added widget.
This avoids leaking 100s of kB per window, when I tested nautilus.
https://bugzilla.gnome.org/show_bug.cgi?id=772859
This allows the use of a "text-direction" hint set to one of "none", "rtl",
or "ltr" to enforce the text direction of a "horizontal-buttons"
display-hint.
This is useful when a menu has buttons that map to physical space in the
UI and therefore must match the application widgetry.
https://bugzilla.gnome.org/show_bug.cgi?id=772775
to hilight drop target there is a wildcard selector which turns
the border and shadow to green, this clearly shouldn't happen when
the whole window is a drop target.
...by putting it in a stack. The busy_spinner and eject_button are
mutually exclusive, but only the latter was coded to ensure that its
visibility did not cause the rest of the row to reflow. By putting both
widgets in a stack and setting child_visible on that, the row allocates
enough space to show one - or none - at once, avoiding any misalignment.
https://bugzilla.gnome.org/show_bug.cgi?id=772345https://bugzilla.gnome.org/show_bug.cgi?id=772348
Calling eglGetDisplay forces libEGL to guess what kind of pointer you
passed it. Different EGL libraries will do different things here, and in
particular glvnd will do something different than Mesa. Since we do have
an API that allows us to explicitly type the display, use it.
The explicit call to eglGetProcAddress is working around a bug in
libepoxy 1.3, which does not understand the EGL concept of client
extensions. Since it does not, the normal epoxy resolver for
eglGetPlatformDisplayEXT would not find any provider for that entry
point, and crash when you attempted to call it.
Signed-off-by: Adam Jackson <ajax@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=772415
EGLDisplays are already opaque pointers, and eglGetDisplay returns an
EGLDisplay not a pointer to one.
Signed-off-by: Adam Jackson <ajax@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=772415
We currently beep when a character is appended at the end in
overwrite mode. That is obviously not right. Patch based on
a patch by Ian MacDonald.
https://bugzilla.gnome.org/show_bug.cgi?id=772389
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
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 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.
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
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.
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
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.
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
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
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 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.
: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
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
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.
This matches the behaviour of Mutter, Metacity and traditional X11
window managers on the window manager side, and is what we want
for at least gnome-terminal. I can't think of any reason why we'd
want incremental resize in any other tiled window.
Signed-off-by: Simon McVittie <smcv@debian.org>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=760944https://bugzilla.gnome.org/show_bug.cgi?id=755947
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
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
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.
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.
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.
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
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
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.
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.
