Under Wayland, fullscreen/maximized windows may not cover the entire
area when a size increment is specified.
Ignore size increments for fullscreen/maximized windows just like most
window managers do under X11 so that windows with size increments can
still be fullscreen or fully maximized under Wayland as well.
https://bugzilla.gnome.org/show_bug.cgi?id=751368
Since 740bcf5, we use these properties to properly compute shadow widths
for unmapped windows. If a client calls gtk_window_maximize and a window
manager unmaximizes a window, we should draw borders, so we need to
reset these when we get the property notification.
This queues an unnecessary resize on the toplevel, and is not needed
anymore, now that GtkWidget does not call
gtk_style_context_set_background() on the window's GdkWindow anymore.
The WM isn't aware of O-R (popup) or offscreen windows. If somebody
maps an offscreen or a popup GTK+ window before the main window, we'll
complete the sequence before a "real" window is mapped. Make sure to
ignore these for startup notifies.
Don't add the container border to the title request size; it
is only used for the child widget.
Don't call gtk_widget_get_preferred_width_for_height() for
the title bar with an unrelated height and subtract the title
bar height before querying the child widget width.
Guard against negative size requests after substracting the
borders/shadows and the title bar.
https://bugzilla.gnome.org/show_bug.cgi?id=751341
In the non-CSD case we checked for 0x0 window size requisition
and replaced it with 200x200 so the window was still visible.
This no longer works in case of CSD as the shadow and title bar
are always added to the requisition resulting in a titlebar/shadow
only window in case there is no child widget (this is currently
visible under wayland or when setting GTK_CSD=1).
Instead of special casing the final window size, special case
the child requisition paths instead. This gives us the same
requisition in both, CSD and non-CSD cases (the header bar
has a too large minimum width atm so the resulting window is
still not the same)
https://bugzilla.gnome.org/show_bug.cgi?id=751341
This error resulted in warnings like
"pixman_region32_init_rect: Invalid rectangle passed"
In case the window is smaller than handle_size * 2 the resulting
edge window got a negative size. Prevent that by limiting the
handle size to half the respective edge length. This also
prevents the corner windows from overlapping in case the window
is too small.
The old should_use_csd() function would return FALSE if the GTK_CSD
environment variable is unset; the change in commit c5e5ee6749
made it return TRUE if GTK_CSD is unset. This has a cascade effect
on the window size, which causes invalid rectangles to bubble down
to Pixman.
https://bugzilla.gnome.org/show_bug.cgi?id=751140
This will be the widget that the popover relates to (::pointing-to in
GtkPopover, ::parent in GtkTextHandle).
Additional API to check the popover/parent relationship between widgets
has been added, which will be useful wherever this is necessary in a
generic manner.
https://bugzilla.gnome.org/show_bug.cgi?id=750993
The change in 03213b9509 changed the rules
as to when CSD can be enabled, but it also unconditionally enables CSD
with the implicit assumption that client-side shadows were the real
issue, and that we could work around that by drawing our own borders.
This also means that setting a titlebar for a GtkWindow will enable CSD
unconditionally.
In reality, some window managers (like Matchbox) *only* support
server-side decorations, and will ignore all hints to the contrary, to
the point of drawing decorations at random locations on top of the
window.
Since CSD are enabled unconditionally, the GTK_CSD environment variable
is also not a suitable escape hatch.
In the grand tradition of asking ourselves if we should do something
just because we can, we should split the environment checks from the
checks on what the user requested; by doing that, we can also check
when enabling client-side decorations, and ideally bail out if needed.
https://bugzilla.gnome.org/show_bug.cgi?id=750343
Even if a window doesn't support client side shadow
(gtk_window_supports_client_shadow returns FALSE), don't assume the
shadow width is zero, as CSD may have been enabled anyway (meaning
priv->client_decorated is TRUE). In that case we still need to report
the correct width.
https://bugzilla.gnome.org/show_bug.cgi?id=749451
If CSD is enabled with shadow even though it "shouldn't"*, the width
should still be calculated correctly. This fixes a regression caused by
b1e5ad469c.
* gtk_window_should_use_csd () returns false
https://bugzilla.gnome.org/show_bug.cgi?id=748615
The window state 'client_decorated' will only be set the window is being
realized. If anyone tries to get the shadow size before that it'd get
the with as if there always was no shadow.
This avoids negative sized opaque regions caused by the allocation being
smaller than shadow.
https://bugzilla.gnome.org/show_bug.cgi?id=748615
Requires Vista and newer.
* Create surfaces with cairo_win32_surface_create_with_format
* Provide an rgba visual that can be distinguished from the system visual
* Make rgba visual the best available visual
* Enable alpha-transparency for all windows that we control
* Check for appropriate cairo capabilities at configure time
(W32 - 1.14.3 newer than 2015-04-14; others - 1.14.0)
* Check for composition support before enabling CSDs
* Re-enable transparency on WM_DWMCOMPOSITIONCHANGED
Windows that were created while composition was enabled and that were CSDed
as a result and will look ugly (thick black borders or no borders at all) once
composition is disabled.
If composition is enabled afterwards, they will return back to normal.
This happens, for example, when RDP session is opened to a desktop where a GTK
application is running. For W7/Vista windows will only re-gain transparency after
the RDP session is closed. For W8 transparency will only be gone momentarily.
Windows that were created while composition was disabled will not be CSDed
automatically and will use SSD (WM decorations), while windows that are CSDed
manually will get a thin square border.
If composition is enabled afterwards, these windows will not change.
This is most noticeable for system menus (popup menus are often generated
on the fly, system menus are created once) and some dialogues (About dialogue,
for example).
https://bugzilla.gnome.org/show_bug.cgi?id=727316
Instead of issuing g_warning, fill the provided GError.
This lets us test this error handling, and is the right
thing to do. Use the new GtkBuilder helpers and
g_markup_collect_attributes to do so.
To calculate the shadow width, we look at the value of priv->fullscreen
and priv->maximized.
Those fields will have the actual value only after GTK receives back a
window state event though, so they will be wrong in _realize(). Look at
priv->fullscreen_initially and priv->maximize_initially too, to avoid
the size changing right after realize, which would make the window
flicker if maximized at startup.
https://bugzilla.gnome.org/show_bug.cgi?id=747808
It turned out that using mwm hints to instruct wms to
create border-only decorations is not really working
universally. So, instead of doing this, render a solid
frame without shadow on the client-side to handle this
case.
https://bugzilla.gnome.org/show_bug.cgi?id=746222
Signed-off-by: Olivier Fourdan <fourdan@xfce.org>
On popover_unmap(), perform the gtk_widget_unmap() call last, so the
GtkWindowPopover data is ensured to be alive throughout the function
if the popover widget is destroyed right on ::unmap.
https://bugzilla.gnome.org/show_bug.cgi?id=745829
Now that this is split in two separate gestures, both must be reset
when the WM grabs the pointer. Also, do on resize drags like on move
drags, and claim the gesture before resetting, so the ownership is
properly transferred across any other widgets.
https://bugzilla.gnome.org/show_bug.cgi?id=745969
This reverts commit fb9a6bb6d8.
In a recent test, I've found that Xfce and Mate now support
this, so they will not be affected by this requirement. And
adding the check back will solve the 'client-side shadow'
problem in KDE.
Postpone until the last moment whether the target widget still
potentially uses updates from this sequence, or window dragging
actually applies because all gestures on the target went to denied
state.
This fixes window dragging on empty space in a headerbar that is
contained in a paned (as in e.g. gedit).
https://bugzilla.gnome.org/show_bug.cgi?id=745562
The gesture is hooked to the capture phase, so it works for buttons in
header bars and whatnot. In order to be friendly to the widget it is
capturing events from, an ugly hack is in place to avoid capturing
events when the target widget has a gesture that would consume motion
events.
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.
If the grab belongs elsewhere, the window won't claim the sequence right
away. The sequence may still be claimed afterwards when window dragging
starts, but simple clicks won't be consumed this way.
This makes it possible to close popovers when clicking on the title region,
while still permitting touch/button 1 interaction for every other purpose.
https://bugzilla.gnome.org/show_bug.cgi?id=743257
On the wayland backend, set up GDK_WINDOW_SUBSURFACE windows
for popovers. In the popover code, the popover-relative-to-parent
calculation had to be tweaked, and it's been made to always prefer
the given popover position, since there's no sizing limitations.
https://bugzilla.gnome.org/show_bug.cgi?id=738891
Currently we only take into account the window GActionGroup for
activating the accels.
However, the application could have some custom GActionGroup in the
chain of focused widgets that could want to activate some action if
some accel is activated while that widget is focused.
To allow applications to set accels on widgets that use custom
GActionGroups, simply use the muxer of the focused widget, which
already contains the actions of the parents.
https://bugzilla.gnome.org/show_bug.cgi?id=740682
