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.
Its not really reasonable to handle failures to make_current, it
basically only happens if you pass invalid arguments to it, and
thats not something we trap on similar things on the X drawing side.
If GL is not supported that should be handled by the context creation
failing, and anything going wrong after that is essentially a critical
(or an async X error).
This is a new function that gets called every time we're drawing
some area in the Gtk paint machinery. It is a no-op right now, but
it will be required later to keep track of what areas which
we previously rendered with GL was overwritten with cairo contents.
When the searchbar is hidden, a 1-pixel-high piece of it is
still peeking out, because visible widgets are always allocated
at least 1x1. Work around this by setting child-visible to FALSE
in this situation.
https://bugzilla.gnome.org/show_bug.cgi?id=724096
The last change accidentally removed the later restore, and
left the earlier, so we ended up with a restore-save sequence.
Thankfully, GtkStyleContext warns about this.
There is not much room in the inspector window; squeezing a
tree and a detailed view in the same page is not great. Instead,
make the details a separate page.
When a drive is ejected or a volume unmounted the current directory
doesn't change most of the times being empty or being a directory that
user shouldn't take care about, like /run/media
Seems more useful to change to $HOME directory in that case so the user
can see something useful and familiar just after unmounting.
https://bugzilla.gnome.org/show_bug.cgi?id=737983
Currently we change the current location if we click the eject button of
a mount.
Check whether the user actually clicked the eject button and don't
change location in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=737983
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.
