Call g_settings_sync() just before g_applcation_run() returns. This is
really the correct thing to do in every case that you're using GSettings
and it prevents every single application from having to do it for
themselves.
Closes bug #647419.
Add a flag to essentially short-circuit g_application_register(). The
application makes no attempt to acquire the bus name or check for
existing instances with that name. The application is never considered
as being 'remote' and all requests are handled locally.
Closes#646985.
* gio/application.c (g_application_real_command_line): Check that the
default signal handler is not the current one before complaining, because
it is not unusual for overloads to call the base class implementation as
a matter of habit.
g_application_real_open() and g_application_real_activate() already do this
extra check.
Some people are trying to write code that calls g_application_register()
then checks to see if we became the primary name owner before exporting
objects. This sort of approach worked with libdbus-1 because method
calls to the freshly-acquired name would not be dispatched until the
application returned to the mainloop. With GDBus, however, dispatches
can occur at any time (including in the brief space between acquiring
the name and actually registering the object).
Add documentation to make it clear that you should not expect this to
work.
Add support for passing the full contents of the environment to the
primary instance (by storing it in the platform_data) when
G_APPLICATION_SEND_ENVIRONMENT is in the flags.
Makes explicit the fact that you are interacting with the individual
action rather than the group and removes potential namespace conflicts
with classes implementing the interface (like g_application_activate()
vs g_application_activate_action()).
Create the gobject property for it.
Tweak the logic of having a pending timeout at the time that the
application starts -- run the mainloop with a use count of zero if there
is a timeout active.
Callers who are using g_application_unregistered_try_new are
likely wanting to continue doing something else if _register()
fails. Change the semantics so that passing register=FALSE
unsets default-quit as well. This means that a later _register()
call will send Activate but continue the process.
https://bugzilla.gnome.org/show_bug.cgi?id=622005
- add G_VARIANT_TYPE_BYTESTRING, _BYTESTRING_ARRAY, _STRING_ARRAY
- remove g_variant_{new,get}_byte_array functions
- add g_variant_{new,get,dup}_bytestring{,_array} functions
- remove undocumented support for deserialising arrays of objectpaths
or signature strngs using g_variant_get_strv()
- add and document new format strings '^ay', '^&ay', '^aay' and '^a&ay'
- update GApplication to use the new API
- update GSettings binding code to use the new API
- add tests
Like how we're handling activation, use GVariant for timestamps. To
avoid polluting the GtkApplication API with GVariants, we rename the
GApplication signals to "quit-with-data" and "action-with-data".
GtkApplication will then wrap those as just "quit" and "action".
https://bugzilla.gnome.org/show_bug.cgi?id=621002
This adds a GApplication object to GIO, which is the core of
an application support class, supporting
- uniqueness
- exporting actions (simple scripting)
- standard actions (quit, activate)
The implementation for Linux uses D-Bus, takes a name on the
session bus, and exports a org.gtk.Application interface.
Implementations for Win32 and OS X are still missing.
