Implement and use solid-csd decoration style to get window offset when solid-csd is used by mShell toplevel window.
Also does not apply margin (resize handler sizes) on popup window as well as Gtk+ do in get_shadow_width().
MozReview-Commit-ID: 9xozp9CCVJj
When system titlebar rendering is disabled and we're in CSD window mode, the window decorations are
rendered by client (application/Gtk) and we don't get _NET_FRAME_EXTENTS property (decoration size) update
for our toplevel window.
So we need to calculate the decoration/shadow size as Gtk+ does, we emulate get_shadow_width()
which is not exported by Gtk+.
MozReview-Commit-ID: K7o2rUPt6Yc
Some themes (Ambiance for instance) uses first-child/last-child css selectors
to style titlebar buttons. Ubuntu Ambiance theme places titlebar buttons closer
by negative margin applied to them.
We put titlebar buttons to GtkBox as well as Gtk+ does and also keep
the button order here to match first-child/last-child selectors. It also means
we must have maximize/restore as one button to keep the correct order.
MozReview-Commit-ID: 9mqljOa4Vu7
Render titlebar button icons as a part of -moz-window-button-* appearence. It allows us to
theme the icons accordingly. We add a GtkImage widget to header bar buttons as Gtk+ does and
store icon pixel data there and render it at moz_gtk_header_bar_button_paint() as a part
of the buttons. It means that the toolbar buttons are not containers and
moz_gtk_get_widget_border() returns zero border for them.
Also implement GetToolbarButtonMetrics() per button.
MozReview-Commit-ID: gkAu3VmE3q
Although this is only known to affect buttons with builtin child widgets, it
is difficult to audit all GTK widgets for similar situations, and so the same
defense is applied to all widgets.
MozReview-Commit-ID: LMVXX3UYqR9
This makes balancing with gtk_style_context_restore()/ReleaseStyleContext()
unnecessary, and the style resolution cached in the style contexts is not
invalidated so frequently.
MozReview-Commit-ID: BKwyqoQsjv2
The style context for MOZ_GTK_TEXT_VIEW is now created by copying from the
widget instead of caching a widget and using its context.
No rendering changes are expected, unless themes are animating GtkTextView
backgrounds.
MozReview-Commit-ID: 9aW61kMkKcb
This makes balancing with gtk_style_context_restore()/ReleaseStyleContext()
unnecessary, and the style resolution cached in the style contexts is not
invalidated so frequently.
MozReview-Commit-ID: BKwyqoQsjv2
This makes balancing with gtk_style_context_restore()/ReleaseStyleContext()
unnecessary, and the style resolution cached in the style contexts is not
invalidated so frequently.
MozReview-Commit-ID: BKwyqoQsjv2
This was needed in GTK2 to get the style of the widget, but styles are almost
independent of widgets with GTK3, where realizing is not necessary to get the
style context.
MozReview-Commit-ID: GtL2FLDl9uA
This is necessary for GTK to match CSS rules against classes on ancestor nodes
of style contexts constructed from paths.
It can be tested with the following in ~/.config/gtk-3.0/gtk.css
tooltip.background label {padding: 100px;}
MozReview-Commit-ID: EUQ9ndeSl1Z
instead of using the context belonging to a widget.
Only the style context is cached, instead of the whole widget.
Using the style context from a widget meant that rendering displayed the
initial appearance of animations after state changes, but there was no
invalidation to trigger the final rendering in the animations.
Style contexts constructed from paths do not incorporate animations.
(See gtk_css_path_node_update_style() in GTK.) Therefore they provide the
appropriate rendering for Gecko's model, which is not expecting animations.
There is no mechanism available to display animations when using style
contexts constructed from paths, but the GtkWidget animation design is also
not suitable for rendering potentially multiple elements each in a different
state of their animation.
This contexts-from-paths approach can be extended also to other widget types,
but this is a smaller change intended for uplift to other branches to address
a regression in menuitem rendering.
MozReview-Commit-ID: EFV7swWQtm4
CreateStyleForWidget() then provides the same behavior with
g_style_context_save() as contexts from widget root style nodes.
MozReview-Commit-ID: 6lRCp3XOoRr
The Gtk 3.20 scrollbars has moved towards usual box model. The scrollbar,
trough,thumb and scrollbar button can now have margin, padding and border set,
different for each direction (ie. left, right, bottom, top). The scrollbar
metrics become ignored in Gtk 3.20 and later.
* Draw scrollbar element [for GTK 3.20+]
* The border for scrollbar, trough, thumb and scrollbar buttons is newly
calculated as margin+padding+border [for GTK 3.20+].
* The margin is subtracted for scrollbar, trough and sb buttons during paint
function [for GTK 3.6+]
* All scrollbar widget's borders transfered from
nsNativeThemeGTK::GetWidgetBorder to the moz_gtk_get_widget_border.
* Added helper function NativeThemeToGtkTheme for mapping mozilla's widget type
to the gtk widget type.
* Scrollbar troughs are now drawn even when there is not enough room for
the thumb [GTK 3.20+]
MozReview-Commit-ID: jd2q67gKM1
