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.
Make g_get_user_data_dir() return the CSIDL_LOCAL_APPDATA folder on
Windows, and not CSIDL_PERSONAL. On Windows 7, that corresponds to the
subfolders AppData\Local vs. Documents under the profile ("home")
folder. This matches what Qt does, for instance, and has been widely
requested.
Also make g_get_user_config_dir() return this and not the (roaming)
CSIDL_APPDATA folder. The reason for this change is that it would be
surprising and hard to justify if g_get_user_data_dir() returned the
local application data folder while g_get_user_config_dir() would
return the roaming one. Nothing in the function names or the XDG specs
suggests that any roaming vs. local dichotomy would be involved.
Document the new semantics and the fact that these two functions now
return the same directory on Windows.
Note that in reality, code that really truly wants to support Windows
as well as possible probably will not use these GLib functions anyway,
but Win32 APIs directly to be sure what it is doing...
Should hopefully satisfy complaints in bug #620710 and related bugs.
Of course, a proper implementation of close() will just ignore an
invalid parameter silently, and set errno. But apparently the "debug"
version of the Microsoft C library generates some noise in this
case. So avoid that. Thanks to John Emmas for reporting.
One of the GVariant test cases allocates a pair of character arrays on
the stack and then passes them to functions that assume that they will
be aligned to a multiple of two.
This is not the case for some versions of GCC (4.0.3 on PowerPC).
Provides access to the g_settings_get_range() functionality, converting
its return value to something that's reasonable for printing at the
console and potentially parseable. The format may change.
Bug #631264.
Prevent assertion messages from spewing forth and also ensure that we
exit with an error status in the event that the value was out of range.
Bug #631264.
Don't store the "none" value for flags into the compiled schema file.
"none" should never appear as a value -- no flags set is indicated by an
empty array.
Rewrite the install rule for GSettings schemas to not depend on an
obscure chunk of non-portable sed that nobody understands the purpose
of.
Instead, use make's VPATH feature to resolve the paths of the files that
need to be installed. No need to depend on the .valid targets here
since automake already ensures that 'make all' is complete before 'make
install' is permitted to run.
Ensure that the strinfo is output in little-endian byte order on big
endian machines.
GSettings is now passing all of its tests on PowerPC.
Bug #630968 is closed.
GSettings relies on parts of the schema infromation remaining
unbyteswapped (the strinfo database, for example) while requiring other
parts to be in native order (the default value, constraints, etc.).
Lift the byteswapping into a place where we can do it selectively.
The test case was passing a guint16 to g_object_get() for a guint
property. That's invalid on all systems, although it works (more or
less) on little endian ones. On big endian it's a total no-go.
Make g_variant_byteswap() merely return a new reference on the given
value in the event that we know that byteswapping will have no effect
(ie: types which have no alignment requirement).
This fixes a somewhat complicated interaction between GVariant,
GSettings and GVDB on big endian machines: GSettings assumes that it
can unref values returned from GVDB without losing access to the
underlying data. This only works if the underlying data is in the
mapped file -- not a freshly-allocated buffer that GVariant byteswapped
into.
For GSettings.
Use the functionality introduced in the last commit to simplify our
notify dispatching and increase the safety of doing so (by ensuring that
the context is acquired in the current thread for the duration of the
dispatch).
This closes bugs #623400 and #629849.
Adds a new function g_main_context_invoke() (and _full() variant).
This function takes a main context, a function and a user_data. If the
main context is already acquired in the current thread, the function is
invoked directly. If the main context is the default main context of
the current thread and it can be acquired then the function is invoked
directly while the context is owned. Otherwise, the function is
scheduled as an idle on the context.
