We currently have a couple of cases where GtkApplication assumes that
the session bus will be non-NULL causing critical error output or (in
the case of trying to publish menus) an infinite loop.
Three fixes:
- if the session bus is NULL due to not having registered the
GtkApplication yet then give a g_critical on the entry point to the
menu setters instead of going into an infinite loop. Document this.
- check for NULL session bus even when calling the menu setters at the
right time in order to prevent the infinite loop for
non-programer-error cases (ie: because we had trouble connecting to
the session bus)
- check for NULL session bus when publishing the X11 properties on the
GtkApplicationWindow and skip publishing them if we're not on the bus
https://bugzilla.gnome.org/show_bug.cgi?id=671249
If the PPD is not available when the printer is loaded then the PPD options are
not available and we can't get the correct qualifier to use with colord.
When the PPD becomes available, refresh the profile title to reflect reality.
https://bugzilla.gnome.org/show_bug.cgi?id=674890
Having refactored cups_request_printer_list_cb so that the cups
version-dependent block size is small enough to be handled in a single ifdef,
make the ifdef HAVE_CUPS_API_1_6 block.
So that it can be passed as a single parameter to functions as we
extract-function to make cups_request_printer_list_cb more manageable.
Note that not all of the affected variables are changed in this
changeset. Those are in extracted functions and will be addressed in the
next two changes.
Since the event will be ignored anyway after it's translated (slave
devices are disabled), don't let it run in the smooth scroll code path,
as it will burn our caches for the actual event we're interested in.
https://bugzilla.gnome.org/show_bug.cgi?id=673644
Of course, we must pass coordinates in the NSWindow coordinate system
when creating an NSEvent. This fixes drag icon positioning and makes
the icon slide back to the correct position when the drag is
canceled.
Try to fetch the name from the application desktop file for the
fallback menu if possible, instead of forcing applications to use
g_set_application_name or hardcoding "Application".
https://bugzilla.gnome.org/show_bug.cgi?id=673882
In the Quartz backend, there are two methods by which windows are
resized. The first method is fully handled by Quartz and does not appear
in the event stream the application resizes. The second method is when
we resize windows by ourselves. In OS X this happens when a GTK+ resize
grip is used. This resize grip is larger than the Quartz resize grip.
When the resize is started outside the "Quartz area", we have to handle
it by ourselves.
This patch fixes this manual window resizing by ignoring events while we
are in the process of resizing (such that the events actually arrive at
the sendEvent handler of GdkQuartzWindow where this resize is handled).
When the resize has finished we break all grabs such that GDK is not
stuck thinking the cursor is still in the resize window.
