summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* gio: port to use guri functionswip/danw/guriDan Winship2014-11-227-338/+44
|
* guri: new URI parsing and generating functionsDan Winship2014-11-2214-457/+3291
| | | | | | | Add a set of new URI parsing and generating functions, including a new parsed-URI type GUri. Move all the code from gurifuncs.c into guri.c, reimplementing some of those functions (and g_string_append_uri_encoded()) in terms of the new code.
* GTlsClientConnection: loosen the semantics of "use-ssl3"Dan Winship2014-11-221-7/+12
| | | | | | | | | | | | | | | | | | | If SSL 3.0 has been disabled (at the host, application, or library level), then the "use-ssl3" property becomes a "fail-immediately" property. Despite the name, the point of the property wasn't really specifically to use SSL 3.0; it was to allow fallback when talking to broken servers that do SSL/TLS negotiation incorrectly and break when they see unexpectedly-high version numbers. So if we can't fall back to SSL 3.0, then the "use-ssl3" property should fall back to TLS 1.0 instead (since there are hosts that will reject a TLS 1.2 handshake, but accept a TLS 1.0 one). glib-networking is being updated to implement that behavior, so update the documentation here. https://bugzilla.gnome.org/show_bug.cgi?id=738633
* GSettings Registry Backend: Init cache_lock EarlierChun-wei Fan2014-11-201-7/+6
| | | | | | | | | | | | | | In commit 8ff5668, we are subscribing the GSettings backend later, but this meant that we need to initialize cache_lock earlier, as we might try to use that lock before a change notification is issued to subscribe the backend, which would then cause an access violation if we are trying to read GSettings values, as that lock is used to access the Windows Registry. Initialize cache_lock once we initialize the GSettings Registry backend, and delete it upon finalize, so that g_settings_read_from_backend() can proceed normally, even if the GSettings backend is not yet subscribed. https://bugzilla.gnome.org/show_bug.cgi?id=740413
* gsettingsschema: Print the string that failed to parseChristian Persch2014-11-201-1/+1
| | | | | | | | When parsing a translated value fails, print the actual string that failed to parse instead of the 'domain\004string' untranslated string. https://bugzilla.gnome.org/show_bug.cgi?id=737150 https://bugzilla.gnome.org/show_bug.cgi?id=737160
* GSettings: delay backend subscriptionRyan Lortie2014-11-192-4/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | GSettings objects begin watching for changes as soon as they are created in order that they can emit the "changed" signal. In the case of dconf, if we want to be able to emit the changed signal, we need to go on the bus and add some match rules. This requires creating the dconf helper thread and also requires initialising GDBus (which creates another thread). Some users of GSettings are never interested in the "changed" signal. One of these users is the glib-networking code that gets run every time a new network connection is created. Some users are reporting that they are annoyed that simply establishing a network connection would spawn two extra threads and create a D-Bus connection. In order to avoid doing unnecessary work for these simple uses, delay the subscription until we know that we will actually need to do it. We do this in a simple way, using a simple argument: in order for the user to care that a value changed then they must have: 1) watched for a change signal; and then 2) actually read a value If the user didn't actually read a value then they cannot possibly be interested in if the value changed or not (since they never knew the old value to begin with and therefore would be unable to observe that it ever changed, since they have nothing to compare the new value with). This really is a behaviour change, however, and it does impact at least one user: the 'monitor' functionality of the GSettings commandline tool, which is interested in reporting changes without ever having known the original values. We add a workaround to the commandline tool in order to ensure that it continues to function properly. It's also possible to argue that it is completely valid to have read a value and _then_ established a change signal connection under the (correct) assumption that it would not have been possible to miss a change signal by virtue of not having returned to the mainloop. Although this argument is true, this pattern is extremely non-idiomatic, and the problem is easily avoided by doing things in the usual order. We never really talked about change notification in the overview documentation for GSettings, so it seems like now is a good time to add some discussion, including the new rules for when one can expect change signals to be emitted. https://bugzilla.gnome.org/show_bug.cgi?id=733791
* glib: Improve documentation for g_strfreev()Alberto Ruiz2014-11-181-3/+5
| | | | Fixes #740309.
* Updated Norwegian bokmål translation.Kjartan Maraas2014-11-151-169/+171
|
* gapplication: enable --help when app has optionsLars Uebernickel2014-11-152-14/+59
| | | | | | | | | | This should already work according to the documentation, but doesn't because main_options is consumed before the check in g_application_parse_command_line(). Fix by moving the check for main_options up. https://bugzilla.gnome.org/show_bug.cgi?id=740157
* docs: Add missing opening parenthesisDavid King2014-11-131-1/+1
| | | | https://mail.gnome.org/archives/gnome-web-list/2014-November/msg00003.html
* docs: Update GParamFlags docs.Volker Sobek2014-11-101-1/+1
| | | | | | | Remove reference to G_PARAM_READWRITE from GParamFlags' description, since commit 6c395244a5db added G_PARAM_READWRITE to GParamFlags. https://bugzilla.gnome.org/show_bug.cgi?id=726037
* Simplify code that uses g_queue_insert_before() and insert_after()Sébastien Wilmet2014-11-092-17/+4
| | | | | | | g_queue_insert_before() and g_queue_insert_after() now accept a NULL sibling. https://bugzilla.gnome.org/show_bug.cgi?id=736620
* GQueue: accept a NULL sibling for insert_before() and insert_after()Sébastien Wilmet2014-11-092-11/+26
| | | | | | | | | It simplifies a little bit some code that inserts data relative to a GList location, that might be NULL for the tail of the queue. A NULL sibling is probably less useful for insert_after(), so it's more for consistency with insert_before(). https://bugzilla.gnome.org/show_bug.cgi?id=736620
* gnetworking.h.win32: Move "#undef interface"Chun-wei Fan2014-11-031-1/+1
| | | | | This is a follow-up commit due to the fix in gnetworking.h.in in commit 7103484 (gnetworking.h.in: move "#undef interface").
* gnetworking.h.in: move "#undef interface"Dan Winship2014-11-021-1/+1
| | | | | | | | | | | | | The win32 headers do: #define interface struct which is just evil and breaks other code that assumes it can use "interface" as a variable name. gnetworking.h was supposed to be doing "#undef interface" after including the win headers, but it did it too soon, resulting in it getting redefined by a later include. Fix this. https://bugzilla.gnome.org/show_bug.cgi?id=738551
* GTlsCertificate: fix loading of bad certificate chainsDan Winship2014-11-011-6/+6
| | | | | | | | | g_tls_certificate_new_from_file() was only loading the complete chain if it was fully valid, but we only meant to be validating that it formed an actual chain (since the caller may be planning to ignore other errors). https://bugzilla.gnome.org/show_bug.cgi?id=729739
* doc: Clarify documentation regarding g_file_replace and etagsRoss Lagerwall2014-10-301-8/+8
| | | | | | | Clarify that with g_file_replace, a non-NULL etag is only checked if the file already exists. https://bugzilla.gnome.org/show_bug.cgi?id=736286
* gio: Prevent hang writing to a large GMemoryBufferRoss Lagerwall2014-10-301-10/+8
| | | | | | | | | | | Fix a hang due to overflow by using unsigned numbers and explicitly checking if the number overflows to zero. This also fixes the previous logic which assigned an int which may be negative to an unsigned number resulting in sign extension and strange results. Use gsize rather than int to allow for large buffers on 64 bit machines. https://bugzilla.gnome.org/show_bug.cgi?id=727988
* gio: Prevent hang writing to a large GMemoryOutputStreamRoss Lagerwall2014-10-301-10/+8
| | | | | | | | | | | Fix a hang due to overflow by using unsigned numbers and explicitly checking if the number overflows to zero. This also fixes the previous logic which assigned an int which may be negative to an unsigned number resulting in sign extension and strange results. Use gsize rather than int to allow for large streams on 64 bit machines. https://bugzilla.gnome.org/show_bug.cgi?id=727988
* gmain: don't pass the same fd to g_poll() multiple timesDan Winship2014-10-293-60/+222
| | | | | | | | | | | | | | | | | | | | | | | If a given fd is being polled by multiple sources, we used to pass it multiple times to g_poll(), which is technically illegal (and not supported by the select()-based fallback implementation of poll() in gpoll.c), and also made it more likely that we'd exceed the maximum number of pollfds. Fix it to merge together "duplicate" GPollFDs. The easiest way to do this involves re-sorting context->poll_records into fd order rather than priority order. This means we now have to walk the entire pollrec list for every g_main_context_query() and g_main_context_poll(), rather than only walking the list up to the current max_priority. However, this will only have a noticeable effect if you have tons of GPollFDs, and we're already too slow in that case anyway because of other O(n) operations that happen too often. So this shouldn't change much (and the new poll API will eventually let us be cleverer). Remove some win32-specific code which did the same thing (but was O(n^2)). https://bugzilla.gnome.org/show_bug.cgi?id=11059
* GDBusInterfaceVTable: clarify memory handling for the method() virtual functionOwen W. Taylor2014-10-281-1/+11
| | | | | | | | | | | | | | | | | | | | | | There are two consistent interpretations that could be taken for memory handling of the 'invocation' parameter passed to the method_call() virtual function of GDBusInterfaceVTable - A reference is passed (transfer full) to the method_call() virtual function, and that reference is then passed (transfer full) to the return_value/error functions on GDBusMethodInvocation. - An internal reference is retained from the point where method_call() is called until the return_value/error function is called. Since the return_value/error functions were already marked (transfer full), we use the first interpretation, annotate the invocation parameter of method call as (transfer full) and describe this in the documentation, along with the idea that you are always supposed to call one of the return_value/error functions. See bug 738122 for the leak this caused in GJS. https://bugzilla.gnome.org/show_bug.cgi?id=738259
* Updates for 2.43.02.43.0Matthias Clasen2014-10-271-0/+40
|
* gcancellable: Clarify that GSources hold references to GCancellablesPhilip Withnall2014-10-271-0/+2
| | | | | | | | | | Clarify in the documentation that a GSource created with g_cancellable_source_new() must be explicitly removed from its GMainContext before the GCancellable can be finalised. This could be a common way of leaking GCancellables. https://bugzilla.gnome.org/show_bug.cgi?id=737259
* Guard g_inet_address_mask_equal against invalid inputErik van Pienbroek2014-10-261-0/+3
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=733338
* gio/tests/tls-certificates: fixDan Winship2014-10-251-2/+14
| | | | | | | | da053e34 broke the tls-certificates test by requiring the backend to implement g_tls_certificate_verify() (which the test TLS backend didn't). Add a trivial implementation to make the test pass again; we'll need something more complicated when we add tests that are supposed to get errors.
* gfile: g_file_equal (x, x) is TRUEBenjamin Otte2014-10-211-0/+3
| | | | | | | | | | So shortcut it. I wrote this patch less as a performance optimization and more as a clarification, so that people looking at the code can be assured of this invariant. https://bugzilla.gnome.org/show_bug.cgi?id=738374
* Add tests for {read,write}_all_async()Ryan Lortie2014-10-213-0/+260
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=737451
* docs: explain inconsistency of _{read,write}_all()Ryan Lortie2014-10-212-4/+17
| | | | | | | | | | These functions are inconsistent with our normal conventions in that they set an output variable to a specified value, even in the case that an error is thrown. Document very clearly that this should be considered exceptional. https://bugzilla.gnome.org/show_bug.cgi?id=737451
* Add g_output_stream_write_all_async()Ryan Lortie2014-10-212-0/+199
| | | | | | | | | | Similar to the previous patch, this commit contains a minor violation of normal API conventions. See the explanation in the previous commit message. Heavily based on a patch from Ignacio Casal Quinteiro. https://bugzilla.gnome.org/show_bug.cgi?id=737451
* Add g_input_stream_read_all_async()Ryan Lortie2014-10-212-0/+194
| | | | | | | | | | | | | | | | | | | Add an asynchronous version of _read_all(). This API is not fully consistent with the normal expectations of a non-asynchronous version. Consistency between the sync and async version is probably more important. The API will still bind correctly, but access to all functionality will not be available: specifically, in the case of an error, higher level languages will be unable to determine how many bytes were successfully read before the error. Most users will probably not want to use this information anyway, so this is OK -- and if they do need the information, then they can just write the loop for themselves. Heavily based on a patch from Ignacio Casal Quinteiro. https://bugzilla.gnome.org/show_bug.cgi?id=737451
* Fix another ancient docs typoMichael Catanzaro2014-10-201-1/+1
|
* GApplication: ignore --help if not handling argsRyan Lortie2014-10-201-1/+7
| | | | | | | If the user didn't register any arguments for parsing, also ignore --help. This fixes a regression in meld. https://bugzilla.gnome.org/show_bug.cgi?id=737869
* GOption: stop calling getopt()Ryan Lortie2014-10-201-12/+3
| | | | | | | | | | | | | | | | | | | | | | | We called getopt() to try to find out of the platform on which we are running defaults to strict POSIX-style argument handling (ie: flags following the first filename are considered as further filenames rather than flags). This is the default case on BSDs, for example. It is also the case on GNU systems with the POSIXLY_CORRECT environment variable set. Unfortunately many of our tools rely on being able to accept commandline arguments in the non-strict ordering and the code for making these calls is spread widely (for example in Makefile fragments invoking some of our build tools). For this reason we need to revert the getopt() check and only enable strict POSIX mode in the case that the application explicitly opts into it using the _set_strict_posix() API. This also fixs a failure to build on Windows due to missing getopt(). https://bugzilla.gnome.org/show_bug.cgi?id=723160
* GHashTable: small docs fixRyan Lortie2014-10-171-2/+2
| | | | We use g_hash_table_unref() here, not g_object_unref().
* Allow hash table destroy notifiers to remove other entriesBenjamin Berg2014-10-172-21/+125
| | | | | | | | | With this patch it is fine to call g_hash_table_lookup and g_hash_table_remove from destroy notification functions. Before this could lead to an infinitie loop if g_hash_table_remove_all was used. https://bugzilla.gnome.org/show_bug.cgi?id=695082
* docs: Add missing get_type() reference to gio.typesEmmanuele Bassi2014-10-171-0/+1
| | | | | | | GSubprocessLauncher is a GObject, so we need to tell gtk-doc to inspect it. https://bugzilla.gnome.org/show_bug.cgi?id=738675
* GOption: add strict posix modeRyan Lortie2014-10-153-0/+144
| | | | | | | | | | | | | | | | Add a "posixly correct" mode to GOption to stop parsing arguments as soon as the first non-option argument is encountered. We determine the default value on the basis of duplicating the behaviour of the system getopt() implementation (which we directly check the behaviour of at runtime). On GNU systems this allows the user to modify our behaviour using POSIXLY_CORRECT. The user can change the value by g_option_context_set_strict_posix(), which might be useful for some usecases of GOptionContext (as mentioned in the doc string of this new function). https://bugzilla.gnome.org/show_bug.cgi?id=723160
* GApplication: Plug a memory leakMatthias Clasen2014-10-141-0/+2
| | | | We were not freeing resource_path.
* gdesktopappinfo: Fix copy/paste typo from e24e89bJasper St. Pierre2014-10-141-1/+1
| | | | | | | | | Commit e24e89b accidentally ironically introduced a typo when replacing the code with symbolic contents. Specifically, "Added Associations" was replaced with "Default Applications" when reading defaults.list, giving a warning about the file containing a "Default Applications" group. If this was intended, it should have not been lumped in with a cleanup.
* gfile: Clarify docsBenjamin Otte2014-10-121-1/+4
| | | | Clarify corner cases that were unclear while reviewing a GTK patch.
* Bump version to 2.43.0Benjamin Otte2014-10-121-1/+1
| | | | We have new API.
* signal: Keep only one list of emissionsBenjamin Otte2014-10-121-48/+25
| | | | | | | | | There is no need to keep 2 lists. This simplifies the code and gets rid of the only user inside glib of G_HAVE_GROWING_STACK. https://bugzilla.gnome.org/show_bug.cgi?id=736284
* Fix a return_if_fail confusionMatthias Clasen2014-10-111-1/+1
| | | | This slipped through my editing of the patch.
* Add simple instance count facilityOwen W. Taylor2014-10-112-2/+55
| | | | | | | | Add GOBJECT_DEBUG=instance-count which enables internal accounting of the number of instances of each GType, and g_type_get_instance_count() to retrieve the result. https://bugzilla.gnome.org/show_bug.cgi?id=354457
* Updated Bulgarian translationKrasimir Chonov2014-10-111-1009/+1230
|
* Clarify g_propagate_error docsMatthias Clasen2014-10-101-0/+4
| | | | | I just ran into a bug that was caused by having src being a persistent GError* that was not cleared after propagating it.
* Fix g_cond_timed_wait() timeout with !CLOCK_MONOTONICBenjamin Gilbert2014-10-101-6/+0
| | | | | | | | g_get_monotonic_time() and g_get_real_time() now always use different clocks, so we cannot avoid correcting for their offset. Fixes failure to time out on Mac OS X. https://bugzilla.gnome.org/show_bug.cgi?id=738197
* garray: initialize allocated size in g_byte_array_new_take()Aleksander Morgado2014-10-081-0/+1
| | | | | | | | | | | | | | Internal allocation size (array->alloc) was being kept to 0 when a new GByteArray was created from an already existing heap-allocated buffer. Among other things, this was making g_byte_array_set_size() fully clear all the buffer contents (not just the newly allocated memory) when G_DEBUG=gc-friendly was being used... if (G_UNLIKELY (g_mem_gc_friendly)) memset (array->data + array->alloc, 0, want_alloc - array->alloc); https://bugzilla.gnome.org/show_bug.cgi?id=738170
* Add advice on g_cancellable_resetMatthias Clasen2014-10-061-0/+7
| | | | Don't use it at home.
* tlscertificate: add support for certificate chainsAleix Conchillo Flaqué2014-10-061-46/+184
| | | | | | | | | | | | | | | | This patch changes the behavior of the following functions: g_tls_certificate_new_from_pem g_tls_certificate_new_from_file g_tls_certificate_new_from_files If more than one certificate is found it will try to load the chain. It is assumed that the chain will be in the right order (top-level certificate will be the last one in the file). If the chain cannot be verified, the first certificate in the file will be returned as before. https://bugzilla.gnome.org/show_bug.cgi?id=729739
View Lorry Controller Status