| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
There's only one screen per display, so no need to let users select from
a list of that 1 screen.
|
|
|
|
|
| |
This avoids crashes in gtk_window_get_position() whenever the GdkWindow
is offscreen.
|
| |
|
| |
|
| |
|
|
|
|
| |
Don't pass NULL source_device in grab/ungrab events
|
| |
|
| |
|
|
|
|
|
| |
This commit implements gdk_keymap_get_entries_for_keyval
and gdk_keymap_lookup_key.
|
| |
|
|
|
|
|
|
|
| |
The test case uses a weak ref to assert objects can finalize,
and then spins the main loop shortly after finalizing to assert
that the finalized object did not leak GSources into the main context
causing latent crashes.
|
|
|
|
|
| |
I forgot to initialize directionm in gdk_wayland_keymap_new,
leading to crash.
|
| |
|
| |
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=672018
|
|
|
|
|
|
|
| |
We *do* want to call gdk_window_set_opacity() on toplevels, because
this particular case does work.
https://bugzilla.gnome.org/show_bug.cgi?id=697263
|
|
|
|
|
|
| |
We always emit direction-changed when we get a new keymap, but
for state changes, we compare old and new direction and only
emit the signal when the direction actually changes.
|
|
|
|
| |
This is very similar to the X11 implementation.
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=696767
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=696767
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=697200
|
|
|
|
| |
This is nicer then getting random sigbus later
|
|
|
|
|
| |
We were sometimes getting zero chars in the name, making them
shorter, due to an off-by-zero in the size.
|
|
|
|
|
|
| |
We were not using the old one anyway, and this may in some cases
use less memory (although in most cases the server has a ref to the
surface anyway).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the window has no mnemonics modifier set, as in the case of a
GtkMenu, never schedule a display of mnemonics on focus-in.
Previously, for those windows, the GdkModifierType mask fetched from the
device would typically have been zero, leading to the
mnemonic_modifier == (mask & gtk_accelerator_get_default_mod_mask ())
check to succeed, so we would always trigger a display for popup menus.
https://bugzilla.gnome.org/show_bug.cgi?id=697144
|
|
|
|
|
|
|
| |
Instead of having maybe_set_mnemonics_visible(), separate the checks
from the actual scheduling of mnemonics display.
https://bugzilla.gnome.org/show_bug.cgi?id=697144
|
|
|
|
|
|
|
|
| |
Don't mention "auto mnemonics", since those methods are purely about
scheduling a delayed display, and that makes understanding the code a
bit harder.
https://bugzilla.gnome.org/show_bug.cgi?id=697144
|
|
|
|
|
|
|
| |
gtk_window_set_mnemonics_visible() will try to g_source_remove() it
otherwise, which seems harmless, but conceptually wrong.
https://bugzilla.gnome.org/show_bug.cgi?id=697144
|
| |
|
|
|
|
|
| |
Following on from a6b29d73 this commit correctly warn if you try and use
deprecated multiple screen behaviour.
|
|
|
|
|
|
|
|
| |
Some functions in gtkstyle.h were overlooked when we added the
GDK_DEPRECATED macros.
Also add IGNORE_DEPRECATIONS to the few remaining callers of those
functions.
|
|
|
|
|
|
|
|
|
| |
First of all, that call is deprecated. Second, we don't have RC styles
anymore. Third, what that function does today is invalidate style
contexts, but that happens automatically when setting the screen on the
style context later.
So this function is completely unnecessary.
|
|
|
|
|
| |
... to avoid gcc warning us. Ideally, we'd not call a deprecated
function here, but I'm lazy.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Don't just create a menushell and populate it with random data -- verify that
the resulting menu layout is actually correct.
This is introduced in a separate commit because the old code was failing this
part of the test.
https://bugzilla.gnome.org/show_bug.cgi?id=696468
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GtkMenuTracker folds a nested structure of sections in a GMenuModel into
a single linear menu, which it expresses to its user by means of 'insert
item at position' and 'remove item at position' callbacks.
The logic for where to insert separators and how to handle action
namespaces is contained within the tracker, removing the need to have
this logic duplicated in the 3 or 4 places that consume GMenuModel.
In comparison with the previous code, the tracker no longer completely
destroys and rebuilds menus every time a single change occurs. As a
result, the new gtkmenu testcase now runs in approximately 3 seconds
instead of ~60 before.
https://bugzilla.gnome.org/show_bug.cgi?id=696468
|
|
|
|
|
|
|
| |
Borrow the RandomMenu code from the GLib testsuite and hook it up to
gtk_menu_shell_bind().
https://bugzilla.gnome.org/show_bug.cgi?id=696468
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=697048
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=697048
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=697048
|
|
|
|
|
|
| |
I didn't know what "pg" stands for.
https://bugzilla.gnome.org/show_bug.cgi?id=697048
|