If we have an application that never goes idle (or takes a long time to
go idle), the close buttons in CSD decoration don't work properly.
While it's not clear why the usage of an idle was added in the first
place, keep on using it to avoid unexpected reentrancy problems, but
change the priority to G_PRIORITY_DEFAULT.
https://bugzilla.gnome.org/show_bug.cgi?id=768485
On X11, device_query_state() uses XIQueryPointer() which will return a
child window only if the pointer is within an actual child of the given
window.
Wayland backend would return the pointer->focus window independently of
the given window, but that breaks the logic in get_device_state() and
later in gdk_window_get_device_position_double() because the window is
searched based on coordinates from another window without sibling
relationship, breaking gtkmenu sub-menus further down the line.
Fix the Wayland backend to mimic X11's XIQueryPointer() to return a
child only if really a child of the given window.
That's the most sensible thing to do to fix the issue, but the API here
seems to be modeled after the X11 implementation and the description of
gdk_window_get_device_position_double() is not entirely accurate.
https://bugzilla.gnome.org/show_bug.cgi?id=768016
Our property parser stops at the first match when looking for
enums, so we need to order our values so that we don't end up
with prefixes of longer names being found first.
I noticed this when the parser tried to interpret
background-blend-mode: color-burn; as "color, with junk at the end".
It also affects animation-direction, which is also fixed here.
After introducing the CSS blend mode enum values and including
the background-blend-mode CSS property, it is very important to
actually provide an example of the new feature.
This patch adds a new demo to gtk3-demo which shows how the
background-blend-mode CSS property works.
https://bugzilla.gnome.org/show_bug.cgi?id=768305
CSS supports blend modes, in which a series of layers are
merged together according to the given operation or set of
operations.
Support for blend modes landed on Cairo, which exposes all
the commons and also the exquisites blend modes available.
Adding support for blend modes, then, is just a matter of
using the available Cairo operations.
This patch adds the background-blend-mode CSS enum property,
and adapts the background rendering code to blend the backgrounds
using the available blend modes when they're set.
https://bugzilla.gnome.org/show_bug.cgi?id=768305
Xfce4-session-manager added support for managing dbus based clients.
This patch adds support for checking if Xfce session manager is
around after trying the gnome one.
https://bugzilla.gnome.org/show_bug.cgi?id=693203
I was struggling to understand why calling
gtk_print_unix_dialog_set_manual_capabilities (...,0)
was not having the expected effect of hiding the preview
button. The initial capabilities were not applied at all.
This has most notably impact in selection buffers, because those were
shared across all selection atoms. This turned out wrong on 2 situations:
- Because the selection atom was set at SelectionBuffer creation time, the
GDK_SELECTION_NOTIFY events generated will have unexpected info if the
buffer is attempted to be reused for another selection.
- Anytime different selections imply different stored content for the same
target.
This is better separated into per-selection buffers, so it's not possible
to get collisions if a same target is used across different selections.
https://bugzilla.gnome.org/show_bug.cgi?id=768177
The sanitize_utf8() function has been copied from X11 so both
backends behave the same. This allows interaction with older clients
(mainly through Xwayland, and the STRING selection target) that
request non-utf8 text.
https://bugzilla.gnome.org/show_bug.cgi?id=768082
commit 0015ebc4a8 reworked
some of the titlebar size allocation code. Those changes
inadvertently introduced a warning when the application sets
the headerbar title widget to be hidden.
This commit fixes that warning.
https://bugzilla.gnome.org/show_bug.cgi?id=768184
This partly reverts 9f5b9c0e07, which
removed the check for GtkWidget-window-dragging in the multipress
gesture. This check is still needed for widgets which have this style
property set (e.g. menubars and toolbars) can maximize the window on
double click -- but those widgets which have it set to FALSE shouldn't
maximize the window.
Use G_FILE_ATTRIBUTE_FILESYSTEM_REMOTE to detect remote filesystems
instead of hardcoded list of filesystem types.
Bump required GLib version accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=767965
...or warning style class applied.
This particular style bit wasn't converted to the saner 3.20 way
so `entry:selected` used in place of `entry selection`.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=768025
we used to style infobars by using the .info, .question, .warning
and .error selectors directly, which used to be ok when we had just
styleclasses all over the place, now it needs to be more specific
or it interferes with everything with those styleclasses applied
like entries.
The header bar currently ignores the expand property on its
children. This commit changes the code to honor that property.
It divvies up any free space and distributes it equally to packed
children (with any left over space given out a pixel at a time
on a first come, first serve basis).
This commit also adds support for the title widget to be made
expandable.
It accomplishes this by using up the padding the title widget
is centered with.
https://bugzilla.gnome.org/show_bug.cgi?id=724332
In order to support the expand property on children, we're
going to need to look at the size of the packed children
on each side of the title widget, up front, before allocating
them (to compute how much extra allocation each expanded child
gets).
This commit lays the groundwork for that analysis by splitting
the size calculation of each side of the header bar outside
of the loop that allocates each child of the header bar.
https://bugzilla.gnome.org/show_bug.cgi?id=724332
With a headerbar, the widget in the center may be a label, constructed
internally, or a custom widget, constructed externally. The size
allocation code needs to handle either case the same way for the most
part. There's more than one place in the code that checks which of
the two widgets to use and does some operation on the selected one.
This commit simplifies the code by checking up front which one is the
center (title) widget and storing that in a temporary variable,
This allows reducing duplicated logic later on in the function.
https://bugzilla.gnome.org/show_bug.cgi?id=724332
There's some extraneous MIN() calls that have predetermined answers.
This commit drops them and then simplifies a few redudant checks into
one MIN call.
https://bugzilla.gnome.org/show_bug.cgi?id=724332
The size allocation code maintains an array of two elements,
to track the allocation of children packed into the two sides
of a header bar. Sometimes this array is indexed with 0 and 1,
and sometimes its indexed with GTK_PACK_START and GTK_PACK_END.
The latter happen to have the values 0 and 1, respectively, but
that's not really obvious.
For clarity, this commit changes the code to index those arrays
consistently, sticking to 0 and 1 across the board.
It's only possible to have a label or a custom title, not both.
The size allocate code confusingly treats them as independent.
That is confusing, because, as the code is written, it makes it
look like the space for the custom title isn't getting accounted
for.
This commit else-ifies some parts of the size allocate code for
clarity.
Firefox does a bunch of interesting things with GTK.
If the top-level GtkWindow does not have a "csd" style class associated,
Firefox will happily draw the contents of the container used to render
HTML and XUL directly on the top level's GdkWindow; on the other hand,
if a "csd" style class is found, the MozContainer will create a new
child window, and draw on it.
Then, Firefox will proceed to disable double buffering on both the
top-level window and the MozContainer (unless they are backed by the
same GdkWindow, in which case only the top-level will be
single-buffered) *and* it will add a GDK_EXPOSURE_MASK flag to the
MozContainer events for good measure (even if this is only needed for
GTK+ 2.x).
After landing the GdkDrawingContext API in GdkWindow, GTK enabled
automatic double buffering on all top-level windows backed by a native
surface, ad most users of single buffering rely on child widgets instead
of top-levels, and we'd still like to have the same double buffering
behaviour for all top-levels on all backends. Obviously, with Firefox
disabling double buffering on the top-level window, the change broke
their drawing mechanism.
Ideally, Firefox could be fixed to not disable double buffering on the
top-level window when MozContainer has a separate GdkWindow — i.e. the
CSD case — but since we did introduce a slight change of behaviour in
fringe users of the GTK+ API, let's keep backwards compatibility with
the old code for a little while longer, and create an intermediate Cairo
context unbound from the GdkDrawingContext, like we used to do until
GTK+ 3.20.
And ensure it's still visible before returning the keyboard focus to it.
Because of the extra ref, add a dispose handler that will ensure the
ref is lost (by popping down), although this should be already ensured
through other paths (eg. when the popup widget loses visibility).
This fixes a possible crash in dispose paths, where we might be restoring
focus on an already destroyed widget, and at a time where, if the toplevel
is being itself disposed, no new focus should be set.
https://bugzilla.gnome.org/show_bug.cgi?id=767849
If there are widget margins set, the whole popover will be displaced.
However the calculation of the tail position doesn't have this into
account, ending up with the tail being detached from the popover if
the margin grew too big.
We should not render the arrows invariably next to the GdkWindow edge,
but optionally displaced inside it depending on the widget margins.
Fixes the gtk3-demo "Popovers" demo case, whose GtkEntry popovers set
widget margins for some reason.
https://bugzilla.gnome.org/show_bug.cgi?id=767851
