| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
Unfortunately, this involves copying a bunch of
code from gtkwindow.c. The only difference here
is that we add a private method to turn this off,
which will be used by GtkPopoverMenu to implement
its own auto mnemonics.
|
| | |
|
| |
|
|
|
|
|
|
| |
Remove the special case in gtkwidget.c where we didn't draw any css
background/border for popovers. Instead, rely on themes to not style the
popover node and add a contents gizmo that gets the actual css styling.
We then requeste enough space for the popover to draw both the contents
and the arrow on the side.
|
| |
|
|
|
|
|
|
| |
Popovers may get relocations optimized away if only x/y changed
in the GtkAllocation. So make sure the toplevel updates popover
positions on all situations.
https://bugzilla.gnome.org/show_bug.cgi?id=729140
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
In practice this shape is only used to outline the popover when it is
above native windows, in the most normal full-csw case the shape won't apply
visibly, so popovers will still be able to cast a shadow there.
If there are native windows below the popover, the shape will exclude the
shadow, so there are no alpha contents above the window. One worst case that
might happen is that the popover lays above patches of native/client-side
windows, so the shadow could come and go around the border. But first let's
see whether that happens often or visibly enough before adding something more
convoluted.
|
| | |
|
|
|
Popovers no longer sets a shape, unless this function is called. This
function exists so widgets that are potentially placed on top of other
native windows can get a popover that's nicely shaped, even if it has
no border shadow around.
https://bugzilla.gnome.org/show_bug.cgi?id=723556
|
