| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
Fetch the DESKTOP_STARTUP_ID envvar at the same point it's done
for the X11 backend, and notify the startup ID gotten on
notify_startup_complete().
|
|
|
|
|
|
| |
Add a gtk_shell.set_startup_id request, so the application can communicate
to the compositor the startup id that it received through the
DESKTOP_STARTUP_ID envvar, or other means.
|
| |
|
|
|
|
|
| |
Add the proper chain up (in preparation to actually freeing stuff) and
remove the empty dispose implementation
|
|
|
|
|
| |
Make it a field of GdkWin32Screen since that is the object exposing
all the the getters.
|
| |
|
|
|
|
|
| |
Shouldn't be needed with recent Benjamin work.
This reverts commit 79ca3f03a8de0fa0f7a846ea72d479066a15dbd7.
|
|
|
|
|
| |
Shouldn't be needed with recent Benjamin work.
This reverts commit d57f4a781cbcab7eb0912edf0ccbf811090067ce.
|
|
|
|
| |
Set GDK_BACKEND=help to see a list of all inluded GDK backends.
|
|
|
|
|
| |
This stops us from starting a lot of useless transitions. And it's even
conformant with the CSS spec!
|
|
|
|
| |
Since we do an OR afterwards, initializing to FALSE is correct.
|
|
|
|
|
| |
We check for it before anyway, and in this case make sense to show the
eject button in both cases.
|
|
|
|
|
|
|
|
|
|
|
| |
When running with a Wayland compositor which doesn't support the
xdg_shell interface, gtk+ will segfault while trying to access the
corresponding wl proxy.
Check for xdg_shell support and do not use Wayland if not present, so
that it can fallback to X11, hoping that Xwayland is usable.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=762258
|
| |
|
|
|
|
|
|
|
| |
Add a comment about the resource gtk/menus-common.ui to the
documentation of the other resources loaded by GtkApplication.
https://bugzilla.gnome.org/show_bug.cgi?id=761432
|
|
|
|
|
|
|
| |
This means all the information needed to automatically load a
shortcuts window and create a menu item to show it is in one place.
https://bugzilla.gnome.org/show_bug.cgi?id=761431
|
|
|
|
|
| |
made things properly in the process creating a sass function to
handle transition properties stacking.
|
|
|
|
|
|
| |
we use to animate "all" in the transition, this seems to trigger
some weird gtk sizing issue, restricting the transition to just
the needed properties fixes.
|
|
|
|
| |
cleaned up unneded selectors and leftovers from previous versions.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
some clean up in the process. The gradient still need some love.
|
| |
|
|
|
|
| |
The number is taken right from Wine source code.
|
|
|
|
| |
If someone figures out where the remaining pixel comes from: Tell me!
|
| |
|
|
|
|
| |
Someone needs to figure out why the default font is wrong.
|
| |
|
|
|
|
|
| |
(1) Actual Windows users don't care about it
(2) It's easier to get rid of
|
| |
|
| |
|
|
|
|
|
| |
We are passing the mount operation as argument, so use
a marshaller that expects an object argument.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were notifying when an unmount operation was performed. However,
creating notifications from the gtk+ library is not that expected, and
makes notification handling difficult to do from the application point
of view since we cannot dismiss those notifications.
This cause issues like notifications of unmount drives stay there after
a system reboot, which confuses the user.
Instead of that, remove the notification handling for mount operations
on gtk+ and instead create a new signal on the gtkplacessidebar in order
to inform applications using it about an operation about to start.
Only drawback about this is that the GtkFileChooser loses its
notifications when unmounting, that although we could use the new signal
to do it, we actually don't want to notify from any part of gtk+ for
now.
https://bugzilla.gnome.org/show_bug.cgi?id=753351
|
|
|
|
|
|
|
| |
The string "None" is used in multiple contexts; add message contexts
to give translators a chance to translate them accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=762165
|
|
|
|
|
|
| |
Some of the translated strings in the cups printbackend are short
and generic and might occur in other contexts. Give them disambiguating
message contexts to avoid translation problems.
|
|
|
|
|
|
|
|
| |
There is no point in attaching and then committing the same buffer if
there was no damage. This will also make us do less unnecessary backfill
read backs, for the cases where we paint with an empty paint region.
https://bugzilla.gnome.org/show_bug.cgi?id=762120
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a after-paint was scheduled but nothing was painted, for example when
the it was scheduled by a subsurface wanting to update its position,
we'd still try to read back from the backfill cairo surface and update
the committed cairo surface reference even though no buffer was
attached.
Fix this by adding a new state, 'pending_buffer_attached', which is only
true if a buffer was attached during frame. Only when this is true will
the backfill be read back and the committed cairo surface reference be
updated.
https://bugzilla.gnome.org/show_bug.cgi?id=762120
|
| |
|
| |
|
| |
|
|
|
|
| |
Having an ID makes it easier to style this appropriately.
|
|
|
|
| |
in the process make the focus outline clearer.
|
| |
|
|
|
|
| |
...more to come.
|
| |
|
|
|
|
|
| |
setting a 16px min-height (same as a check/radio) and resetting
margins on check/radio to workaround a sizing issues there.
|