This guarantees we only create 1 extra style cascade in total for hidpi
and not one per style context.
Style cascades are now nested like this:
GtkSettings root cascade (scale == 1)
|
+-- GtkSettings per scale cascade (for any scale, no custom providers)
|
+-- GtkStyleContext custom cascade (for any scale, custom providers)
This requires a bunch of care when changing cascade-related properties
inside GtkStyleContext, so that it ends up with a properly setup
cascade, but I think I got those cases right.
The only thing we don't do yet is reverting to a GtkSettings cascade
when the last custom provider is removed from a custom cascade.
The default ->upload_texture() works also for Windows since commit 27cf0fa,
as some of the problems described in 742953 also applied for GL core
contexts on Windows as well before 27cf0fa. Clean up the GDK-Win32 code a
little bit as a result.
This property is necessary to ensure widgets automatically update after
the text scale factor is changed desktop-wide.
And if I'm already doing a property like this, I can make it
overridable. So now you can override the dpi per-widget with CSS like
GtkSwitch {
-gtk-dpi: 48;
}
if you want to debug things.
Long-term, we want to get rid of this property and insist on dpi being
96 everywhere and people can change the font size to get larger fonts.
GPUs generally have problems when you create a 35000px wide surface.
Luckily X catches this and sends a BadAlloc. Which GTK immediately
abort()s on.
Testcase included.
https://bugzilla.redhat.com/show_bug.cgi?id=1163579
We should remove the mir and cairo surface before rendering the
transient_for, which will regenerate the cairo surface anyways.
Otherwise, we end up releasing both, when we only really want to get rid
of the mir surface.
Mouse over a parent menu[bar] didn't work while the menu was open.
The fix was to correct the behaviour of pointer crossing events so that
the pointer appears to be only inside one window at a time.
See: http://tronche.com/gui/x/xlib/events/window-entry-exit/normal.html
We need this because it fixes menu activation. The menu activation code
looks at the time between events to determine if mouse clicks happen too
quickly.
This avoids showing the scrollbars if we are positive the child widget
is being manipulated, regardless of the pointer being close to any of these.
On the next motion event after finishing the operation, the scrollbar will
be shown if necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=743894
is_visible() wasn't the right check to perform here before unmapping,
and gtk_widget_unmap() already avoids being doubly called by checking
gtk_widget_get_mapped() anyway.
