Instead of making assumptions about enum value ordering,
introduce a helper function to determine policy values
for which the scrollbar may be visible.
Add a new policy, GTK_POLICY_EXTERNAL, which hides the scrollbar,
but does not force the scrolled windows size to be determined by
its child. This can be used to keep two scrolled windows in sync,
while sharing a single scrollbar.
https://bugzilla.gnome.org/show_bug.cgi?id=730730
As an actionable (inherited from GtkButton), a GtkMenuButton
should not set its own sensitivity when it has an action-name
set, but just follow the enabled state of the associated
action.
https://bugzilla.gnome.org/show_bug.cgi?id=738083
Dimmed inner colorswatch shadow to make brighter colors looks nice,
increased the padding to make button states more evident, 0 border
radius to match the padding change and no colorswatch shadows when
the button is insensitive.
The code did weird things with drawing backgrounds sometimes but not
really. Now it does this:
(1) render a background
(2) render a frame
(3) render an icon
- if no icon exists, draw the generic handle icon
We want to render a background *and* the current color (if there is
one).
This also adds a custom function gtk_render_add_content_path() which
adds the path of the current content area to a cairo_t.
This adds a CSS box (complete with padding and border) for the icon. The
box is even drawn when no icon is present. Use the ".image" as the style
class here instead of -active-color-badge.
Use this box to draw the circle around the selection icon in Adwaita.
auth_info should be a NULL-terminated array as it is used in
e.g. g_strdupv invocations iterating over its elements until
a NULL element is encountered.
https://bugzilla.gnome.org/show_bug.cgi?id=737777
This is a convenient shortcut for a common case. It is implemented
by adding a .monospace style class to the text view, and letting
the theme decide about the monospace font to use.
Same here: We need to synchronize the visible child with the
selected row when setting a stack on the sidebar. I've noticed
this problem in the sidebar example in gtk3-widget-factory.
Drawing text with Pango is quite expensive, and drawing text and also
blurring it is *really* expensive. To prevent us from drawing a lot of
text and then blurring it a lot is *really* expensive.
We now cache the blurred pixels for the last layout and shadow we made,
which means we can repeatedly draw labels with a blurred text-shadow
extremely fast.
To detect whether the shadow is up-to-date, we track the serial of the
PangoLayout alongside the radius of the box shadow. We don't support
inset shadows nor spread on text-shadow, so we don't need to track
these.
We get multiple notifications from the bookmark manager when
something changes. Every time, we reconstruct the sidebar contents
completely, by clearing the store. The bookmarks are added with
async calls though, and the code was forgetting to cancel outstanding
async requests, leading to multiple instances of the same bookmark
getting added. Use the cancellable we already have to prevent that.
This could be made much more efficient by not recreating the entire
sidebar quite so often (3-5 times for a single bookmark rename).
https://bugzilla.gnome.org/show_bug.cgi?id=737679
I've noticed a missing image show up in my print dialog, where
the printer reported "printer-paused" as icon. Rearrange things
so we always fall back to "printer" for printer icons.
We still need to possibly scan the toplevel after selecting
a widget, since we don't monitor the list of toplevels, so
the window may not be in our tree yet. This was broken in
commit e7bd73f2b0.
These turned out to break existing ui files, concretely
GWeatherLocationEntry was no longer guessed correctly.
Update the testcases to reflect this, and add a testcase
for GWeather.
- gtk_style_context_get_background_color()
- gtk_style_context_get_border_color()
Those functions shouldn't be used anymore, because they don't represent
anything from the CSS styling we support. The background color often
isn't used due to background images and there are actually 4 different
border colors (1 for each side) - if there isn't also a border image in
use.
Instead of drawing a gradient in the background color, draw a CSS box.
And change the theme so instead of setting just a background color it
draws a gradient.
The resulting visuals are the same.
Instead of drawing text for selections and links manually, use the
gtk_render_background() and gtk_render_layout() functions.
As a side effect, this allows shadows on selected text and links
and real backgrounds (like gradients or images), too.
I tried asking but nobody knew why it is necessary to set the background
color of the first cell. It seems with CSS styling this is completely
unnecessary.
This fixes shadows that are animated not updating the clip of the widget
they are drawn on. An example of this are the buttons in the CSS shadows
example in gtk-demo.
Reftest included
With buttons at the bottom, things were not looking good here:
no spacing, and a gray background. Add spacing, and put the buttons
on the white background.
It turns out that GtkBuilder will sometimes set a property
twice. Normally, this is harmless, but for GtkRadioButton:group,
it triggered a critical. Remove that.
Remove checks for NULL before g_free() and g_clear_object().
Merge check for NULL, freeing of pointer and its setting
to NULL by g_clear_pointer().
https://bugzilla.gnome.org/show_bug.cgi?id=733157
When allocated more than the requested height, GtkCalendar
was 'falling apart'. Not only was the main part rendered
at the far end of the allocation, clicking on days was
broken in this scenario.
Fix this by always placing the main part directly under
the header and day names.
https://bugzilla.gnome.org/show_bug.cgi?id=737670
Context menus inherit their style from the widget they are attached
to. This can have unexpected effects in particular for font, as can
be seen in gedit or gnome-calculator. Prevent this by resetting
the font of context-menus to the initial value.
GtkSidebar behaves internally much like GtkStackSwitcher, providing a vertical
sidebar like widget. It is virtually identical in appearance to the widget
currently used in GNOME Tweak Tool.
This widget is connected to a GtkStack, and builds its own contents as a
GtkListBox subclass, using the "title" child property to provide a consistent
navigatable widget.
Being a subclass of GtkListBox it benefits immediately from strong keyboard
navigation, and minimal changes are required for theming.
https://bugzilla.gnome.org/show_bug.cgi?id=735293
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
Since it turns out that x/yalign can't be quite equivalently
replaced by h/valign, bring them back as label properties, so
we can eventually get rid of GtkMisc.
https://bugzilla.gnome.org/show_bug.cgi?id=735841
This adds both a compile time check for the SDK version being
compiled against, as well as a runtime check in the case the
resulting binary is run against an older SDK.
https://bugzilla.gnome.org/show_bug.cgi?id=735054
Add some docs/example about the possible event handling ordering issues
that may appear on GtkGesture::begin between multiple gesture groups.
Mostly relevant for state changes.
The remaining code assumes that the dialog doesn't get destroyed, but
it actually does on delete-event.
In particular, the filter function and the preview text are lost as
soon as the dialog is created and thus when we create a new dialog we
don't have those properties to set on it anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=719936
Factor out the typename-to-get-type mangling as a separate
function, for easier testing.
Also fix some cases where it doesn't, currently, like
GString -> g_string_get_type and
GdkRGB -> gdk_rgb_get_type
The scale in the selectable listbox in page 2 of gtk3-widget-factory
has the flaw that the row is getting selected even when one only
interacts with the scale - unlike e.g. the checkbutton and button
further down in the listbox.
The problem is that GtkRange is trying to claim the sequence for
the drag gesture from the ::pressed handler of a multipress
gesture. Since the drag gesture hasn't seen the sequence at this
point, that is ineffective.
The fix here is to rearrange the gestures so that the multipress
gesture sees the sequence before the drag gesture, and then
claim the sequence from the ::drag-begin handler.
Binding signals can return a boolean indicating whether they
handled the event. Use that here and return FALSE if the
inspector keybinding is disabled.
When closing the inspector before the main window, we must take
care to sever all signal connections and weak refs, otherwise
things will go bad when the window is closed later.
When GtkGestureMultiPress::released happens, in_button should be unset
after emitting GtkButton::released, whose default implementation uses it.
Moreover, in_button should only be unset there for real touch events, not
guaranteed to trigger crossing events, as opposed to every pointer/touch
events from touchscreens.
https://bugzilla.gnome.org/show_bug.cgi?id=737297
Instead of hardcoding these actions, consult the settings.
Note that not all of the actions supported by gnome-shell are
implemented here, only maximize, minimize, lower, and menu.
https://bugzilla.gnome.org/show_bug.cgi?id=729782
These match the GSettings that mutter/metacity/gnome-shell have
for this. We change the default for the middle-click action to
none, since lower is just a terrible default.
We're slightly bending the rules here, since we're adding new
settings after .0, but a) it is just barely after .0, and b) settings
are not really application API.
https://bugzilla.gnome.org/show_bug.cgi?id=729782
Some recent refactoring changed things so that in_button is no
longer TRUE when released() is called for touch events. As a minimal
fix, let GtkButton do more of the work by chaining up to its
pressed and released handlers, which know how to handle touch
events. This could be further improved by leaving more of the
state handling to GtkButton, like it was done for GtkToggleButton.
A popover can go unmanaged for 2 reasons, when the widget it points to
gets destroyed, or transitionally in gtk_popover_set_relative_to(). In
both of these cases it makes sense to only unset popover information
about the previous widget managing it, if the popover is meant to
survive the unmanaging through extra refs.
Also, the focus widget prior to a modal popover being shown is considered
information about the relative_to widget, unset it on
gtk_popover_update_relative_to() with the rest.
https://bugzilla.gnome.org/show_bug.cgi?id=736193
This gives an opportunity for implementations to handle these events
differently, instead of hardcoding the WM-triggering behavior.
gtk_window_event() only forwards events for WM management if the event
widget is not the window (ie. caught when bubbling), so is safe to be
called here without triggering gtk_window_handle_wm_event() twice.
This commit is an adaption to master of
https://bugzilla.gnome.org/show_bug.cgi?id=736702#c1 by Cosimo Cecchi.
On regular scrolling (ie. not natural scrolling), positive deltas in the
Y axis (downwards) should actually move the value towards the adjustment
minimum value to be more intuitive. This also makes the scrolling
directions match between the button and the popped up scale.
https://bugzilla.gnome.org/show_bug.cgi?id=736830
Settings have a little more metadata than plain properties. They
can come from different sources. Make this information available
so we can show it in the inspector.
https://bugzilla.gnome.org/show_bug.cgi?id=736971
For symbolic icons, we prefer symbolics in inherited themes over
generic icons in the theme itself. So far this was implemented
by looking at icon_name[0] and looking that up in inherited themes
if it is symbolic. But with automatic rtl/ltr handling, the first
icon name will always have an -rtl or -ltr suffix, and an icon
with that suffix is not going to exist in most cases. To fix this,
look for shorter icon names too, as long as they are still symbolic.
https://bugzilla.gnome.org/show_bug.cgi?id=737000
Otherwise, they might not be properly set before the window is mapped.
For the opaque region and border window, it means that they won't get
set before the next size allocation, which tends to not be a bit deal.
For the shadow width, though, _GTK_FRAME_EXTENTS has a different meaning
when it's set before the window is mapped, so we need to make sure that
it's properly set when the window is mapped.
- Move the class to the Deprecated section.
- Warning at the bottom of the class description.
- A missing property was not marked as deprecated.
- Update doc of gtk_container_set_border_width() to not mention
GtkAlignment.
https://bugzilla.gnome.org/show_bug.cgi?id=736622
This allows us to access otherwise hidden windows, which can be
useful to provide better debug information than would be available
through other means.
https://bugzilla.gnome.org/show_bug.cgi?id=736557
There was some X11-specific code before an early exit
in the functions that grab and ungrab keys during DND.
It seems to not cause a problem under Wayland, but moving
it out of the way seems right anyway.
If the query fails because it has been cancelled, it means that
dispose() has been called, so don't try and update anything.
This fixes a segfault with Nautilus in certain situations.
https://bugzilla.gnome.org/show_bug.cgi?id=736512
fr(bepo) XKB keymap sends dead_stroke with AltGr+l keys
and gtk-im-simple-context should send '/' with
dead_stroke+dead_stroke keys but gtkimcontextsimpleseqs.h
was not sorted in the descending order and failed to get
dead_stroke.
Also need to add dead_currency for Shift+AltGr+e and
dead_belowcomma for Shift+AltGr+Cedilla.
https://bugzilla.gnome.org/show_bug.cgi?id=736250
This is an expected keybinding, and it is not hard to support.
Note that we use a private ::escape signal instead of using
::cancel directly, since we want to be able to suppress the
cancellation when we are on a progress page.
https://bugzilla.gnome.org/show_bug.cgi?id=579625
When closing the application window before closing the inspector window,
the selected widget will be set to NULL once and all the property pages
will try to g_object_weak_unref that NULL widget, so bail out in
gtk_inspector_prop_list_set_object if it's NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=736201
When GtkApplicationWindow has a menubar, we don't chain up
to the GtkWindow size_allocate, which used to position the
popovers. Move that to _gtk_window_set_allocation() which
is always called by GtkApplicationWindow.
https://bugzilla.gnome.org/show_bug.cgi?id=736205
... just because there is no style context instantiated yet. Instead,
instantiate a style context during realize() and ask it.
Fixes problems with dim labels not being dimmed on first show.
Testcase included.
https://bugzilla.gnome.org/show_bug.cgi?id=735240
Just pretend that the main widget is an empty widget the size of the
overlay.
Makes it possible to write testcases where no size requests are run on
overlay widgets before size_allocate() is called.
Testcase included.
(gnome-shell-extension-prefs:22382): GLib-GObject-WARNING **: invalid cast from 'GtkInvisible' to 'GtkWindow'
(gnome-shell-extension-prefs:22382): Gtk-CRITICAL **: gtk_window_set_transient_for: assertion 'parent == NULL || GTK_IS_WINDOW (parent)' failed
#1 0x00007fffeeb81a12 in g_log (log_domain=log_domain@entry=0x7fffeeea3464 "GLib-GObject", log_level=log_level@entry=G_LOG_LEVEL_WARNING, format=format@entry=0x7fffeeeaa878 "invalid cast from '%s' to '%s'") at gmessages.c:1079
#2 0x00007fffeee9c2a9 in g_type_check_instance_cast (type_instance=0xb314c0, iface_type=iface_type@entry=9020048) at gtype.c:4021
#3 0x00007ffff0a06e25 in gtk_tooltip_set_last_window (tooltip=tooltip@entry=0xbb8c10, window=<optimized out>) at gtktooltip.c:910
#4 0x00007ffff0a08dfd in _gtk_tooltip_handle_event (event=event@entry=0xbf72c0) at gtktooltip.c:1538
#5 0x00007ffff090d7a9 in gtk_main_do_event (event=0xbf72c0) at gtkmain.c:1785
#6 0x00007ffff0496ab2 in gdk_event_source_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at gdkeventsource.c:364
#7 0x00007fffeeb7a8c3 in g_main_dispatch (context=0x807300) at gmain.c:3067
https://bugzilla.gnome.org/show_bug.cgi?id=736131
The "too dark" background was caused by box-shadow inherited by
window-frame.csd, so box-shadow: none and the right background
color on tooltip selector.
This is a temporary workaround for scrolling units being amplified
on quartz, due to the assumption that smooth scrolling deltas are
always in some abstract unit similar to the one from xi2.
A proper solution for the situation is described in bug #736121, but
since we are close to release, this patch solves the issue temporarily.
https://bugzilla.gnome.org/show_bug.cgi?id=736121
