With Bug 1613130 fixed we may not need a fallback widget so let's remove this workaround.
Differential Revision: https://phabricator.services.mozilla.com/D64052
--HG--
extra : moz-landing-system : lando
- Create header bar at GTK_WINDOW_TOPLEVEL
- Use actual header bar widget as window titlebar because gtk_window_set_titlebar() sets "csd" and "solid-csd" styles.
We need to read the styles to get correct decoration type.
Differential Revision: https://phabricator.services.mozilla.com/D59850
--HG--
extra : moz-landing-system : lando
Call gtk_style_context_set_scale() on styles created by WidgetStyleCache module on Gtk 3.20+
Also modify moz_gtk_widget_paint_* routines to pass the scale info to CreateStyleContext()
from WidgetStyleCache.
Differential Revision: https://phabricator.services.mozilla.com/D28466
--HG--
extra : moz-landing-system : lando
Gtk+ sets .left/.right classes to GtkBox element at GtkHeaderBar according to button placement (left/right).
We don't support that now so set .left at least to be compatible with themes - BlueMenta for instance.
Differential Revision: https://phabricator.services.mozilla.com/D6657
--HG--
extra : moz-landing-system : lando
We don't set gtk_header_bar_set_decoration_layout() so we don't need to query the layout
by gtk_header_bar_get_decoration_layout(). That means we don't need to create the GtkHeaderBar
at startup when titlebar rendering is disabled.
Also unify window/header bar construction at CreateHeaderBarWidget() and assert when the widgets
are already created.
Differential Revision: https://phabricator.services.mozilla.com/D5417
--HG--
extra : moz-landing-system : lando
To get correct style of GtkHeaderBar widget we need to get style of fully
occupied widget with child buttons.
When GtkHeaderBar Gtk+ style is requested create also all child elements
and then return the style.
Differential Revision: https://phabricator.services.mozilla.com/D4663
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : rebase_source : 687993d60b8f2063ed31f07ba2d7ab9f1faa09c8
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
--HG--
extra : rebase_source : 86a3f12e760194b5828afed784f6aa02c352e017
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
--HG--
extra : rebase_source : 9c31a2073d1bb247ce9d0240333143661b8ae4b8
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
--HG--
extra : rebase_source : d1df34537901342969d1e33524b414a2786df541
Based on patch by Andrew Comminos [:acomminos] <andrew@comminos.com>
MozReview-Commit-ID: 18U3GBrTyVW
--HG--
extra : rebase_source : 7a203d5c4d1856d24f08c2ea42ad4519d283ab73
Based on patch by Andrew Comminos [:acomminos] <andrew@comminos.com>
MozReview-Commit-ID: HzzXDqE0s5n
--HG--
extra : rebase_source : d929e03d7ab84229101b9c11cdb35396547860e4
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
--HG--
extra : rebase_source : d327addad8d2b0e070c6ca86c6e38271c8431a23
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
--HG--
extra : rebase_source : 4733d66f8265007555cc17568033ece09e6cb2dc
This works around a GTK bug that led to the default engine being used instead
for the first draw.
MozReview-Commit-ID: 4r48HNUgVBE
--HG--
extra : rebase_source : 83a964e02dba97cb0b52acde6b692d241c03ed57
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
--HG--
extra : rebase_source : 279c8b15e58c3f0fff51f41a4afacfebfbfa5739
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
--HG--
extra : rebase_source : 44c82ff74e1e52046799659f3bfa37c7faafeb58
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
--HG--
extra : rebase_source : 2091fc84a9ecb8b55e7d3e36e72cbd03ea826ac8
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
--HG--
extra : rebase_source : 926e6b7fee9a15fe5c86be7327c60b146db11316
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
--HG--
extra : rebase_source : 95c267c5495791a40e755aacf14a80c750fbedd2
The same name is retained for moz_gtk_widget_paint(), which is now more
consistent.
MozReview-Commit-ID: 9RtW66JQVGX
--HG--
extra : rebase_source : 3067daa4e9347cf689e9dccbd7e07578b52cf59c
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
--HG--
extra : rebase_source : 689f7340007c889ce0eaeb3b4acd228d45ad0d6d
CreateStyleForWidget() then provides the same behavior with
g_style_context_save() as contexts from widget root style nodes.
MozReview-Commit-ID: 6lRCp3XOoRr
--HG--
extra : rebase_source : ad161eef11e0dc70c8a487c204f109eceac3b1c4
Martin Stransky
Sylvestre Ledru
Jonathan Watt
Karl Tomlinson
Sebastian Hengst
Phil Ringnalda