This causes several problems:
- Compilation in FreeBSD with --enable-gtk-doc broke
- Modules that still use the AM_GLIB_GNU_GETTEXT macro
doesnt compile anymore because /usr/share/glib-2.0/gettext
is not filled with the correct files, as this was done in
the glib custom po/Makefile.in.in
See https://bugzilla.gnome.org/show_bug.cgi?id=622991
This reverts commit e5c752371c.
GDatagramBased is an interface abstracting datagram-based communications
in the style of the Berkeley sockets API. It may be contrasted to (for
example) GIOStream, which supports only streaming I/O.
GDatagramBased allows socket-like communications to be done through any
object, not just a concrete GSocket (which wraps socket()).
This adds the GDatagramBased interface, and implements it in GSocket.
https://bugzilla.gnome.org/show_bug.cgi?id=697907
Make use of the common autotools module that is used to generate the MSVC
project files from their respective templates so that the main build files
beccome cleaner, and enhance them in a way that the headers that should be
installed can be written to the property sheets during 'make dist', so that
the chances of missing headers for MSVC builds can be greatly reduced.
Also use this autotools module to fill in the projects for
glib-compile-schemas and glib-compile-resources.
https://bugzilla.gnome.org/show_bug.cgi?id=735429
Instead of just dropping address types that we're not specifically
handling we return a GNativeSocketAddress which is just a dummy
container for the stuct sockaddr.
https://bugzilla.gnome.org/show_bug.cgi?id=750203
This WIP patch moves the Windows Directory Monitoring code to the new
GLocalFileMonitor mechanism, and adds file monitoring in the process.
Progress from previous patch:
-File renames are now properly supported, but G_FILE_MONITOR_EVENT_MOVED_IN
and G_FILE_MONITOR_EVENT_MOVED_OUT needs to be investigated, as
ReadDirectoryChangesW() seems to send FILE_ACTION_REMOVED when a file is
moved out of a directory.
-Events are handled for both the long and short (8.3) variants of the
filenames, and files monitored will report changes when it is changed
via its short or long filenames.
Things to be done:
-Perhaps find out about attribute changes in files in a monitored
directory; if a file is monitored, attribute changes are correctly
handled.
-Investigate on G_FILE_MONITOR_EVENT_MOVED_OUT,
G_FILE_MONITOR_EVENT_MOVED_IN, G_FILE_MONITOR_EVENT_PRE_UNMOUNT,
G_FILE_MONITOR_EVENT_UNMOUNTED.
-Investigate on the "boredom" algoritm, and see how we can do it on
Windows.
https://bugzilla.gnome.org/show_bug.cgi?id=730116
Remove all event merging and dispatch logic from GFileMonitor. The only
implementation of GFileMonitor outside of glib is in gvfs and it already
does these things properly.
Get rid of GLocalDirectoryMonitor. We will use a single class,
GLocalFileMonitor, for both directory and file monitoring. This will
prevent every single backend from having to create two objects
separately (eg: ginotifydirectorymonitor.c and ginotifyfilemonitor.c).
Introduce GFileMonitorSource as a thread-safe cross-context dispatch
mechanism. Put it in GLocalFileMonitor. All backends will be expected
to dispatch via the source and not touch the GFileMonitor object at all
from the worker thread.
Remove all construct properties from GLocalFileMonitor and remove the
"context" construct property from GFileMonitor. All backends must now
get the information about what file to monitor from the ->start() call
which is mandatory to implement.
Remove the implementation of rate limiting in GFileMonitor and add an
implementation in GLocalFileMonitor. gvfs never did anything with this
anyway, but if it wanted to, it would have to implement it for itself.
This was done in order to get the rate_limit field into the
GFileMonitorSource so that it could be safely accessed from the worker
thread.
Expose g_local_file_is_remote() internally for NFS detection.
With the "is_remote" functionality exposed, we can now move all
functions for creating local file monitors to a proper location in
glocalfilemonitor.c
Port the inotify backend to adjust to the changes above. None of the
other backends are ported yet. Those will come in future commits.
Currently, the Windows code use Winsock2-specific APIs to try to emulate
calls such as inet_pton(), inet_ntop() and if_nametoindex(), which may not
do the job all the time. On Vista and later, Winsock2 does provide a
proper implementation for these functions, so we can use them if they exist
on the system, by querying for them during g_networking_init(). Otherwise,
we continue to use the original code path for these, in the case of XP and
Server 2003.
This enables many of the network-address tests to pass on Windows as a
result, when the native Winsock2 implementations can be used.
https://bugzilla.gnome.org/show_bug.cgi?id=730352
Add a new internal helper called GContextSpecificGroup.
This is a mechanism for helping to maintain a group of context-specific
monitor objects (eg: GAppInfoMonitor, GUnixMountMonitor).
https://bugzilla.gnome.org/show_bug.cgi?id=742599
GListModel is an interface that represents a dynamic list of GObjects.
Also add GListStore, a simple implementation of GListModel that stores
all objects in memory, using a GSequence.
https://bugzilla.gnome.org/show_bug.cgi?id=729351
We have a configure.ac check for lib.exe that attempts to enable
creation of .lib files for our 5 public libraries. That has been broken
for a long time for two reasons:
1) the Makefiles hardcode 'lib' instead of 'lib.exe'
2) we dropped generation of .def files quite some time ago (except for
in gthread where we have the two-symbol file under version control)
Add new rules for creating .def files from dumpbin.exe (which you should
have if you have lib.exe) and fix the .lib rules to use lib.exe.
Add a bit of $(AM_V_GEN) all around, as well.
https://bugzilla.gnome.org/show_bug.cgi?id=722033
This indicates whether the thumbnail (given by G_FILE_ATTRIBUTE_THUMBNAIL_PATH)
is valid — i.e. to represent the file in its current state. If
G_FILE_ATTRIBUTE_THUMBNAIL_IS_VALID is FALSE (for a normal _or_ failed
thumbnail) it means the file has changed since the thumbnail was generated, and
the thumbnail is out of date.
Part of checking thumbnail validity (by the spec) involves parsing
headers out of the thumbnail .png so we include some (small) code to do
that in a separate file. We will likely want to copy this code to gvfs
to do the same for GVfsFile.
Heavily based on a patch from Philip Withnall <philip.withnall@collabora.co.uk>
who suggested the feature and designed the API.
https://bugzilla.gnome.org/show_bug.cgi?id=709898
There are a number of nice things this class brings:
0) Has a race-free termination API on all platforms (on UNIX, calls to
kill() and waitpid() are coordinated as not to cause problems).
1) Operates in terms of G{Input,Output}Stream, not file descriptors
2) Standard GIO-style async API for wait() with cancellation
3) Makes some simple cases easy, like synchronously spawning a
process with an argument list
4) Makes hard cases possible, like asynchronously running a process
with stdout/stderr merged, output directly to a file path
Much rewriting and code review from Ryan Lortie <desrt@desrt.ca>
https://bugzilla.gnome.org/show_bug.cgi?id=672102
This is essentially a commandline implementation of the client-side of
the org.freedesktop.Application D-Bus interface.
It includes support for tab-completion based on desktop files and their
contents.
https://bugzilla.gnome.org/show_bug.cgi?id=704218
Rather than having lots of obscure platform-based #ifdefs all over
gio, define some macros in gcredentialsprivate.h, and use those to
simplify the rest of the code.
https://bugzilla.gnome.org/show_bug.cgi?id=701482
In implementing a better g_output_stream_splice_async() and possibly
other situtations it's helpful to know whether the input stream's
read function internally uses threads. If it and the output stream's
write async functions use threads, then the splice function could
spawn a single thread for better efficiency.
This patch adds a function to determine whether an input stream's
g_input_stream_read_async() function internally uses threads.
https://bugzilla.gnome.org/show_bug.cgi?id=691581
Add a new type of GAction that represents the value of a property on an
object. As an example, this might be used on the "visible-child-name"
property of a GtkStack.
https://bugzilla.gnome.org/show_bug.cgi?id=703270
Perform a substantial cleanup of the build system with respect to
building and installing testcases.
First, Makefile.decl has been renamed glib.mk and substantially
expanded. We intend to add more stuff here in the future, like canned
rules for mkenums, marshallers, resources, etc.
By default, tests are no longer compiled as part of 'make'. They will
be built when 'make check' is run. The old behaviour can be obtained
with --enable-always-build-tests.
--disable-modular-tests is gone (because tests are no longer built by
default). There is no longer any way to cause 'make check' to be a
no-op, but that's not very useful anyway.
A new glibtests.m4 file is introduced. Along with glib.mk, this
provides for consistent handling of --enable-installed-tests and
--enable-always-build-tests (mentioned above).
Port our various test-installing Makefiles to the new framework.
This patch substantially improves the situation in the toplevel tests/
directory. Things are now somewhat under control there. There were
some tests being built that weren't even being run and we run those now.
The long-running GObject performance tests in this directory have been
removed from 'make check' because they take too long.
As an experiment, 'make check' now runs the testcases on win32 builds,
by default. We can't run them under gtester (since it uses a pipe to
communicate with the subprocess) so just toss them in TESTS. Most of
them are passing on win32.
Things are not quite done here, but this patch is already a substantial
improvement. More to come.
GBytesIcon is an icon that has a GBytes inside of it where the GBytes
contains some sort of encoded image in a widely-recognised file format.
Ideally this will be a PNG.
It implements GLoadableIcon, so GTK will already understand how to use
it, but we will add another patch there to make things more efficient.
https://bugzilla.gnome.org/show_bug.cgi?id=688820
Some (broken) toolchains for example trip up
-Werror=missing-prototypes in system headers. This patch allows
people to skip the formerly hardcoded "baseline" warnings.
https://bugzilla.gnome.org/show_bug.cgi?id=694757
Add GSimpleProxyResolver, for letting people do static proxy
resolution, and to use as a base class for other resolvers (such as
GProxyResolverGnome).
https://bugzilla.gnome.org/show_bug.cgi?id=691105
gio's glib-mkenums call needs to get gnetworking.h out of $(builddir),
not $(srcdir). Fix/simplify it by using $(filter) on $^ and letting
make find everything.
Also add -Wno-portability to AM_INIT_AUTOMAKE in configure.ac, so that
it doesn't warn about this (or about the gmake-specific features we
were already using in gio/tests/)
https://bugzilla.gnome.org/show_bug.cgi?id=691866
Before this commit, the only difference between the expected and actual
ABI were the addition of _init and _fini symbols in each module (now
that regexp-based export control is not catching those).
We only want to control the default visibility for our five main
installable libraries: libglib, libgthread, libgmodule, libgobject,
libgio. We should therefore only set -fvisibility=hidden when building
those.
Use a separate substitution variable for this purpose.
Using CFLAGS directly leads to some modules built in testcases not
exporting their symbols (and then the tests fail). It also affects the
fam file monitoring module.
Colin had originally done it this way in his visibility patch series but
I failed to understand why so I didn't copy it. Now I do.
Also: revert changes made to two testcases in an attempt to work around
this issue.
https://bugzilla.gnome.org/show_bug.cgi?id=691756
With visibility now under the control of __declspec(dllexport) we no
longer need to build .def files or use them for building our various
.dll files.
.def files used to be installed (even though it is only really useful
when creating the .dll or .lib file). Don't do that anymore either.
The Makefiles still contain rules to create a .lib file for use with
Visual Studio and these rules require .def files. There are special
requirements to using these rules (like having installed and setup
Microsoft tools for use during the build) and therefore the problem of
creating a .def file for use with them is left open to anyone willing to
make the effort. Many options are available depending on which
toolchain is in use (dlltool, pexport, gendef, dumpbin.exe, just to name
a few).
If we can find a free tool for creating .lib files in the future, we
should probably revisit this issue and add proper support back to our
build system.
Since Windows builds by Visual C++ do not make use of autotools during
its build process, we need to dist a pre-configured
gio/gnetworking.h(.win32) for such builds.
The vs9/vs10 (and therefore vs11) property sheets are updated as well
https://bugzilla.gnome.org/show_bug.cgi?id=690163
