Instead of manually doing it everywhere, just call set_object (NULL)
from the selection_changed handler. Fix all the set_object() functions
to deal with NULL.
Nice to have a quick way of testing this everywhere.
The implementation is not quite perfect: due to the way text
direction works in GTK+, widgets that appear in the inspector
window while we are flipped will inherit the flipped direction
instead of the fixed direction of the inspector window.
The widget-tree was not safe against object just going away.
Fix this by using row references instead of iters where
necessary, and by using weak refs to clean up when objects
die.
It does not really add much over the sensitive/insensitive rendering
that is already indicating which widget is mapped. At the same time,
set up signal handlers so we can update that when the widget changes.
Not only was the property list connecting to notify::bla for
each property individually, it was also leaking the signal
handlers when the selected object changed. Fix both.
When showing the objects in the tree, use the property name
as the name thats shown in the list. This makes it easier
to differentiate e.g. hadjustment and vadjustment in a
GtkScrolledWindow.
Add a tab that shows available signals for each object. For now,
we only show if each signal has handlers connected or now. More
functionality will be added later.
The list of toplevels also includes hidden combobox popups
and the like, so we have to be a little careful. To ensure
the right choice, we now pick the first visible window
that is not a GtkInspectorWindow.
Instead, we want to let GTK+ open a window whose life-cycle
it can control. We just ensure that all our types are registered
when the module is loaded, so GTK+ can find them.
The positioning of the highlight window was not reliable; instead
just use a after-handler for the draw signal, in the same way that
drag highlights are drawn by GTK+ itself.
And copy the code for grabbing a widget via pointer from testgtk;
that code is known to work.
This is a web service provided by Google that allows people to
share their printers (https://www.google.com/cloudprint/learn/).
In addition to being able to print to printers shared on Google Cloud
Print, there is an equivalent of "Print to file" in the form of "Save to
Google Drive".
The cloudprint module uses gnome-online-accounts to obtain the OAuth 2.0
access token for the Google account.
Currently it can discover available printers, get simple details about
them such as display name and status, and submit jobs without any
special options.
https://bugzilla.gnome.org/show_bug.cgi?id=723368
Return values of g_variant_get_child_value() were not unreffed
correctly together with one value returned by g_variant_get().
Use g_variant_get_data() instead of copying each byte separately.
https://bugzilla.gnome.org/show_bug.cgi?id=712799
Use info available in Avahi TXT records for creation of gtk printer
and request details when needed (through gtk_printer_request_details()).
If there is a printer advertised on Avahi by a remote CUPS server
try to get its PPD file at first or get its capabilities through an IPP
request if it fails.
https://bugzilla.gnome.org/show_bug.cgi?id=712751
Printing a file with to PDF/etc. with the virtual printer option doesn't add
the file to the list of recently used files. It should be there, so I can
easily access it.
https://bugzilla.gnome.org/show_bug.cgi?id=668598
We add a custom im module for broadway that calls some broadway
specific APIs to show/hide the keyboard on focus in/out. We then forward this
to the browser, and on the ipad we focus an input field to activate
the keyboard.
Commits the pre-edit string on receipt of focus_out and reset
commands.
Patch refinements by Cody Russell <bratsche@gnome.org> and
Ek Kato <ek.kato@gmail.com>
Replace the deprecated API calls with the updated APIs, and fix the build
of modules/input/gtkimcontextime.c, as we really needed
gdk/gdkkeysyms-compat.h (gdk/gdkkeysyms.h was already included)
https://bugzilla.gnome.org/show_bug.cgi?id=705068
The IME input method has been both ignoring keypresses of
non-spacing characters (ditching these as non displayable),
and not letting IME do anything about those.
Even though, the sparse documentation on IMM/IME seems to
hint that applications can't pipe non-spacing characters to
the input method manager, and experimentation shown that
those characters are indeed handled differently than how
it'd be expected.
Then, add basic handling of dead keys on the IME input method
itself , as it's not mutually exclusive with regular keymaps
with dead keys.
https://bugzilla.gnome.org/show_bug.cgi?id=704937
When an application translates a key event and drop its native event
before passing to imquartz, it can't recognize the NSEvent. On this
case imquartz doesn't emit any signals such as "commit" signal so
that the application doesn't insert any text. To avoid no response,
at least imquartz should fallback to slave GtkIMContextSimple.
https://bugzilla.gnome.org/show_bug.cgi?id=694273#c27
(cherry picked from commit c064e18894)
It can happen if the io channel has been closed. In that case
g_io_channel_write_chars() returns early because of a g_return macro
that checks if the io channel is writable. When returning from g_return
macros, the bytes written output parameter is not updated and the error
is not filled, so the error is not detected and the written variable is
used uninitialized. We should check the return value of
g_io_channel_write_chars() to break the loop.
https://bugzilla.gnome.org/show_bug.cgi?id=685419
In avahi_request_printer_list() a new connection to the DBus system bus
is started asynchronously, but it's not cancellable and it's not taking
any reference of the GtkPrintBackendCups. This means that when the
callback is called, the object might have been destroyed already. We can
just pass the cancellable created and check for the cancelled error in
the callback before trying to use the GtkPrintBackendCups. The code to
cancel avahi operations and to unsibscribe from the DBus signals has
been moved from finalize to dispose to make sure it happens as soon as
possible.
https://bugzilla.gnome.org/show_bug.cgi?id=696553