| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Empty helpers did try to draw a NULL paintable (not good) and in the
non-null case code used the wrong width/height.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This step was missed before, again.
SASS 3.6 emits rgba(0, 0, 0, 0) instead of transparent, so it wants to
change those too, but that patch was only committed in March and isn't
being backported to the previous stable, so I don't know if others'
versions will do the same - so until it's shown that anyone else (A) is
regenerating CSS and (B) also has 3.6, I'm skipping those changes. See:
https://github.com/sass/libsass/commit/c287f312ac9735aa274bbce56762391ca348cad9
|
|
|
|
| |
Expand the docs for ::register-session a bit.
|
|
|
|
| |
We can just return here.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
A number of applications want to track the state of the screensaver.
Make this information available as a boolean property. We only listen
for state changes when ::register-session is set to TRUE.
This is implemented for unsandboxed D-Bus access by talking
directly to org.gnome.ScreenSaver or org.freedesktop.ScreenSaver,
and for sandboxed D-Bus by using a (new) portal API.
A Quartz implementation is missing.
|
|
|
|
|
|
| |
When the environment variable is set, don't connect
to the session manager, but instead rely on the
inhibit portal.
|
|
|
|
| |
Less code duplication, more sticky toffee!
|
|
|
|
| |
Less code duplication, more cookies!
|
|
|
|
| |
Less code duplication, more cake!
|
|
|
|
|
| |
The paths that we create for requests and sessions
need some icky code to create. Keep it in one place.
|
|\
| |
| |
| |
| | |
Adwaita: Add color to separator.selection-mode
See merge request GNOME/gtk!309
|
| |
| |
| |
| |
| |
| |
| | |
This makes separators to look good when separating two header bars in
selection mode.
https://gitlab.gnome.org/GNOME/gtk/issues/1286
|
| |
| |
| |
| | |
This fixes a warning introduced in the previous commit.
|
| |
| |
| |
| |
| |
| | |
Don't treat it as one, it does not like it.
Closes https://gitlab.gnome.org/GNOME/gtk/issues/1297
|
| | |
|
| |
| |
| |
| |
| |
| | |
Its Hieroglyphs!
Closes: #1292
|
|\ \
| | |
| | |
| | |
| | | |
revealer: Only clip child when animating
See merge request GNOME/gtk!301
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Currently, GtkRevealer clips the child if the transition type is
sliding, regardless of whether the animation had already ended. An
example where that is a problem would be in Nautilus: the file
operations popover button is animated on reveal to draw attention, but,
given that the button is in turn stashed inside a revealer with a
sliding animation, things suddenly fall apart.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This reverts commit 749ef4d71ca018a18fd608bf3b2e4c022727e2ae.
The GtkIcon and GtkGizmo measure code is different, the former uses
-gtk-icon-size.
|
| | |
| | |
| | |
| | |
| | | |
One function to measure the box in the opposite of its internal
direction is enough.
|
| | |
| | |
| | |
| | | |
So we call it like we call it everywhere else.
|
| |/
|/| |
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
Since priv->active is equivalent to the widget state being CHECKED, we
can as well use that everywhere.
|
| | |
|
| | |
|
| |
| |
| |
| | |
And save a few lines that way.
|
| |
| |
| |
| | |
.menu-button is not a style class we use anywhere.
|
| | |
|
| |
| |
| |
| |
| | |
Especially the bounds graphene_rect_t, which is unused in the
non-border-image case.
|
| |
| |
| |
| |
| | |
It just does when the default GtkWidget implementation does anyway:
snapshot all child widgets
|
| | |
|
|/ |
|
|
|
|
|
| |
We must not call move-to-rect unless we have
a transient parent.
|
|\
| |
| |
| |
| |
| |
| | |
gtkscrolledwindow: Consider shift key presses when decelerating
Closes #770
See merge request GNOME/gtk!286
|
| |
| |
| |
| |
| |
| |
| | |
Otherwise horizontal scrolling using the shift key would decelerate
vertically.
Fixes https://gitlab.gnome.org/GNOME/gtk/issues/770
|
| | |
|
|\ \
| | |
| | |
| | |
| | | |
Kill subsurfaces
See merge request GNOME/gtk!299
|
| | |
| | |
| | |
| | | |
This is no longer used.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Instead, use a popup and gdk_surface_move_to_rect.
I have not tried to reproduce all details of the old
positioning logic, but moving the popup above/below
the entry works as before.
|
|/ /
| |
| |
| | |
A small step towards splitting up gtk/
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In order to make tooltip positioning portable, make use of the
move_to_rect API. Some semantical changes are made, as identical
semantics cannot be implemented using the move-to-rect API.
Primarily the implemented semantics are:
Position the tooltip in the center pixels slightly below (defaults to 4
units below) the tooltipped widget. This is always the case for keyboard
driven tooltips; the case where it tries to avoid the pointer cursor is
not implemented.
For pointer position triggered tooltips, implement the following
additional semantics:
Use the current cursor size to determine the padding used to enlarge the
anchor rectangle. This is to try to avoid the cursor overlapping the
tooltip.
If the anchor rectangle is too tall (meaning if we'd be constrained
and flip on the Y axis, it'd flip too far away from the originally
intended position), rely only on the pointer position to position the
tooltip. The approximate pointer cursor rectangle is used as a anchor
rectangle. Ideally we should use the actual pointer cursor rectangle
(image used as well as hotspot coordinate), but we don't have API to
get that information.
If the anchor rectangle isn't to tall, just make sure the tooltip isn't
too far away from the pointer position on the X axis.
Closes: #134
Closes: #432
Closes: #574
Closes: #579
Closes: #878
|
| |
| |
| |
| | |
Unused.
|
| |
| |
| |
| | |
Unused.
|
| |
| |
| |
| | |
Unused.
|
| |
| |
| |
| | |
It's always FALSE.
|
| |
| |
| |
| | |
The unref will already properly free the menu item's resources.
|