This adds support for registrating multiple versions of the same
typename by adding "@@" and a version name when you register the type.
This allows you to include a static library in your module that uses
gtypes. Normally such types would conflicts if another library also
statically linked to the library with the same gtype names, but a
different version. However, since the version names are different
we avoid this conflict.
You can also use this in public types if you want to allow using two
libraries with similarly named types to be used in the same process.
However, in addition to the gtype versions you then need to solve the
symbol name conflicts. This can be done for instance by using dlopen
with RTLD_LOCAL, or by introducing ELF symbol versioning.
You can query the versions of a type with g_type_[q]version (), and
you can look up a name by name and version with
g_type_from_name_and_version(). g_type_from_name() returns the
unversioned name if one exists (thus putting the burden of using
from_name_and_version on the person introducing versioned symbols),
and in the case of conflicting versions the alphabetically largest
version is used to guarantee stable results.
Perform conversion before writing a value out of the cache into the registry,
and convert back when reading a value into the cache out of the registry.
The registry holds UTF-8 strings.
This is a flag used to understand if a key exists on the registry
and if it is readable. It makes more sense to rename it as readable
since anyway a key that does not exists anymore is a key that is
not readable.
The documentation of g_file_info_copy_into() was misleading. The
attributes are not just copied, @dest_info is also cleared at the
beginning. So any previously set attributes in @dest_info are lost.
There was a bug in gedit about this function, where some metadata were
not saved. So it might make sense to change the implementation to not
clear @dest_info, and copy one by one the attributes from @src_info to
@dest_info.
https://bugzilla.gnome.org/show_bug.cgi?id=747927
The start_position arguments are passed to pcre_exec() as the
startoffset, which is in bytes (not characters).
I had recently a doubt about this, so it's better to document it.
https://bugzilla.gnome.org/show_bug.cgi?id=747927
I'm tired of seeing 'No such file or directory' in the logs without
a hint as to what is actually wrong. Including the filename here
may help me tracking down a bug in the continuous infrastructure.
Visual Studio, at least the older versions, cannot use L on macros which
are defined as a constant string, plus the L must be applied to all string
literals here. This does not look nice, but this is life...
