This helps isolate the inspector from some of the changes that
it can trigger. To specify a different display, set
GTK_INSPECTOR_DISPLAY to the name of the display to use for
the inspector window. If no display is specified, GTK+ will
use a separate connection to the default display.
When a new screen is set on a window, we unrealize it, to
recreate all the resources. But we don't reset the client_decorated
flag, so realize() doesn't call create_decoration() - which makes
sense, since the decoration already exists. But the side-effect
of create_decoration() is to select the rgba visual, and visuals
are per-screen.
Fix this by looking for the rgba visual in set_screen(), and
replacing it with the rgba visual for the new screen, if necessary.
This special code was added back in the days when computation wasn't
idemptotent. These days it is.
Also, the bypass code path is only used in fallback code that is pretty
much unused.
This is what the old adwaita did, not having a better solution for
removing double borders, better to have this back even if it can
be problematic in certain cases.
... and make it the default. This takes over the meaning from "none" for
this property in that it draws the fallback builtin image.
"none" now literally means no image will be drawn.
This commit adds a mode to GtkScrolledWindow in which it puts
narrow, auto-hiding scrollbars over the content, instead of
allocating room for the scrollbars outside of the content. We
use traditional scrollbars if we find a mouse or if overlay
scrolling has explicitly turned off.
For test purposes, GTK_TEST_TOUCHSCREEN can be used to get
overlay scrolling even in the presence of a mouse. The
environment variable GTK_OVERLAY_SCROLLING can also be used
to force overlay scrolling on or off.
This will be used to identify a scrollbar is being dragged - we
don't actually need the style class; another way to keep track
of the dragging status would be ok too.
When a getter function (like get_color()) is called and the passed in
state doesn't match the current state returned via get_state(), we used
to do a trick: We called save()/set_state() on the context before
getting the values.
Unfortunately, since 3a337156d1 this
has the unfortunate side effect that it also creates a child element.
This breaks various old codebases (spinbutton has been fixed in
998feeb2bc, Webkit is fixed in
https://bugs.webkit.org/show_bug.cgi?id=137803 ) unfortunately.
So instead, look up the values manually ensuring that no child element
is created but the correct state is used.
Keeping them is a bad idea now where the widget paths are actually
changed by a save(). And almost all of the time, state or style classes
will be changed anyway.
Looking them up again is just a hash table lookup anyway.
GtkCssNodeDeclaration is a new struct with copy-on-write semantics.
It encapsulated the properties used to define a node in the CSS tree.
The idea is to use it in various places for caching, in particular as
key in hash tables.
This signal is emitted whenever user scrolling hits the overshoot
edge in the given direction. May be useful to add "reload" or "load
more" behaviors in apps.
https://bugzilla.gnome.org/show_bug.cgi?id=738534
With my latest changes we have a darker text color for views and
entries (which I assume are content), the places sidebar is totally
chrome though so it needs the chrome text color back.
This can be used by applications to indicate that a paned is expected
to be actively used by the users for configuring the UI, and needs
a prominent handle.
https://bugzilla.gnome.org/show_bug.cgi?id=738860
Implement Federico's suggestion:
In single-selection mode, just use the selected row,
In multi-selection mode, use the cursor row as long as it is
in the selection.
https://bugzilla.gnome.org/show_bug.cgi?id=154709
There are legit reasons for GtkGesture::handle_event to return FALSE,
GtkGestureSingle objects should be unsetting the current button/sequence
if that happens, in order to avoid inconsistent states.
https://bugzilla.gnome.org/show_bug.cgi?id=738591
When gtk_window_set_titlebar (win, NULL) is called, we were taking
an early exit and forgot to re-map the window. This does not normally
happen in practice, but glade is about to get a 'csd' switch which
lets one toggle back and forth between titlebar and no titlebar.
With the recent save-is-child changes, using
gtk_style_context_get_padding (context, different_state)
will now open a subelement.
This is not what we want, so we check the state whenever we get the
button contexts.
Now it's based of fg color, so the list row gets darker on the
bright variant and brighter on the dark variant, similarly to what
we do for spinbutton buttons.
Flat buttons gets the button decoration on hover, while transitioning
the decorations of adiacent flat buttons are both shown (one fading in
and the other fading out) so the borders clashes, since normally there's
no spacing between them, to avoid it the transition on the normal state
is set to none and added back to the hover state, so the decoration
won't fade out. To make the transition more evident the duration is
increased.
This is a change for how CSS is applied.
Previously, subelements (I'll take GtkEntry icons as an example) were
treated as having the same parent as the regular elements. So a selector
such as
.entry
would match an entry inside a window. But it'd also match the icon image
inside the entry. So CSS like
.entry { padding: 10px; }
would add 10px of padding to both the entry itself and to the icon image
inside the entry, so the icon would effective have 20px padding. To get
around that, one would have to unset it again like so:
.entry { padding: 10px; }
.entry.image { padding: unset; }
This is getting more and more of a problem as we make subelements
respect more properties that aren't inherited by default anyway, like
backgrounds and padding/margin/border.
This patch has one caveat though: It makes calling
gtk_style_context_save() the first time have an important side effect.
It's important to audit code to make sure it is only used for
subelements.
And last but not least, this patch is only useful if code unsets
parent's style classes that it doesn't want to apply any longer. Because
style classes are inherited by default (and I don't think we want to
change that), the example will still apply until the subelements no
longer contain the .entry style class.
If the menubar has an app-menu popover, and it is shown at the time of
disposing the window, it will attempt to transfer focus back to the
previous focus widget when undoing modality, even though the dispose()
code already did set_focus(NULL) previously.
At the time the popover is removed, there aren't many hints as to whether
the toplevel or the focus widget are being destroyed (ie. not still under
in_destruction), so just swap the order of these two calls.
For every other popover, this would all happen within dispose/destroy,
which is handled better.
This way we don't have to clear/refill the model every time but can keep
the existing model and only update the values.
A nice side benefit is that running an update keeps the current selection.
