GAction is a read-only interface (as is visible by the lack of _set() functions
on its API). The properties on the interface currently force implementors to
support writing of the properties at construct time, however.
Lift that restriction.
Take advantage of this from GSimpleAction by nuking the set_property
function and setting the fields directly in the constructor.
This commit represents an API break to GAction in the following ways:
- the 'set_state' entry in the GActionInterface vtable has been
renamed to 'change_state'. The number and order of vtable items has
not otherwise changed.
- g_action_set_state() has been renamed to g_action_change_state() to
match the updated vtable entry.
- the "state" property of the GAction interface has been changed to
read-only to reflect the fact that g_action_set_state() no longer
exists.
- GSimpleActionClass has been hidden. GSimpleAction can no longer be
subclassed.
>> Rationale
g_action_set_state() has never been a true setter in the sense that
calling it will update the value of the "state" property. It has always
been closer to "request 'state' to be changed to this value" with
semantics defined by the implementor of the interface. This is why the
equivalent method in GActionGroup had its name changed from 'set' to
'change'. This change makes the two interfaces more consistent and
removes any implication about the effect that calling set_state() should
have on the 'state' property.
>> Impact
This incompatible API break was undertaken only because I strongly
suspect that it will go entirely unnoticed. If the break actually
affects anybody, then we will accommodate them (possibly going as far as
to revert this commit entirely).
The virtual table change only impacts implementors of GAction. I
strongly suspect that this is nobody (except for GSimpleAction).
The hiding of GSimpleActionClass only impacts impacts subclasses of
GSimpleAction. I strongly suspect that none of these exist.
The changing of the property to be read-only only affects people who
were trying to change the state by using GObject properties. I strongly
suspect that this is nobody at all.
The removal of the g_action_set_state() call is the most dangerous, but
I still suspect that it will impact nobody outside of GLib. If anybody
is impacted by this change then, at their request, I will reintroduce
the API as a deprecated alias for g_action_change_state().
This time I realized that I needed to set autocrlf=false on my Windows side
... ugh...
This is one of those files that must have CRLF line endings to work
orrectly :|
-Reinstate build/win32/vs10/glib.sln with the correct EOL (DOS/Windows) so
that the file can be correctly recognized by Windows, rather than having
the "Unrecognized Visual Studio Version".
-Update the main GLib projects to output the DLL/LIB file into <Release or
Debug>\<Win32 or x64>\bin for all configurations.
-Update/simplify the property sheets to copy all DLL and LIB files from
<Release or Debug>\<Win32 or x64>\bin for all configurations.
-Update the VS 2008 property sheet to seperate the intermediate directories
for all projects as well to avoid errors/warnings of being unable to
write/access the PDB files as they are in use.
The Linux eventfd() call is basically tailor made for the main loop
wake up pipe - all we want is a threadsafe way to write to a file
descriptor, and wake up the context on the other end; we don't care
about the content at all.
The eventfd manual page basically explains the benefits:
Applications can use an eventfd file descriptor instead of a
pipe (see pipe(2)) in all cases where a pipe is used simply to
signal events. The kernel overhead of an eventfd file
descriptor is much lower than that of a pipe, and only one file
descriptor is required (versus the two required for a pipe).
When writing my multithreaded spawn test case I actually hit the 1024
file descriptor limit quickly, because we used 2 fds per main context.
This brings that down to 1.
https://bugzilla.gnome.org/show_bug.cgi?id=653140
