dconf 0.4 released

[Ryan Lortie]

dconf 0.4 is released.


You can download it here:
  http://download.gnome.org/sources/dconf/0.4/

SHA256 for your horizonal-scrolling pleasure:

  9812a3401ce31a2b083aaf963b6600b528975c61b7292c6d40346f5f4bf76d28  
dconf-0.4.tar.bz2
  beb33f2aa435ef938bb4d7a2e5066058921504c5ed7b0fd59ab1e5f3bee44431  
dconf-0.4.tar.gz


Changes in dconf 0.4
=

 - fix crashes when the dconf database doesn't yet exist
 - add some incomplete gtk-doc
 - use new GVDB (note: dconf file format has incompatibly changed)
 - implement GSettings sync()
 - use string tags instead of sequence numbers since it was impossible
   to have universally unique sequence numbers
 - theoretical support for sharing dconf databases between machines with
   different byte orders
 - fix bug where first write was not successful when auto-starting
   service
 - FreeBSD build fixes
 - client API cleanups
 - GObject introspection support
 - enable automake silent rules by default for tarball builds


Bugs (I'm sure there are many) to the usual place, please.  I know about
the insane amount of leaks and will be tracing those down.  I'm away for
the weekend, so don't expect replies to any hate mail until Monday :)

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

GLib 2.25.10 is released

[Ryan Lortie]

hi Everyone,

GLib 2.25.10 is now available for download at:

  ftp://ftp.gtk.org/pub/glib/2.25/
  http://download.gnome.org/sources/glib/2.25/

66e6a090c88a94f715889429498d940ff5bb890b3479b78f4c4c05f8a50b2a38  
glib-2.25.10.tar.bz2
630485c1f2cf54f2665db869c7204ca6e52a4e59c2f211f0ce8aeb5c8ac0a888  
glib-2.25.10.tar.gz

This is a development release leading to GLib 2.26.

Notes:

 * This is unstable development release. While it has had
  a bit of testing, there are certainly plenty of bugs
  remaining to be found. This release should not be used
  in production.

 * Installing this version will overwrite your existing
  copy of GLib 2.24. If you have problems, you'll need
  to reinstall GLib 2.24.

 * GLib 2.26 will be source and binary compatible with
  the GLib 2.24 series; however, the new API additions
  in GLib 2.25.x are not yet finalized, so there may
  be incompatibilities between this release and the final
  2.26 release.

 * Bugs should be reported to http://bugzilla.gnome.org.


About GLib
==

GLib is the low-level core library that forms the basis for projects
such as GTK+ and GNOME. It provides data structure handling for C,
portability wrappers, and interfaces for such runtime functionality as
an event loop, threads, dynamic loading, and an object system.

More information about GLib is available at:

 http://www.gtk.org/

An installation guide for the GTK+ libraries, including GLib, can
be found at:

 http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html


Overview of Changes from GLib 2.25.9 to GLib 2.25.10


++
| WARNING: There have been API changes in GDBus. Users of these  |
| APIs will need to be adapted.  In particular, a new release of |
| dconf is required to go along with this one.  There has also   |
| been a change in the GSettings backend API used for keyfiles.  |
++

* GDBus:
 - add direction parameter to filter functions (API change)
 - allow calling other interfaces with a GDBusProxy
 - padding added to class struct fields (ABI change)
 - fixes for closures-based functions

* GVariant:
 - new is_floating() call
 - add g_value_take_variant() call (required for marshallers)

* GSettings:
 - support for binding GParamSpecEnum properties
 - ifelse-style condition support for GLIB_GSETTINGS m4 macro
 - remove gsettings-schema-convert tool (now in GConf)
 - allow introspection of all installed schemas
 - allow introspection of the keys in a schema
 - rewrite keyfile backend (API change)

* GNIO:
 - don't implicitly close GSocket until it is destroyed
 - windows fixups

* Other:
 - allow GChecksum to take (NULL, 0) for data/length
 - GRelation and GCompletion are now deprecated
 - introduce G_PARAM_DEPRECATED and G_ENABLE_DIAGNOSTIC
 - add working directory to GApplication platform data
 - lots of documentation cleanups
 - PCRE updated to 8.02

* Build:
 - the IA__g_* style symbol aliasing has been disabled and replaced with
   the -Bsymbolic-functions linker flag on platforms that support it.
   Please be on the watch for portability issues and report them to us.
 - many test cases have been moved to the GTester framework
 - lcov support has been added for tests
 - many windows fixes

* Bugs fixed:
 501057  lcov coverage suite and GLib integration
 551271  deprecate GRelation
 601686  Implement diagnostic mode
 603309  GSocketOutputStream broken on Windows (?)
 616718  GLIB_GSETTINGS macro can't be used conditionally
 616855  GSocketConnection: don't close the socket if it's still reffed
 618866  g_ptr_array_remove_index_fast memory leak
 619878  keyfile backend calls keys_changed with invalid argument
 619879  keyfile backend doesn't make use of expected_type
 621092  Add with_closures() variants for bindings
 621172  Cross compiling fails
 621838  Actually add cwd to platform data
 621945  Filter outgoing messages in GDBusConnection
 621947  add g_value_take_variant
 622038  GSettings: "It is a programmer error" documentation is unclear
 622154  [patch] update documentation for g_application_new
 622281  binding: Add SYNC_CREATE to the flags
 622480  Improve documentation for g_strcmp0()
 622554  g_error called if schema not installed
 622601  Return interned strings from g_settings_list_keys

* Translation updates:
 - Galician


Thanks to all contributors:
 Matthias Clasen
 Christian Dywan
 Emmanuele Bassi
 Milan Bouchet-Valat
 David Zeuthen
 Dan Winship
 Tor Lillqvist
 Javier Jardón
 Sven Herzberg
 Patrick Hulin,
 Christian Persch
 Johan Dahlin
 Christian Persch
 Jürg Billeter


June 24, 2010
Ryan Lortie

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

dconf 0.4.1 is out

[Ryan Lortie]

hi Everyone,

dconf 0.4.1 is released.


You can download it here:
  http://download.gnome.org/sources/dconf/0.4/

Checksums:

  02107c9f1cb23b0aa749d49858374246b73786ffa0c14e69ba66d9410d8bfb25
dconf-0.4.1.tar.bz2
  6bf25c7c9fe36a6d5c261df0c319877af42faebd78a78c05aa9bb25ff2b4fba8
dconf-0.4.1.tar.gz


The primary purpose of this release is to adjust to some API breaks that
happened in the just-dropped release of GLib.  If you don't upgrade
dconf then crashes will occur.

There are also some bug fixes.

Cheers


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: dconf 0.4.1 is out

[Ryan Lortie]

hi Robert,

On Sat, 2010-06-26 at 14:43 +0200, Robert Schwebel wrote:
> Is it possible that we make this conditional, like in
> 
>   --{en,dis}able-dconf-editor

Yes.  Of course.  I'll do this soon.

The plan is for the dependency on Vala to increase (to be used in the
core parts of dconf, for example), but since that's only needed for
'make dist' (or compiling directly from git) I guess it's okay for your
embedded use case?

Cheers


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: dconf 0.4.1 is out

[Ryan Lortie]

On Sat, 2010-06-26 at 19:01 +0200, Tadej Borovšak wrote:
> This is how normal flow looks like:

Quite accurate, and exactly how it will work with dconf.

Thanks for the explanation, Tadej :)

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

release of GLib 2.25.11

[Ryan Lortie]

ncluded into the docs
  - added support for schemas that extend other schemas (using the
'extends=' attribute).  Values of keys in the base schema can be
overridden using .
  - added theoretical support for lists (using the 'list-of=' attribute)
  - lots of new tests
  - add support for flags (implemented similarly to enums)
  - add support for generating .enums.xml files to gsettings.m4:
  gsettings_ENUM_NAMESPACE = org.example.myapp
  gsettings_ENUM_FILES = ../path/to/*.h
will generate org.example.myapp.enums.xml with mappings for all
enums and flags in the specified .h files.
  - warn with g_message() if the 'memory' backend is used by default
(ie: because no other GSettings backends are installed)
  - fix get_property() for GSettings::schema
  - command line tool: fix a bug that prevented non-basic values from
being set due to a premature free
  - command line tool: bash completion support
  - chain up in _finalize
  - add a new g_settings_get_mapped API to read settings that require
post-processing
  - retry with the translated or schema default value if the
GSettingsBindGetMapping function fails
  - schema compiler: never fail due to empty schema directories (but
warn)
  - peek rather than ref/unref the GEnumClass in the mapping function
  - schema compiler: compile *.enums.xml before *.gschemas.xml to ensure
that we have all the enums that the schemas may reference
  - schema compiler: improve accuracy of line numbers in error reports
  - fix crashes in the keyfile backend caused by invalid group names in
the keyfile

Other:
  - always intern GBinding prop names
  - base64: remove asserts preventing conversion of empty strings
  - document NULL special-cases for GValueArray
  - GNode docs improvements
  - improve detection of 'system internal' mounts
  - fix leaks in the inotify GFileMonitor implementation
  - annotate all custom GIO GSources to improve debugging (e.g. using
SystemTap)

Tests:
  - Turn on glibc malloc checking features for make check
  - improvements for GSettings tests, plus new tests
  - improved tests for GKeyfile
  - new tests for GDir, GSList, GSList, GAppLaunchContext,
CharsetConverter, GIcon, ...
  - move some tests to GTester (tree tests, uri tests)
  - generally, really an awful lot of new tests
  - don't try to allocate 2gigs of memory anymore for the array test

 552363 g_value_array_{insert,prepend,append}'s special cases for NULL
 561248 Improve return value description from g_node_prev/next_sibling()
 570036 Add ACLOCAL_AMFLAGS to Makefile.am
 576833 g_sprintf add a reference to g_strdup_printf
 576854 g_strconcat() documentation should provide a hint about bad l10n
 582227 reference: add other URI functions to 'URI Functions' section
 599223 should provide g_spawn_* variants that take a GAppLaunchContext
 610784 array test failing
 613057 Leak in inotify GFileMonitor implementation
 620536 Annotate all custom GIO GSource using g_source_set_name
 620913 More control with G_DBUS_DEBUG
 622124 implement flags
 622127 GSettings extended key validation
 622128 retry with default value for failed mapping
 622294 More annotations for GVariant
 622565 glib-compile-schemas fails when no schemas
 622600 Fix missing prototype warning
 622813 gsettings mapping & enum buglet
 623142 Ensure ::new-connection runs before processing D-Bus messages
 623143 Never require non-closed connections
 623319 use g_parse_debug_string for dbus debug flags
 623401 process enums first
 623402 schema compiler reports wrong line numbers
 623407 g_keyfile_settings_backend_new crashes with the key "/"
 623473 zlib should be checked with pkg-config
 623537 GDBusProxy has weird checking on NameOwnerChanged
 623538 GDBusProxy::g-properties-changed emission for corner cases
 623692 directory with file at multiple MLS levels may display empty
 623720 gschema.dtd does not contain enum definitions
 623770 quoting of expand_macro in gdesktopappinfo.c
 623772 gdesktopappinfo.c, function child_setup
 623780 g_unix_is_mount_path_system_internal
 623954 g_settings_finalize
 623955 Dubious return values

Updated translations:
 Galician
 Hebrew
 Norwegian bokmål
 Spanish


Thanks to the contributors:
 Colin Walters
 Dan Winship
 Danielle Madeley
 David Zeuthen
 Kristian Rietveld
 Matthias Clasen
 Milan Bouchet-Valat
 Tor Lillqvist
 Will Thompson


July 11, 2010
Ryan Lortie

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

dconf 0.4.2

[Ryan Lortie]

I just did a dconf release to go with the new GLib release.

There have been some crasher fixes and the editor has been quite a bit
improved.

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

glib 2.25.12 is here!

[Ryan Lortie]

 Owen Taylor
 Stefan Kost
 Tomeu Vizoso


July 29, 2010
Ryan Lortie
From the Hague :)

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Minutes of the GTK+ team GUADEC meeting - 2010-07-29

[Ryan Lortie]

On Tue, 2010-08-03 at 01:28 -0400, Matthias Clasen wrote:
> > • Hackfest
> >  ∘ Planned for October w22 (18th-22nd)
> 
> I will try to make it this time, for a change. Are the dates final yet ?

Set in stone and approved by the foundation.  It's fine to start booking
tickets.

> Did outstanding work for GLib 2.26 get discussed ? I am only aware of
> the datetime work, anything else ?

The focus of the meeting was on Gtk -- my understanding is that GLib
plans are completely unchanged from what they were before GUADEC.

I've been working on a GApplication rewrite (with approval and design
validation from Colin and Emmanuele).  I hope to land that in the coming
days (ie: it will be the focus of a 2.25.13 release).

There are still a couple of outstanding GSettings features, of course...

> I assume we also need a GTK+ 2.22 release in time for Gnome 2.32.

Yes.  Release team wants that, including GtkApplication backported.


Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Gtk+ Hackfest, October 18-22, A Coruña, Galicia

[Ryan Lortie]

Hello everyone,

I'm very pleased to officially announce the Gtk+ 2010 hackfest.

The hackfest will be during the week of October 18 through 22 in A
Coruña, Galicia.  Igalia has stepped up and offered the venue.

For developers actively involved in Gtk+, the foundation has agreed to
pay the full cost of accomodation (Sunday through Saturday) if those
attending can cover their other costs (travel, food, etc).

Please visit this wiki page and add yourself to the list of names if you
are interested in attending:

http://live.gnome.org/Hackfests/GTK2010

We have room for about 20 (comfortable) to 30 (less comfortable) hackers
at the venue.

The dates and location are completely finalised, so if you are coming,
you should start booking tickets ASAP.  Please add yourself to the list
before booking tickets, so we can avoid being overbooked at the venue.

The hackfest has two primary focuses:

  1) Revisiting the choices we made at GUADEC in terms of schedule
 feasibility and culling features if necessary.

  2) Hacking like crazy to make them happen in time for a Christmas
 release of Gtk 3.0.

Looking forward to seeing everyone there.

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

dconf 0.5

[Ryan Lortie]

hi Everyone,

After a bit of post-GUADEC delay I am happy to announce dconf 0.5.  This
is the first release of dconf that doesn't completely suck (but it still
has a lot of suck).

There have really been a lot of changes this time around, but one is
really worth mentioning: I am experimenting with living a libtool-free
existence.  For this reason, it is quite expected that this release of
dconf may not be very portable.  If you have trouble getting dconf to
build on a non-GNU toolchain then please file bugs at:

https://bugzilla.gnome.org/

You can grab the tarballs here:

http://download.gnome.org/sources/dconf/0.5/

The NEWS here is relative to dconf 0.4 (since I didn't write NEWS for
the point releases that came between).

Changes in dconf 0.5
=

 - Include a dconf-editor
 - drop libtool
 - allow compiling without gobject-introspection
 - autotools/build fixups
 - repair some broken use of tags
 - many updates for glib API changes
 - fix a crasher in the service
 - prefer 'automake-1.11' if it is in the path
 - add support for layering (ie: for system defaults)
 - add support for multiple writers in one service
 - add a shared memory status region to indicate if the gvdb is stale
 this prevents dconf from having to reopen the file each time
 - support keyfile-maintained system settings (via 'dconf update')
 - port client library and commandline tool to vala
 - client library no longer has unimplemented calls
   (except for write_many_async, due to bugs in valac)
 - gtk-doc is now complete for the client library
 - install our own vapi
 - support 'reset' in the GSettingsBackend


Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

gobject-introspection 0.9.3

[Ryan Lortie]

hi,

I just released dconf 0.5, containing a dependency on an unreleased
gobject-introspection.  Oops.  :(

Rumour has it that Colin is still roaming around Europe so I've uploaded
a tarball for gobject-introspection 0.9.3 in order to save vendors the
hassle of coming up with creative solutions to the mess I've made.

http://download.gnome.org/sources/gobject-introspection/0.9/


Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

AC_MSG_RESULT(patching libtool to fix HIDEOUS BREAKAGE) [was Re: dconf 0.5]

[Ryan Lortie]

hi Kevin,

On Wed, 2010-08-04 at 08:39 -0700, Kevin Fox wrote:
> On Tue, 2010-08-03 at 18:42 -0700, Ryan Lortie wrote:
> > I am experimenting with living a libtool-free
> > existence.
> 
> Out of curiosity, why?

Short version:

  1) I don't believe that I need it.

  2) It has many features that are actively causing me pain.


Expanding on each of those points:

First, dconf is only really intended to be used on free operating
systems.  It will never be used on Windows and probably not on Mac OS
either.  That greatly reduces the complexity associated with building
shared libraries.

Second, the two big issues:

  - installation of .la files
I need post-install hooks to erase them after they are installed.

  - forcing the undesired use of rpath
The workarounds for this problem are VERY ugly, see
http://wiki.debian.org/RpathIssue if you like to cry.

and also more trivial things:

  - almost doubling the time it takes to configure and build
  - distributing a(nother) gigantic shell script + m4 in tarballs

All together, if I don't need and and I don't like what it is doing to
me, then why should I continue to use it?

My intention is to develop a small m4 macro that guesses the correct way
to build shared libraries on a small selection of common Unix flavours,
at configure time, and use that instead.  Quite some people have
indicated to me that they would be interested in using this macro after
it becomes clear that it properly handles such a range of systems.


Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: dconf 0.5

[Ryan Lortie]

hi Robert,

I caught the bug on bugzilla.  I'll review it today.

I basically agree, though.

Cheers

On Thu, 2010-08-05 at 09:07 +0200, Robert Schwebel wrote:
> Ryan,
> 
> On Tue, Aug 03, 2010 at 09:42:19PM -0400, Ryan Lortie wrote:
> > After a bit of post-GUADEC delay I am happy to announce dconf 0.5.
> 
> Here is a patch that makes the dconf editor optional. I've also added
> this to bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=626081
> 
> rsc
> 
> --8<--8<--8<--8<--8<--


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: AC_MSG_RESULT(patching libtool to fix HIDEOUS BREAKAGE) [was Re: dconf 0.5]

[Ryan Lortie]

On Thu, 2010-08-05 at 19:26 +0200, "Andrés G. Aragoneses" wrote:
> El 04/08/10 19:29, Ryan Lortie escribió:
> > 
> > and also more trivial things:
> > 
> >   - almost doubling the time it takes to configure and build
> >   - distributing a(nother) gigantic shell script + m4 in tarballs
> > 
> 
> Not that I have a deep idea about this, but isn't dolt supposed to fix
> these problems?

These were the issues marked as "trivial".

Also, dolt doesn't impove the "script size" situation -- libtool is
still shipped.  In fact, it makes it (slightly) worse, by shipping two
extra scripts.

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

glib 2.25.13 released

[Ryan Lortie]

Hello.

Due to a rather serious packaging bug in glib 2.25.12, I'm making a
quick 2.25.13 release.  You should not use glib 2.25.12.

I've made some changes to address that problem and hopefully prevent
similar problems from happening again.  I looked over the package and it
seems to be fine, but please be on the lookout for any possible issues
that I introduced with the new changes.

Download and SHA256:

 http://download.gnome.org/sources/glib/2.25/

785297b1528cba6f2d20358ba7386be49bad0e7d50aa4b965d80a44eba14a5e0  
glib-2.25.13.tar.bz2
21001d2365f286f61710936d0e06fab7eef8d0aba57ffe37a5f8a41342e23c59  
glib-2.25.13.tar.gz

There should be no API/ABI break time time around (at least compared to
last time).

We still expect to break GApplication API soon -- but that has been
pushed to 2.25.14 most likely (which should come some time next week or
the one after).

Here's the news:


Overview of Changes from GLib 2.25.12 to GLib 2.25.13
=

+---+
|   WARNING: There have been no breaks in API or ABI.  Weird, eh?   |
+---+

The primary purpose of this release is to fix a serious problem with
glib 2.25.12: glibconfig.h (as generated on a Fedora amd64 system) was
being distributed in the tarball.  It was being used to build some parts
of glib on other systems (eg: 32bit ones).  This was causing some very
serious problems.

There have been many other improvements, however:

 Build and testing:
  - vastly improved test coverage
  - old tests moved to the gtester framework
  - gtester Makefile modified so that the tests only run once
  - cleanup of how we handle includes while building glib

 GVariant:
  - add a g_return_if_fail (utf8) to g_variant_new_string()

 GDBus:
  - perform extra sanity checks when serialising messages
  - add API to query and set the byteorder of a GDBusMessage
  - improve debug output, add some extra options
  - if exiting due to the bus disconnecting us, print an error message
explaining why
  - sort property names correctly
  - don't bother sending RemoveMatch when we will close the connection
anyway
  - use effective uid/gid for credential passing

 GSettings:
  - add G_SETTINGS_BIND_INVERT_BOOLEAN for inverting boolean bindings
without mapping functions
  - mark all strings in the schema compiler for translation

 Binding:
  - improve closure support for bindings
  - copy GSettings INVERT_BOOLEAN flag

 Other:
  - fix another complicated GCancellable deadlock possibility

Bugs closed:
 599590 glib build doesn't look for correct pkg-config
 619026 avoid warning in gutils.h when using gcc with -Wconversion
 624739 Please fix POTFILES.in
 625472 Valgrind claims uninitialized bytes used
 625500 g_date_set_time_val documentation doesn't mention local time
 625628 GDBusProxy: wrong property name sorting
 625753 Incorrect flags used in g_dbus_connection_call_sync()
 625827 Expand documentation about error quark naming
 625988 builddir != srcdir issues
 626107 glibconfig.h is being disted

Updated translations:
 French
 Galician
 Hebrew
 Norwegian bokmål
 Spanish


The contributors to this release:
 Dan Winship
 David Zeuthen
 Emmanuele Bassi
 Fridrich Štrba
 Hannes Müller
 Mark Wielaard
 Matthias Clasen
 Milan Crha
 Philip Withnall
 Stef Walter
 ...and at the very last minute, Benjamin Otte.


Sorry for 2.25.12. :)

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

GLib 2.24.2 released

[Ryan Lortie]

Glib 2.24.2 is out:

  http://download.gnome.org/sources/glib/2.24/

3aeb521abd3642dd1224379f0e54915957e5010f888a4ae74afa0ad54da0160c  
glib-2.24.2.tar.bz2
a6874b847d99618edb4bf86732ce00357711529a2592ded17e246063ad9f3374  
glib-2.24.2.tar.gz

This is a small bugfix release.  Its primary purpose is to get the
long-since-fixed data corruption issue in GConverterOutputStream into a
packaged release.

There is also a workaround for the long-standing race condition in
gtester that sometimes causes 'make check' to hang.

Some other small fixes and translation updates are included.

I avoided more extensive backporting of fixes because the nature of the
master branch of glib has been quite hectic lately and because a 2.26.0
release of glib will be out within a month or so anyway.


Overview of Changes from GLib 2.24.1 to GLib 2.24.2
===

* Bugs fixed:
 578295 gtester has a race condition
 619945 GConverterOutputStream triggers assertion and corrupts data
 621168 GKeyFile memory leak on Windows platform
 616216 glib compile from remote directory fails

* Translation updates:
 Estonian
 French
 Galician
 Indonesian
 Italian
 Latvian
 Romanian
 Spanish

Thanks to all who contributed:
 Christian Dywan
 Jürg Billeter
 Tor Lillqvist
 Matthias Clasen


August 8, 2010
Ryan Lortie

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Gtk Hackfest update

[Ryan Lortie]

hi Everyone,

Claudio has been in contact with the hotel for the hackfest and has made
a "prebooking".  We have received a very discounted rate, but the hotel
needs to know in advance exactly how many people will be coming.

For this reason, we ask that everyone ensure that they are listed on the
wiki for the hackfest by September 6th at the latest.

Past this date we cannot guarantee that there will be space in the hotel
or that your accommodation will be funded by the foundation.

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: gtk_widget_draw()

[Ryan Lortie]

hi Havoc,

On Mon, 2010-08-09 at 12:46 -0400, Havoc Pennington wrote:
> How would we handle widgets that currently have multiple windows and
> draw different things to each one (i.e. the expose handler is looking
> at the window in the expose event).
> For example GtkTextView

I think we should just fix these.

It seems like the only GtkWidgets that posess GdkWindows ought to be
toplevels (windows, popups, etc) and GtkPlug/GtkSocket.

That said, I really have no concept about the amount of work required.

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

GTK Team Meeting tomorrow

[Ryan Lortie]

hi all,

Just a reminder that we're planning to have a GTK Team Meeting tomorrow,
Tuesday September 7 at the usual time and place.

See the details here:

http://live.gnome.org/GTK+/Meetings

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

freezing for GLib 2.26

[Ryan Lortie]

Hello everyone

I plan on branching glib-2-26 early next week and removing GApplication
(and related classes) from the branch.  At that point, I will consider
the branch to (soft) frozen.  Of course, we will allow bug fixes past
that point.  Documentation and tests will also be allowed, as will be
important last-minute fixups, if they are well-reviewed.

I know of a couple of outstanding items from David and Emmanuele.  Those
are expected to land before I branch.  Other than that, this is your
last chance to speak up if you have anything planned for GLib 2.26.

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: freezing for GLib 2.26

[Ryan Lortie]

On Fri, 2010-09-10 at 08:58 -0400, Morten Welinder wrote:
> GDateTime still has API issues.

These are the changes that I mentioned Emmanuele was working on.

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

GLib 2.25.16 and 2.27.0 released

[Ryan Lortie]

  Japanese
  Lithuanian
  Norwegian bokmål
  Polish
  Portuguese
  Punjabi
  Simplified Chinese
  Slovenian
  Spanish
  Swedish
  Swedish
  Traditional Chinese

The list of contributors since 2.25.15:
  Benjamin Otte
  Christian Hergert
  Christian Persch
  Damien Lespiau
  Dan Winship
  David Zeuthen
  Emmanuele Bassi
  Joe Marcus Clarke
  Jon Nordby
  Kristian Rietveld
  Matthias Clasen
  Sam Thursfield
  Thiago Santos
  Tomeu Vizoso
  Tor Lillqvist
  Will Thompson


Ryan Lortie
September 17 2010

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

GLib status update

[Ryan Lortie]

Hello everyone,

I just released GLib 2.25.16 and 2.27.0.

The 'master' branch in git is now tracking the 2.27.x series and the
2.25.x series is on the 'glib-2-26' branch.

'master' is more or less completely open now (except for the normal
restriction that any changes must be backward compatible with what's
currently in the glib-2-26 branch).  Any bug fixes made here should be
cherry-picked into the glib-2-26 branch.

We expect that there may be some other last minute changes impacting the
API of 2.25.x.  Those changes should be discussed here or on IRC, before
being made to both branches at the same time.  We should really keep
that to a minimum though, since I just made a release announcement
promising no big changes.

'glib-2-26' should be considered frozen for all other purposes.

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

GLib 2.25.17 released

[Ryan Lortie]

Hi all

A somewhat serious bug was discovered in GLib 2.25.16 as it was released
yesterday -- a complete failure to build against the system-installed
pcre (see bug #629971).

Because of the late date in the cycle leading up to GNOME 2.32, the
inconvenience to our users and distributors is great enough to warrant
the effort required to roll a new release.

So here's GLib 2.25.17 :)

  http://download.gnome.org/sources/glib/2.25/

ba2543fa9dceb7dbcfbf00dcc3773cd649ef1698d7f7ad401f136e980559777d  
glib-2.25.17.tar.bz2
a932cceba58bf1c2d5d3c699fef3ad49823b27cc98381a1eafdcf8145a91761b  
glib-2.25.17.tar.gz

Other than the bugfix mentioned above, the Portuguese translation was
also updated.  There were no other changes.

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

GLib 2.26.0

[Ryan Lortie]

Good day!

At long last, the GLib 2.25.x saga has come to an end.  You can grab
your 2.26.0 tarballs here:

http://download.gnome.org/sources/glib/2.26/

4c18e3aadb5b20acc7c0f7d3a77da8a2843b85a9fd73fd3aa360a7aea953e3b2  
glib-2.26.0.tar.bz2
844bb4612c50898a9a349ab28f4843cb5e45b7fabfae3f3e8adca87b387f8032  
glib-2.26.0.tar.gz

Of course, this is a stable release with an API promise.  No more of
those nasty slips and breaks!

We turn our focus to 2.27.x hacking now, but there will surely be a
2.26.1 along in the coming weeks with some fixups.

There are just a few final changes:

Overview of Changes from GLib 2.25.17 to GLib 2.26.0


GSettings:
 - allow override files to have entries for non-existent schemas
 - schema compiler no longer aborts due to an error in a single .xml
   file

GDBus:
 - fix some race conditions in the connection test cases

GDateTime:
 - hide some implementation details (time zones)
 - fix parameter naming in header file to match .c file
 - add G_GNUC_WARN_UNUSED_RESULT for modifier functions
 - add full ISO 8601 week date support and improve docs

Other:
 - g_quark_try_string(NULL) now returns 0 without error
 - clean up confusing code in GSocketControlMessage
 - fix SOCKS5 memory leak
 - improve some docs

Bugs closed:
 628937 gracefully handle broken schemas
 629687 leaks class refcount in gsocketcontrolmessage
 63 g_date_time_difference
 630077 GDateTime week number support
 630185 Allow NULL strings in g_quark_try_string()

Translations updated:
 Basque
 Brazilian Portuguese
 Bulgarian
 Czech
 Danish
 Dutch
 Estonian
 French
 Greek
 Hebrew
 Japanese
 Korean
 Romanian
 Russian
 Spanish
 Traditional Chinese


Thanks to the contributors this time around:
 David Zeuthen
 Stefan Kost
 Claude Paroz
 Philip Withnall
 Behdad Esfahbod
 Colin Walters

And a very big thanks to the dozens of people who have contributed
during the 2.25.x cycle.

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Doubts about GPeriodic

[Ryan Lortie]

hi Havoc,

First I want to note that GPeriodic was only an attempt to get the
timing right.  It's just a clock.  It is not in any way meant to provide
policy about how a paint cycle is actually run.

That said, I did make a Gtk branch with some crackful experimentation
(currently shoving GPeriodic into gdkthreads in a global way).  This is
not meant to be "the way" -- it was just a convenient place to stick it
for now so that we could experiment with getting some widgets animating
using it.  Of course, we're discovering that resize handling and stuff
is quite difficult (another mail for all that stuff).

It's worth noting, though, that Emmanuele was able to get Clutter's
paint cycle working on top of it without modification, so there is
something here...

Anyway.  GPeriodic is just a clock, so let's talk timing.

On Thu, 2010-10-21 at 03:09 -0400, Havoc Pennington wrote:
> Another thought, in the patch
>periodic->last_run = now;
> I think this will look a little rocky - the frames are going to
> display at actual-screen-hz intervals, no matter what time it is when
> you record last_run and no matter what time it is when you call your
> drawing APIs. So things look better if you keep the "tween timestamp"
> on hz intervals. The last_run time probably has very little to do with
> when frames hit the display. Animations should go ahead and paint
> assuming they are hitting the display at a fixed fps.

This is something that gave me a great deal of pause, and is a rather
interesting question.  I'll attach the full code fragment in its current
form, for context:

  /* Update the last_run.
   *
   * In the normal case we want to add exactly 1 tick to it.  This
   * ensures that the clock runs at the proper rate in the normal case
   * (ie: the dispatch overhead time is not lost).
   *
   * If more than one tick has elapsed, we set it equal to the current
   * time.  This has two purposes:
   *
   *   - sets last_run to something reasonable if the clock is running
   * for the first time or after a long period of inactivity
   *
   *   - resets our stride if we missed a frame
   */
  now = g_periodic_get_microticks (periodic);
  elapsed_ticks = (now - periodic->last_run) / 100;
  g_assert (elapsed_ticks > 0);

  if G_LIKELY (elapsed_ticks == 1)
periodic->last_run += 100;
  else
periodic->last_run = now;

[[and yes, I'm using G_LIKELY strictly for documentation purposes]]

In the usual case, it's true that the ticker (which is expressed in
microframes, by the way) is advanced exactly one frame when dispatching
from the main context (ie: free-running clock with no external synch
information from vblank).

The only place I disagree with you is on what to do when we want to skip
a frame.

> In the litl shell fwiw the pseudocode for the tween time on each frame is:
> 
> int frame_time = 1000 / fps;
> int actual_time =  - current_ticker_time;
> int frames_late = (actual_time / frame_time) - 1;
> current_ticker_time += frame_time;
>  if (frames_late > 0) {
> current_ticker_time += (frame_time * (frames_late + 1));
>  }
>
> The idea of this is: decide to drop frames based on floor(frames_late)
> and then skip ahead by ceil(frames_late). The point of that is to bias
> against dropping a frame until we're a full frame behind, but then be
> sure we drop enough frames to get ahead a bit when we do drop them,
> and always stay on a multiple of the refresh rate.

This is an interesting proposal.

The problem when the clock is free-running is that we don't know exactly
what side of the vblank we're on.  That's the point of resetting the
stride (ie: assuming that the new top-of-the-frame time is now).  That
might end up being right, or it might be wrong.  In the event that we
are late for only one frame, it's a cointoss.

On the other hand, if we are consistently dropping frames -and- are
unaware of the vblank, I think I could mount a statistical argument that
my approach is more likely to result in a more smooth/accurate animation
(say, RMS of correct position vs. actual position for each frame that
actually hits the monitor).

Far more interesting, I think is in unblock():

  periodic->last_run = g_periodic_get_microticks (periodic);

In the event that we *do* have vblank information, we set the counter to
exactly the wallclock time at some semi-random interval (namely:
whenever our process bothered to notice the notification from the X
server).

I'm actively unhappy with that.  I was talking with Emmanuele about the
information that's in the vblank notification we get from the server.
There is timestamp information there.  I'd be quite a lot happier if we
had a method to inject that information into GPeriodic (ie: a timestamp
parameter on the unblock API).

> Due to this and also the desire to not explode when the computer's
> clock is set, I would define the ticker to be a monotonic value that
> is in time units but is not a wall clock time. i.e. if I change my
> computer's clock back an hour,

Re: Doubts about GPeriodic

[Ryan Lortie]

Hi Owen,

A few questions, if you don't mind me picking your brain:

On Wed, 2010-10-20 at 14:58 -0400, Owen Taylor wrote:
> The real problem is that the phases of the repaint cycle matter. We
> don't just have a bunch of stuff we need to do every frame, we need to
> do things in the order:
> 
>  * Process events

The only benefit I see to processing input events at the start of a
frame cycle is that we possibly get to merge them.  We probably do want
that.

What about non-input events, though?  Like, if some download is
happening and packets are coming in and causing dispatches from the
mainloop that we do not have control over.

Do we try to ensure that those people treat this 'external stimulus' in
the same way that we treat events (ie: possibly merge multiple incoming
packets so that they update their UI state only once in response to it)
or do we want them to just call the GTK API on the spot and risk
duplicated work because that's quite a lot easier to understand?

Maybe we should have some mechanism that allows them to choose.

If we elect not to have that mechanism, then the input problem is
actually quite easy, by virtue of the fact that there is only ever one
person managing input from the X server.

>  * Update animations

"tick"

>  * Update layout

Clutter and GDK want to do two different things here, it seems.
Presently (and almost by chance) GPeriodic is emitting a "tick" signal
after running all of the tick functions and Emmanuele is using this to
run "stage updates" on all of the Clutter stages.  This is a little bit
like Gtk managing it's geometry but not exactly.

In Gtk's case, we have a chance to do this a bit more programmatically -
only run layout adjustments on widgets/windows that have been marked as
requiring some resize (ie: toplevels and containers with
GTK_RESIZE_QUEUE themselves).  That could be handled from a 'tick'
handler, or we could add some more hooks to GPeriodic.

A reason that I think it makes sense to do layout updates separate from
repainting is that layout updates can result in us wanting to change the
size of our toplevels (eg: someone opened GtkExpander).

This is a *really* tough problem because if that happens, we can't just
paint.  We have to wait until the window manager has actually given us
our new size.  I did some benchmarking, and that tends not to happen
until about 1ms later (a bit less for metacity, a bit more for compiz
and mutter).

So do we block the mainloop for ~1-2ms and desperately suck from the X
socket until we receive ConfigureNotify (at least until some timeout)?
Do we skip drawing the window and wait until next frame if we have a
pending ConfigureNotify?  Is there some way we can abuse
_NET_WM_SYNC_REQUEST to make this problem easier?


On the Gtk experiment branch, layout updates are actually done pretty
much "on the spot" right now (ie: you make some changes to the layout
which will queue a idle that will run pretty much immediately).  There
have been no changes to this part yet.

>  * Repaint

This part is what I originally intended the damage/repair mechanism to
be used for.

> If GTK+ and Clutter are working together in the same process, then we
> still need to go through those phases in the same order and do
> everything for each phase.
> 
> It looks like GPeriodic has two phases:
>  
>  - Tick
>  - Repair
> 
> Which I guess are meant to be "update animations" and "relayout and
> repaint". I can sort of see how I can squeeze the right behavior out of
> it given various assumptions. In particular, you need to only ever have
> one one repair function that does all the work of relayout then repaint
> - you can't have separate repair functions for relayout and repaint. Or
> for clutter and for GTK+.

GPeriodic is probably going to need to gain some more phases, indeed.  I
don't plan to have relayout and repaint shoved into the same stage for
the reasons listed above, but also for reasons of sanity.

> But does an abstraction make sense at that point? If we need to
> explicitly glue GTK+ into clutter or clutter into GTK+ using hooks
> provided in GTK+ and Clutter, then all that GPeriodic is doing is saving
> a bit of code reuse.

Right.  Another way we could do this is by having some hooks in Gtk:

  - do this
  - do that
  - do the other thing

and have those clocked internally by Gdk in the Gtk-runs-itself case and
by Clutter in the Clutter-runs-Gtk case.

That certainly could make sense for the "set tasks" like layout,
drawing, etc.  In fact, all of these things could be driven by
one-big-handler on the "tick" signal that GPeriodic currently emits.

For timeline advancement, however (ie: the stuff that the user wants to
do) I think an abstraction like GPeriodic is quite useful.  It gives a
common place that users can register their animation hooks that works
the same way for both Clutter and Gtk.  It prevents us from having some
timeline system within Gtk that is clocked by Clutter telling Gtk "run
all your timelines now!".  Cody is cr

Re: New rule

[Ryan Lortie]

hi Bastien,

On Thu, 2010-10-21 at 17:44 +0100, Bastien Nocera wrote:
> I'll also note that some apps can't be ported, like gnome-control-center
> or totem because the only way to get arguments is through "open" which
> only deals with files/URIs.

Give G_APPLICATION_HANDLES_COMMAND_LINE in the GApplicationFlags and
then connect to the "command-line" signal (or implement the vfunc).

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

threading / timers / etc

[Ryan Lortie]

Hello

We have an agreement at the hackfest that I will do the following things
now:

  - Starting immediately, glib will depend on librt (and therefore
libpthread) on systems that have it.

  - We will add GTimeSpec which is GTimeVal using nanoseconds instead of
microseconds (same story with struct timeval vs. struct timespec).
The librt interfaces provide this level of accuracy so it would be a
shame to needlessly discard it.

  - We will expose an API in glib that gives the monotonic time (if
possible) or otherwise falls back to the wall clock time.  gthread
on Windows is using GetSystemTimeAsFileTime for example (which is
wall clock time), so not much more we can do there...

  - g_source_get_current_time() will be deprecated and replaced with an
API based on monotonic time.

  - Existing sources in glib (timeouts, mostly) will use monotonic time
instead of wall clock time.

  - GPeriodic will use monotonic time for the timestamp value to the
"tick" parameter.

  - The rules about initialising the thread system do not change at all.

We also plan the following for the future ("glib 4.0"):

  - libgthread will stop existing, be folded into libglib and it will
become impossible to replace the default threading implementation
for your platform.  Threads will be "turned on" always.

Comments?

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Next major glib version number [was: threading / timers / etc]

[Ryan Lortie]

On Fri, 2010-10-22 at 16:14 +0100, Bastien Nocera wrote:
> glib 3.0 maybe? We're still discussing changes for glib 2.x, aren't we?

If you accept the following premises:

  - we can't break glib API without effectively also breaking Gtk API

  - we aren't going to bump glib's version number when we release Gtk3

  - we like glib to have the same version as Gtk in the long-run

then it becomes clear that we need to skip GLib 3.0.

Some of those premises could be up for debate, of course.

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Next major glib version number [was: threading / timers / etc]

[Ryan Lortie]

On Fri, 2010-10-22 at 13:28 -0400, Daniel Macks wrote:
> On Fri, 22 Oct 2010 17:20:45  0200, Ryan Lortie  wrote:
> >   - we aren't going to bump glib's version number when we release Gtk3
> X constant for Y=3
specifically, X=2 for Y=3

> >   - we like glib to have the same version as Gtk in the long-run
and X=Y for Y != 3

> Assertion failed: (X!=3)

I disagree :)


Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: threading / timers / etc

[Ryan Lortie]

On Fri, 2010-10-22 at 15:02 -0400, Havoc Pennington wrote:
> Hi,
> 
> On Fri, Oct 22, 2010 at 11:06 AM, Ryan Lortie  wrote:
> >  - We will add GTimeSpec which is GTimeVal using nanoseconds instead of
> >microseconds (same story with struct timeval vs. struct timespec).
> >The librt interfaces provide this level of accuracy so it would be a
> >shame to needlessly discard it.
> 
> I know this is a completely minor side issue to the point of your
> email (which sounds good overall) but I often find myself writing a
> convenience wrapper around g_get_current_time() that returns a single
> integer. If you do get_time(TimeSpec*) it might be nice to also do a
> "uint64 get_time_milliseconds()" wrapper.

Unfortunately the system monotonic clock is specified as "since some
unspecified starting point" (ie: you may not assume that it is zero when
the system started).  For this reason, and because the time_t from the
kernel could already be quite large, we can not safely stick monotonic
time into a single int64 with any precision greater than whole seconds.
This is not true with wallclock time, where we can safely assume that
our software will not be running in the year 2 (Y20K bug?).

Of course, it's "unlikely" that an OS would choose to do this...  I
don't feel willing, though, to hardcode sanity assumptions of every OS
kernel in the world into an API design.

I briefly considered having a per-process epoch whereby the first time
you request the monotonic time, that becomes "time zero".  After rolling
it over in my head a few times, I like it less and less.

I do plan to mitigate the problem substantially by providing some
convenience API for GTimeSpec -- add, subtract, return difference as
int64 of nanoseconds, create from milli/micro/nanoseconds, etc.  These
should help the situation quite substantially.

For something like GPeriodic, of course, we can continue to safely emit
the timestamp as an int64 number of microseconds (or nanoseconds, even),
relative to the time at which the GPeriodic was created (or first
started running).

Cheers


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: threading / timers / etc

[Ryan Lortie]

hi Pavel,

On Mon, 2010-10-25 at 11:24 +0200, Pavel Holejsovsky wrote:
> Just out of curiosity; would you mind trying to specify reasons why you 
> don't like it?

My general uneasiness with this idea developed along these lines:

 - If we have some API for getting this int64 for the current time then
it makes sense that we probably also want to have an API for
converting between GTimeSpec and this int64.

 - If we have that API then we need to initialise the process-specific
   offset the first time the API is used to convert a GTimeSpec to a
   int64.

 - It's not clear what would happen if we tried to do a int64 to
   GTimeSpec conversion first.  Crash?  Critical?

 - If someone passes a bogus GTimeSpec to the conversion call the first
   time then your process is more or less hosed for its entire life.


I settled on the idea that we might want to have more locally-scoped
epochs (like the time at which a GPeriodic was created, for example).


Because the only complication I can see with this 
> solution is that the clock is not monotonic across process borders 
> (although it is a bit hard for me right now to invent situation where 
> this would matter).

We're already planning to inject timestamps received from the X server
for vblank (generated in the kernel IRQ handlers, I think?) directly
into GPeriodic.  I can easily imagine other situations where this might
be useful.


Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

microseconds ought to be enough for anybody

[Ryan Lortie]

Hello

After an extensive process of dithering and soul-searching, I've come to
the following conclusions about time in GLib:

  - we have too many time types

  no explanation required.

  - microseconds ought to be enough for anybody

 A nanosecond is on the scale of individual clock cycles and
 processors are getting slower, not faster.  I have an extremely
 hard time imagining this sort of precision being meaningful (much
 less, actually useful) in our platform.  Heck; our mainloop is
 still based on milliseconds.

  - double isn't as good as int64

 Using doubles for time intervals is extremely wasteful.  Doubles
 were designed to represent extremely small and extremely large
 numbers -- orders of magnitude that we never meaningfully encounter
 while dealing with time.  Those extra bits used to express order of
 magnitude are lost for expressing actual information.  If we used
 fixed point, we get those 12 extra bits back.

 I also don't like the strange feeling that I get when I consider
 that the precision of double-based time expression slowly decreases
 with each passing year.  Not that it's really a practical
 consideration -- just a weird feeling.

  - use of int64-as-microseconds is already extremely common

 This is another reason to avoid doubles.

  - who cares about stupid platforms?

 I spent a significant amount of time hand-wringing over
 hypothetical "stupid" platforms that have the epoch of their
 monotonic clock in biblical times.  Although that's a theoretical
 possibility, I don't know of any such platforms and if they do
 exist, we can cross that bridge when we get there.  Our primary
 concern should be Linux -- and Linux is quite sane here.

The conclusion of all of this is one point: barring substantial
complaints, the be-all and end-all of time in glib is going to be
microseconds stored in a gint64.

GDateTime already calls this a "GTimeSpan".  That's OK.


I will do the following:

  - rip out the newly introduced GTimeSpec and all APIs using it

  - deprecate GTimeVal and all APIs using it

  - replace both with APIs using int64 of microseconds

  - deprecate GTimer

with int64-based time, it's trivially easy to do it yourself


Somewhat related (but not directly): I'd like to deprecate GDate (and
the half-dozen or so related types) in favour of eventual replacement
with a GDateTime-style immutable opaque structure.  I guess we could
call that GDay (pronounced "g'day") for lack of a better available name
or we could wait until glib4 and replace GDate with GDate at that point.
Probably we should consider support for non-Gregorian calendars before
that point anyway (the fabled GCalendar API).

I'm going to start pushing this work into a branch today and I'll merge
it to master quite soon unless there are objections.

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: microseconds ought to be enough for anybody

[Ryan Lortie]

On Mon, 2010-11-01 at 10:06 -0700, John Ralls wrote:
> +1
> 
> I don't see any reason to have a replacement for GDate. Just add any
> extra functionality it provides to GDateTime -- which, with int64,
> will be good for +/- 290,000 years from whatever its epoch date is,
> with microsecond resolution. That should be sufficient for everyone
> except astronomers, who have their own time libraries anyway.

GDateTime is currently bounded between Gregorian dates 0001-01-01
(proleptic) and -12-31.  I can't see any reason that we should
change that.

GDateTime was originally proposed to double as a 'date' type by having
"midnight on day" to roughly stand in for "day", with some APIs to make
that easier.

It turns out that there are a lot of reasons that you don't want to do
that, so any API that encouraged that sort of use was removed with the
idea being that we would add a proper construct for this in the future.

> As for bizarre OSes with epochs beginning at some time before the
> common era, well, if glib is ever ported to one a simple ifdef can
> just add the correction value and be done with it. No worries.

That's my current line of thinking.

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: microseconds ought to be enough for anybody

[Ryan Lortie]

On Mon, 2010-11-01 at 14:21 -0400, Havoc Pennington wrote:
> Well there's already G_USEC_PER_SEC but I guess it's saving typing of
> more zeroes.

Reading 1000 is very easy.  With 100 or 10, you usually have
to stop and count the number of zeros (see also: why 'thousands
separators' exist).

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Add GtkRadioGroup?

[Ryan Lortie]

hi Alex,

I was thinking of doing the same thing, but making the GtkRadioGroup
implement GAction with a state type of string (and each radio button in
the group being identified by a string).

Setting the action to a state equal to the name of a radio item would
activate that item.  Easy DBus exporting for all.

Thoughts?

Cheers


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Add GtkRadioGroup?

[Ryan Lortie]

hi Alex,

On Tue, 2010-11-02 at 13:42 +0100, Alexander Larsson wrote:
> I'm not sure forcing every radio item to have a name is a good idea.

Maybe true

> Also, I don't think exposing raw widgets as exported actions is a good
> idea. Its probably better to have more highlevel actions, or at least
> some separation between action specification and implementation.

I think that, at a minimum, anything that appears on a menu should be on
the bus.  There are a number of reasons for this -- ability to support a
global menu, a reasonable level of baseline scriptability, etc.

The case where the radios are directly inside of some API doesn't
necessarily mean that they should not be scriptable, but we could allow
for that.

I don't see naming of radios in a radiogroup as too much different than
naming of radioactions...  Maybe it's actually radioactions that I see
as being in the group... Sort of makes sense if you're viewing buttons
as the view component and actions/groups as the underlying model.

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

microseconds update

[Ryan Lortie]

hi everyone,

I wrote an email yesterday detailing my goals to reduce GLib to having a
single type for time.  The work just landed on master.

Of course, there were complications.

Status report:

 - GTimeSpec is gone

 - g_get_monotonic_time() returns int64 time

 - new function g_get_real_time() returns wall clock int64 time

 - it's not really possible to deprecate GTimeVal at the moment due to
   its appearance in a large number of APIs and (most annoyingly) on the
   vtable of the thread implementation.

   It's on the glib4 kill list and I added a docs note about that.

 - GTimer is also not deprecated because it has a lot of users and it's
   not immediately clear that we should disrupt them.  GTimer is
   switched to monotonic time, though, and is using int64 internally.

   I had one uneasy feeling while looking at removing GTimer.
   g_timer_elapsed() rather conveniently returns a double -- which is
   great for whacking directly into a printf statement.  Many people use
   it this way.  Of course, it's quite easy to do the math yourself, but
   not quite as nice.


So far I'm using int64 everywhere, but I wonder if we should introduce
some extra meaningless typedefs to improve the self-documentation of
function signatures and user code.  We already have GTimeSpan to
represent the distance between two times, but it's clear that we should
not use that for absolute representation of either monotonic or
wallclock time.  Perhaps we should also have two new types to represent
absolute values of wall-clock time and monotonic time.

I'm not crazy about the caps used on GTimeSpan (being that it's an
integer type).

I guess my preferred names for the new types would be "gmonotime" and
"grealtime".  We could also go the route of having a single new type,
gtime.

Or nothing at all.


Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

GPeriodic update

[Ryan Lortie]

hi,

After a lot of travel I've been at home for more than 24 hours.  I got a
chance to read through the GPeriodic thread (mostly between Owen and
Havoc).

I've done the following as a first attempt to improve the situation:

GPeriodic now has two GSource priority levels, which it calls "high" and
"low".  The high level is the normal priority level at which the
GPeriodic source is registered.  There is not normally a source
registered at the low level.

GPeriodic measures how long its "run" function takes (the sum of
dispatching tick and repair functions).  It then multiples this amount
by two.  If the result is bigger than the duration of a single frame
then it sets an internal flag to indicate that it wants to skip frames.

The number of frames skipped is the (rounded down) whole number of
frames corresponding to twice the time it took to do the painting.  This
means that if you took less than half of the frame time to do painting
then no frames will be skipped.  More than half (but not one whole frame
time) then 1 frame will be skipped, and so on.

That means that at least 50% of the time is given to "other things".

The source continues to be registered with the mainloop at its high
priority -- it just signals that it doesn't want to run until the next
frame time (as delayed by the skip count).

At any time that the skip count is set to a non-zero value, an idle is
added to the mainloop at the "low" priority level.  If this idle gets a
chance to run then it directly sets the skip count to zero.  This way we
can use up to 100% of the CPU for painting, as long as nothing else is
trying to run.

I believe that this approach is the essence of what we should do and I
think that it's the most direct way to do it.  The details about
deciding exactly how many frames to skip (eg: based on a rolling average
instead of one immediate measurement) should still be worked out, of
course.

Patch is here:

http://git.gnome.org/browse/glib/commit/?id=63b87b2c26bf983823f83943b8d752bd053ce539

I'm aware of the increasing ickiness of my "reset our stride" code and
I'm already considering the best way to deal with this.

Comments are extremely welcome at this point.

Otherwise, see you in Boston. :)

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: comments on gio TLS (SSL) APIs wanted

[Ryan Lortie]

Dear everyone:

please take note :)

On Thu, 2010-11-11 at 15:07 -0500, Dan Winship wrote:
> Discussion should happen mostly in bugzilla I guess? Thanks in advance...


Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: radio-group branch

[Ryan Lortie]

On Wed, 2010-11-10 at 08:23 +0100, Alexander Larsson wrote:
> So, what do you want to do here? How do we land this?

I'm against landing it in its current state because I remember yet
another reason that I think we want to have names for radio buttons
within a group: it's the only sane way to deal with binding a radio
group to GSettings.

That was actually my first motivation.  After that is when I got the
idea "oh, may as well make it a GAction too then".  I forgot the first
motivation by the time I mentioned it to you before.

Cheers


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: radio-group branch

[Ryan Lortie]

On Fri, 2010-11-12 at 12:37 +0100, Alexander Larsson wrote:
> I'm not inherently against naming the buttons. It would be nice if we
> got a third argument to the group active-changed signal that lets you
> avoid having to compare button instances to see which one is active.
> Although in code it might be better to allow any gpointer as "name" for
> the button so you could put in random user data.

The best way for GSettings to use this would be if it were a GObject
property of type string (so you could bind to it).

> Anyway, I don't see that the current code needs much work to add this.
> Just add a .._set_radio_name() to all radio-button widget types and then
> propagate this to the group? Its a small incremental patch to the
> current branch.

Yes.  That's about it.

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

dconf 0.7 released

[Ryan Lortie]

Hello everyone

I just released dconf 0.7.  The two main improvements are an improved
dconf-editor and a new library for using dconf with libdbus-1.

  http://download.gnome.org/sources/dconf/0.7/

SHA256:

73fe932a2905ea99f7bc51efe7fe240f5ec87caa4959ab0c1ac65571ac14512c  
dconf-0.7.tar.bz2
e76c6b58a9d4273cf232511379ea0979dc6aff300b1fd07c626d8ba39ba2e426  
dconf-0.7.tar.gz

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

dconf 0.7.1 released

[Ryan Lortie]

Hello

The dconf 0.7 release contained a few bugs related to linking.  I've
released 0.7.1 to address those issues.  If you notice any more
problems, please let me know.

  http://download.gnome.org/sources/dconf/0.7/

SHA256:

  04b81606131a59362167e50e84b55ac2af49fdfa3ad4b5b0bdb07dc14bf5bd1d  
dconf-0.7.1.tar.bz2
  b37fc869d483581783a36683bc5d9b6ee1781dd44a0a5ef7114f3406bd5bef0b  
dconf-0.7.1.tar.gz

Sorry for the bad release.

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

dconf 0.7.2

[Ryan Lortie]

hi everyone;

dconf 0.7.2 is out today.

  http://download.gnome.org/sources/dconf/0.7/

SHA256:

  35fc51ef893dc3951bfc7abaee6adb8b77e501274b3a5292ed03db4e685ef03c  
dconf-0.7.2.tar.bz2
  722ec9439d9b54f791dd4b729bf7d6ae4ba52c9dbe096b35ad88e64665e628ac  
dconf-0.7.2.tar.gz

Changes in dconf 0.7.2
==

This is entirely a cleanup/fixes release.  Some fixes here to make the
increasingly-strict toolchain happy, and also some fixes for some
crashers in the GSettings backend and service.

 - remove some unused variables (new GCC gives a warning: #640566, another)
 - add a mutex to fix multi-threading issue (#640611)
 - don't crash if we have no D-Bus
 - clean up symbol exports
 - fix a crash in the service when using 'reset'
 - drop old linker options that were for libtool


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

G_CONST_RETURN

[Ryan Lortie]

(replies to gtk-devel-list please)

Greetings,

I just opened bug #644611 about deprecating G_CONST_RETURN.

After discussing this with Matthias on IRC, it is our intention to phase 
out use of this macro in our platform.  The usual way that we would do 
that is by removing our own use of it and marking it as deprecated (and 
guard its definition with the usual G_DISABLE_DEPRECATED check).


Unfortunately, the macro appears very widely in the headers of many of 
our platform libraries.  If an application using G_DISABLE_DEPRECATED 
#includes one such header, their build is broken.  That would impact... 
well, just about everyone.


For this reason, we've decided to 'take it slowly'.  The current plan is 
to remove uses of the macro from glib and gtk+ and add a notice about 
the pending deprecation to the documentation.  The next few months will 
serve as a 'grace period' for other libraries to clean up their headers. 
 After that, we will introduce the deprecation in the usual way and 
deal with the (hopefully reduced) fallout.


Cheers
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: How gvdb_table_is_valid works on glib/dconf

[Ryan Lortie]

hi Joshua

On 11-02-16 04:09 AM, Joshua Lee wrote:

I can not understand while gvdb_table_is_valid can check the on-disk
gvdb table is valid.


The very first thing that comes in any GVDB file is the string 
"GVariant".  That's normally why *data should be non-zero, so !!*data 
will be 1.


When dconf system databases are replaced, the old file has its header 
overwritten with zeros to indicate that applications need to reopen it 
on their next access.  This cases *data to be 0, so !!*data is also zero.


See this code in dconf-update, for example:


var fd = Posix.open (filename, Posix.O_WRONLY);

if (fd < 0 && errno != Posix.ENOENT) {
var saved_error = errno;
throw new FileError.FAILED ("Can not open '%s' for 
replacement: %s", filename, strerror (saved_error));

}

try {
table.write_contents (filename);

if (fd >= 0) {
Posix.write (fd, "\0\0\0\0\0\0\0\0", 8);
}
} finally {
if (fd >= 0) {
Posix.close (fd);
}
}


Basically, it opens the old file and holds on to the fd while replacing 
it with the new file.  It then zeros-out the header of the old file to 
indicate that users should reopen (thus getting the new file).


Hope that helps.

Cheers
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [PATCH] dconf: increase minimum glib version

[Ryan Lortie]

hi Robert,

On 11-02-10 03:51 PM, Robert Schwebel wrote:

what do you think about this patch?


Sorry for the delay.  I'm a somewhat casual reader of this list so I 
didn't notice your message.  The patch has been committed just now.


Thanks
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

please test: dconf 0.7.3

[Ryan Lortie]

I just released dconf 0.7.3.

I consider this release to be more or less 'frozen' for the GNOME 3 
release.  If emergency changes are needed then we can make those and 
release another tarball, but otherwise I will probably just let this one 
go out with the release.


In short: please package and test this and give me feedback promptly.

  http://download.gnome.org/sources/dconf/0.7/

SHA256:

84efc95cb62b6637b2131e110ff447908be739c2185d69bebb300293b561dfd9 
dconf-0.7.3.tar.bz2
7b208f3050d68d103bf0b8f8171dbd224430cf36bb461cbe6072b011da80fb7e 
dconf-0.7.3.tar.gz


Changes in dconf 0.7.3
==

This release consists almost entirely of fixes made by Robert to
dconf-editor.  A few other trivial build fixes are included as well
(bumping library version dependencies to match reality, etc).

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Small glib 2.28 patch for Win32

[Ryan Lortie]

hi Alex,

Thanks for contacting me about this.

On 04/15/11 04:19, Alexander Larsson wrote:

On Mon, 2011-04-04 at 12:34 +0200, Kean Johnston wrote:

Because it doesn't include config.h and since it was code that was sort of
living off to the side and I didn't know if it would be appropriate to
introduce a dependency on autoconf/configure/config.h, I did it a more
portable way.


Yeah, this code seems shared between various modules.
Ryan? What is your prefered way to fix this?


Kean: I agree pretty much entirely with your analysis and I appreciate 
your careful consideration in this area.


I'm going to apply your fix, as originally suggested, to the 'upstream' 
gvdb module and then resync with GLib.


Thanks for pointing this out.

Cheers
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

dconf 0.7.4

[Ryan Lortie]

hi everyone

I just released dconf 0.7.4 with two long-awaited feature improvements.

First, the commandline tool no longer sucks.

Second, we have system lockdown support via editing text files and dconf
update (which apparently is how most people want to do it anyway).  I'll
update the wiki with documentation for that soon.

Cheers



News


Changes in this version:

  - #648949: multithreading issue fixed (which actually affects all
GSettings-using programs since dconf is used from a helper thread in
that case)

  - dconf commandline tool is vastly more friendly now

- no more aborting on unrecognised arguments

- proper help

- bash completion support

  - support for sysadmin lockdown

  - the editor now properly reads installed enum xml files



Download


http://download.gnome.org/sources/dconf/0.7/dconf-0.7.4.tar.gz  (262K)
  sha256sum: e96cd3ab75d5639d4a744391e6745ed115658fdd0953f85287c84405335ab7cc

http://download.gnome.org/sources/dconf/0.7/dconf-0.7.4.tar.bz2 (187K)
  sha256sum: 299d79daf0b214c692e7d5788d7bda76d778c1748ea37c33256c4fa6143b22cd


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

dconf release strategy

[Ryan Lortie]

Hi.

I recently released dconf 0.7.4 which mixed bug fixes with a pair of
major enhancements.  Many distributions were quick to package it due to
the bug fix part.

It turns out that one of the enhancements contained a trivial bug with a
rather extreme result.  That's fixed now and I plan to have a 0.7.5 out
soon.

The incident has convinced me that dconf needs a more credible release
strategy.  The core of the problem is the fact that there is only one
branch of development and that feature additions and bug fixes are
happening on the same branch (and landing in the same releases).

My plan going forward is as follows:

  - 0.8 will be released soonish containing the fix for my mistake and
some other bugfixes collected from bugzilla.  It will be a stable
branch with only bugfixes.

  - I will branch 0.9 and do new feature work there.

  - I will try to keep the usual even/odd approach roughly in synch with
the GNOME release cycle (which will automatically place it in synch
with the cycles of many distributions).  This is only a loose
synchronisation but I will try to keep people's needs in mind.

Sorry for the mistake.  Hopefully this new approach will prevent it from
happening again.

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

dconf 0.7.5

[Ryan Lortie]

hi

As a quick follow-up to dconf 0.7.4 here is 0.7.5.  This release fixes
the major crasher in the last release and attempts to incorporate some
vendor patches that distributions had been carrying.

Robert didn't get the memo about no new feature development before the
0.8 release and added a bunch of nice stuff to the editor.  Since some
changes to the build system were involved, I'm releasing 0.7.5 to let
the dust settle before going to 0.8.0.

Please provide feedback about any problems that you encouter.

Cheers


News


This release corrects a serious flaw in the previous release: crashing
if the database did not already exist.

It also contains many fixes and improvements to the dconf-editor,
including use of GSettings to store the window geometry.

This is the final release before 0.8.0 which will become the first
release in a new stable series.  Feature development will continue on
'master' toward 0.9 past that point.



Download


http://download.gnome.org/sources/dconf/0.7/dconf-0.7.5.tar.gz  (266K)
  sha256sum: a5f627fb80515f6baa769977d53238ae193efc58f69c1c8b3d04ca78ef9161db

http://download.gnome.org/sources/dconf/0.7/dconf-0.7.5.tar.bz2 (189K)
  sha256sum: e2103e8207744903790e9fac6427fa394bb485a0c7f4e0d03b0fb43268c34f33



___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Initial work on a help API

[Ryan Lortie]

On Wed, 2011-05-18 at 09:29 -0400, Shaun McCance wrote: 
> With some GApplication work, we could get applications to read
> something from their .desktop file. Then it could be explicit,
> e.g. X-Launchpad-ID= You'd still have to patch applications,
> but with a one-line patch to a data file instead.

I raised the point on the xdg list that I want to add application
identifiers (of the "org.gnome.Foo" sort) to desktop files.  Michael
Vogt has plans to make this data available in apt (by sucking it out of
the desktop files).

We could go from application ID to package name (and from there
launchpad ID) without the need to patch anything at all.

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: G_CONST_RETURN

[Ryan Lortie]

(replies to gtk-devel-list please)

hello desktop-devel and gtk-devel lists,

On Sat, 2011-03-12 at 22:47 -0500, Ryan Lortie wrote: 
>  The current plan is 
> to remove uses of the macro from glib and gtk+ and add a notice about 
> the pending deprecation to the documentation.  The next few months will 
> serve as a 'grace period' for other libraries to clean up their headers. 
>   After that, we will introduce the deprecation in the usual way and 
> deal with the (hopefully reduced) fallout.

It's been a few months.  I've committed removal of use of G_CONST_RETURN
to GLib (fixing a few problems in GObject) and added the deprecation
notice to the documentation.  Javier, Emmanuele and myself have been
fixing various libraries and applications.  We've filed bugs and
committed a lot of fixes to various low-level things like atk, pango,
gdk-pixbuf, gtk+, clutter and many others.

It's been a few months, and there have been no objections, so we're just
about ready to go ahead with the next stage of the plan.  If you haven't
already done so, please check your modules for G_CONST_RETURN and
replace it with plain "const".  If you're using G_DISABLE_CONST_RETURNS
then please take the time to fix your code not to depend on this hack.

  http://people.gnome.org/~fpeters/reports/g_const_return.html

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

GLib 2.29.14

[Ryan Lortie]

hi all,

Only a few days after the previous release, GLib 2.29.14 is now out.
You can grab it from the normal place:

  http://download.gnome.org/sources/glib/2.29/

The checksums:

  2e407742b60c7b6e48527e6f6f5cf1fe8ea7494a55b3a070ebf04cabe044fe5a  
glib-2.29.14.tar.xz
  d474069c198fb63e0cab401f1baf054c57fe7db9c55650c3d8347d686ca163a0  
glib-2.29.14.tar.bz2

Overview of changes from GLib 2.29.12 to 2.29.14


* Unicode improvements
 - add g_unicode_script_{to,from}_iso15924
 - add G_UNICODE_SPACING_MARK define
 - more normalisation improvements
 - stop using deprecated g_unicode_canonical_decomposition()

* GParamSpec:
 - mark the 'name' field as 'const' and add a comment to the header to
   help avoid future problems caused by bad hacks

* Merge some (modified) patches from Debian:
 - 03_blacklist-directories.patch
   - add some blacklisted mount directories
 - 60_wait-longer-for-threads-to-die.patch
   - sleep longer in a test case, if needed to avoid failing

* Units policy change: prefer use of SI units
 - deprecate g_format_size_for_display, add g_format_size(_full)

* GSettings: don't call g_error() when the schema is missing

* GVariant support for arrays of object paths:
 - new g_variant_{new,get,dup}_objv API
 - support for g_variant_{new,get} '^ao' and '^a&o' similar to '^as'

* GDBus:
 - use new improved array-of-objects support and pass 'ao' as char**
   instead of GVariant*
 - improve handling of 'h' type (Unix file descriptor index)

* GIO:
 - fix compilation without USE_STATFS and USE_STATVFS

* Documentation fixes

* Bugs fixed:
 622921 Migrate from dbus-glib to glib's GDBus
 648271 Add g_unicode_script_to_iso15924()
 654948 Stop using deprecated g_unicode_canonical_decomposition()
 654988 g_atomic_int_add should document behaviour change
 655025 #define G_UNICODE_SPACING_MARK G_UNICODE_COMBINING_MARK
 655076 normalization misses some Full_Composition_Exclusion=True.

* Translations updated:
 Spanish


Thanks to everyone who had a hand in this release:
 Behdad Esfahbod
 Benjamin Otte
 Dan Williams
 David Zeuthen
 Giovanni Campagna
 Simon McVittie
 Vincent Untz


Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

GLib 2.29 vs Gtk 3.0 instability

[Ryan Lortie]

hi,

I recently introduced a change into the GLib unstable branch that causes
all applications using Gtk 3.0 to crash:

  
http://git.gnome.org/browse/glib/commit/?id=d6c30e1766c975dd79e6f252d73c6c0581b64b01

The reason for the crash is this code in gtkthemingengine.c, added a
year ago:

  /* FIXME: hack hack hack, replacing pspec->name to include namespace */
  name = g_strdup_printf ("-%s-%s", name_space, pspec->name);
  g_free (pspec->name);
  pspec->name = name;

When I switched GParamSpec to consistently intern all strings, most of
the theming engines were hit quite badly by this bug (since the code was
attempting to g_free() interned strings).

A workaround was committed to the master branch of Gtk+ very shortly
after the problem was discovered:

  
http://git.gnome.org/browse/gtk+/commit/?id=7741f5a09a841c4dc93727b990defc303510ed2c

The workaround is incompatible with the old version of GLib, which is
okay since Gtk master branch already depends on new GLib for unrelated
reasons.

Sébastien Bacher pointed out that people who install new GLib versions
onto systems using the existing Gtk 3.0 stable series will still be
affected by the bug.  We want to avoid this situation.

Since any changes to the stable series cannot introduce a dependency on
an unstable GLib, I modified the workaround to check the GLib version
and do the appropriate thing.  I applied the fix to the gtk-3-0 branch:

  
http://git.gnome.org/browse/gtk+/commit/?h=gtk-3-0&id=98513a02a234b65d962bf771a886d435ab1946ca

This patched version of Gtk 3.0 should work fine against both the old
and new GLib versions, thus avoiding the "upgraded GLib" issue without
introducing a new GLib dependency.

I intended to make a point release on the Gtk 3.0 stable branch
yesterday but there are some other issues currently blocking that
release for the time being.  One will happen soon.  It is requested that
all distributors package this release as an update to their stable
series, or at least apply the patch above.  This will save your users
from crashes if they attempt to upgrade their GLib.

Sorry for the bumpy ride.

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

dconf 0.8.0 and 0.9.0

[Ryan Lortie]

hello

I just dropped releases of dconf 0.8.0 and dconf 0.9.0.

http://download.gnome.org/sources/dconf/0.8/dconf-0.8.0.tar.xz  (164K)
  sha256sum: 05111e973c365696759dd1b37e3f5acc877eff24dd2e4036d742aac5da5dda3b

http://download.gnome.org/sources/dconf/0.9/dconf-0.9.0.tar.xz  (169K)
  sha256sum: df16ba1af423145f968fb7d36d0a1bfd75f27aefb5d3016aaecb1ab311944581

dconf 0.8.0 is a bugfixes-only release that (as planned) is almost
entirely unchanged from 0.7.5.  This makes a reasonable update to the
stable release series of existing distributions.

dconf 0.9.0 has a whole host of nice new features:

  - support loading/storing of maybe types in dconf

  - remove NFS detection hackery and rely on XDG runtime dir

  - add proper support for change notification to DConfClient

  - commandline tool improvements

- reset: reset keys or entire subpaths

- dump: dump entire subpaths to keyfile format

- load: load them back again (maybe at a different path)

- watch: actually works now

  - editor improvements

- keys now change in editor when changed from outside

- support for flags

- show dconf-editor in applications list

  - work around incompatible Vala bindings changes with an #if

  - don't install the bash completion script as executable

  - fix a warning caused by reusing a GError variable

  - other small fixes

I know that dconf 0.9 shows itself in the applications list without an
icon -- we're hopefully getting one soon.

Thanks to Robert Ancell, Matthias Clasen, Colin Walters, Michael Biebl,
Jeremy Bicha, David Ronis, Pino Toscano, Ionut Biru, Antoine Jacoutot
and Sébastien Bacher.

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: dconf 0.8.0 and 0.9.0

[Ryan Lortie]

hi Robert,

On Wed, 2011-07-27 at 11:19 +0200, Robert Schwebel wrote:
> Subject: [PATCH] dconf: increase minimum glib version

Thanks for the fix.  I've applied it to both the master and dconf-0-8
branches.

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

GLib 2.29.16

[Ryan Lortie]

GLib 2.29.16 has been released:

   http://download.gnome.org/sources/glib/2.29/

   066540465360c37f9d2e9784fa4e1c96b6705ed2028d3b90dc89ea2bf43dee72  
glib-2.29.16.tar.xz

Overview of changes from GLib 2.29.14 to 2.29.16


* GTlsDatabase: an abstract class that provides support
  or certificate and key lookup. An implementation will
  be provided in glib-networking

* GHmac: Support or HMAC digests

* Misc new API:
 - g_ptr_array_add_full: creates a GPtrArray with
   a preallocated size and a destroy function
 - g_desktop_app_info_get_show_in: checks if a GDesktopAppInfo
   should be shown in a given desktop environment
 - g_mkdtemp, g_mkdtemp_full, g_dir_make_tmp: create
   temporary directories

* Unify thread wakeup implementations of GMainContext
  and GCancellable, and use eventfd for it when available

* Show mounts in $XDG_USER_DIR in addition to /media and $HOME

* Bugs fixed:
 636572 GTlsCertificateDB
 644601 Some tests need a running dbus session
 652284 deal with small key lengths
 652827 glib-2.29.8 no longer builds with mingw.org's toolchain
 653063 PEM parser fails parsing private key when put first
 654078 Fail to static linking with Glib library
 654450 New functions: g_ptr_array_new_full()
 654793 Add G_VALUE_INIT
 655044 GDesktopAppInfo: Add g_desktop_app_info_get_show_in()
 655148 gdbusconnection is broken when compiling with mingw
 655241 glocalfile.c no longer compiles with MinGW GCC
 655598 g_cancellable_get_fd: silently return -1 for NULL cancellable
 655664 gdbus should not abort if no dbus session is available
 655769 Use ZLIB_CFLAGS when compiling gio
 656031 Improve GVariant annotations
 656048 glib-codegen requires Python >= 2.5
 656151 configure test logic inverted, doesn't match comments
 656152 GCC only syntax used, yet other compilers allowed by configure.
 656162 allow use of lcov 1.9 for coverage
 656282 GDBusProxy: uninitialized local variables can be freed
 656283 Failing tls connection cause assertion
 118563 Add g_mkdtemp in the spirit of g_mkstemp
 636405 Add g_return_if_fail() to g_settings_bind_with_mapping()
 656039 race condition between GDBusProxy signals and public API
 656492 g_io_channel_new_file failure (open(2) behavior wrt POSIX)

* Translation updates:
 Bulgarian
 Esperanto
 French
 Galician
 German
 Hebrew
 Indonesian
 Italian
 Norwegian bokmål
 Russian
 Spanish
 Swedish


Thanks for this release go to:
 Antoine Jacoutot
 Behdad Esfahbod
 Chun-wei Fan
 Colin Walters
 Cosimo Cecchi
 Dan Winship
 David Zeuthen
 Dieter Verfaillie
 Marc-André Lureau
 Martin Pitt
 Matthias Clasen
 Murray Cumming
 Nicolas Dufresne
 Owen Taylor
 Pavel Holejsovsky
 Simon McVittie
 Sjoerd Simons
 Stef Walter
 Tomas Bzatek
 Vincent Untz
 Xavier Claessens


Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

GLib plans for next cycle

[Ryan Lortie]

I'm working on some plans for things I want to do in GLib at the start
of the next cycle.  I'd do them now, but it's getting late.

I've tried some aborted attempts at a few of these things in the past,
but they were all made complicated and ugly by one big factor: we don't
have always-on support for creating threads in libglib.

So here's my list -- both as a solicitation of feedback and as a way to
make sure I don't forget it.

 - merge libgthread into libglib

   The amount of code in libgthread is quite small and almost everything
   on earth is linking against it anyway.  Not having threading support
   built into libglib is preventing us from doing some nice things that
   we could do otherwise.

 - consider removing support for user-specified thread implementations

 - merge libgmodule into libglib

   This isn't really important, but why not?

 - glib_get_worker_context()

   Add a new function for use within glib (and gobject, gio):

  GMainContext * glib_get_worker_context (void);

   This function would create a thread (which we can do if libgthread is
   in libglib) and setup a GMainLoop running in it, returning the
   context.  Future calls would return the same context.  This gives us
   somewhere to take care of things "in the background" and gives us the
   benefit of always having a mainloop running (so we no longer have to
   go out of our way to support the non-mainloop use case of GLib).

 - remove the racy non-threaded case of GMainContext

   We currently have a long-standing race condition in GMainContext that
   occurs when dealing with signals in the single-threaded case only. 
   This is what used to make gtester randomly hang sometimes (before a
   workaround was added to gtester).  Since we have libgthread
   always-on, we can solve that problem once and for all, in addition to
   ripping out a bunch of rarely-used code.

 - make GMainContext use the GLib worker context

   GMainContext currently uses its own internal worker thread to deal
   with signals in the threaded case (which is why they're reliable). 
   It could share the worker thread.

 - make GDBus use the GLib worker context

   GDBus uses a worker thread.  It could also share.

 - make GSettings use the GLib worker context

   Here's the 3rd separate worker thread in typical GNOME programs. 
   Merge it as well.

 - make GTimeZone use the worker context

   This would allow us to detect changes in /etc/localtime via inotify
   instead of polling it each time we create a new GDateTime.

 - land some very minor (and 100% compatible) changes to the GSource API

   see https://bugzilla.gnome.org/show_bug.cgi?id=657729

 - with the updated GSource API we can start looking at epoll in a
   meaningful way


Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLib plans for next cycle

[Ryan Lortie]

On Wed, 2011-08-31 at 12:52 -0400, Dan Winship wrote:
> On 08/31/2011 11:50 AM, Ryan Lortie wrote:
> >  - merge libgthread into libglib
> 
> Getting rid of libgthread or moving any of its symbols into libglib is
> an ABI break on some platforms.
> 
> Of course, since there are only 2 exported symbols (g_thread_init and
> g_thread_init_with_errorcheck_mutexes), I guess you can just move
> everything else in libgthread into libglib, and keep libgthread with
> those methods as no-ops.

My exact plan is to leave the library installed with the two functions
calling equivalent functions in libglib (or doing nothing at all if we
decide to scrap user-provided thread implementations as well).

Next step is to modify the libgthread.pc file so that newly-compiled
programs don't even bother linking the library anymore.

We could also use the symlinking trick -- make libgthread a symlink to
libglib, thus maintaining compatibility.  There was a lot of talk about
how this is a valid technique when we were considering the
libgobject/libgio merges.

> >  - merge libgmodule into libglib
> >
> >This isn't really important, but why not?
> 
> Well, the same ABI issues again. If you don't have a use case it might
> be better to not bother. (Or, you could rename it in glib. Or have it as
> a private API in glib, with libgmodule just having public API wrapping it.)

Since I don't have a compelling case for it, it might indeed be best to
just leave well enough alone.

> >  - glib_get_worker_context()
> 
> s/glib/g/ ? glib_* sounds like it's for glib-internal-only use, which I
> don't see any reason for. It's definitely useful outside of glib.

My original intention is that it *would* be glib-private (like
glib_gettext() for example).  It's true that other libraries could find
it useful, though -- dconf would certainly put itself on this list.  I'm
just slightly worried about this thread becoming contaminated (think:
mainloop blocking) through use by poorly written libraries.

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLib plans for next cycle

[Ryan Lortie]

On Wed, 2011-08-31 at 19:58 +0200, Jannis Pohlmann wrote:
> TBH, I don't think the name alone will prevent misuse; in particular
> so as the "glib" prefix is no obvious internal-only hint (e.g.
> glib_check_version() is not private either).
> 
> Wouldn't a note in the API docs suffice?

We have a few functions like glib_gettext() that are glib internal API
(enforced by not being defined in an installed header).

I envision this falling into the same category.

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLib plans for next cycle

[Ryan Lortie]

An update.

On Wed, 2011-08-31 at 11:50 -0400, Ryan Lortie wrote:
> I'm working on some plans for things I want to do in GLib at the start
> of the next cycle.  I'd do them now, but it's getting late.

I created a wip/glib-next branch and started working on a lot of these
ideas.

I started by merging a couple of awesome patches from Dan that consisted
of making thread support mandatory and deleting a whole tonne of totally
pointless threads-not-initialised code from gio.

Here's the status of items from my list:

>  - merge libgthread into libglib

Seemed like a popular idea, so done.

> - consider removing support for user-specified thread implementations

I did this, but I possibly regret it.  See below for more discussion.

>  - merge libgmodule into libglib

Not done due to push-back and general pointlessness.

>  - glib_get_worker_context()

Done.

>  - remove the racy non-threaded case of GMainContext

Done.

>  - make GMainContext use the GLib worker context

Done, and I think it's okay, but it may contain a race.  It's difficult
to test, though because of a glibc bug that I think I've run into.

>  - make GDBus use the GLib worker context
>  - make GSettings use the GLib worker context
>  - make GTimeZone use the worker context

Pending.

>  - land some very minor (and 100% compatible) changes to the GSource API
> 
>see https://bugzilla.gnome.org/show_bug.cgi?id=657729

The proposed API changes are on the branch.  I've ported the timeout
source (which was a net reduction in code).

>  - with the updated GSource API we can start looking at epoll in a
>meaningful way

Big work to be done here.  This will take a while. :)

=

On the topic of removing support for custom thread implementations: this
simplifies things a fair bit, and would let us get rid of a lot of ugly
code in gthread.h.

In some cases it could theoretically be a performance regression to do
this, though.  Here's why:

The POSIX implementation of GMutex uses the native pthreads mutex quite
directly -- so much so that it uses the pthread functions directly as
the entries for the thread implementation vtable.  That vtable is
exposed as a public global variable and macros in gthread.h do this:

#define g_mutex_lock(mutex) \
  if (g_thread_supported ())\
vtable.lock (mutex);\
  else  \
(do nothing);

Because the vtable.lock function is a direct pointer to the pthreads
locking function, this has the potential to be faster than calling a
real (normal) g_mutex_lock() function that then calls pthreads.

It could be that 2 normal function calls are actually faster than
looking up the address of the vtable and doing a computed jump on a
pointer contained therein -- I haven't checked yet, but I doubt the
difference is substantial either way.

The if (g_thread_supported()) thing is a performance killer, but I think
it's not problematic for a couple of reasons.  It basically comes down
to the fact that this will hopefully be (statically) TRUE in the future,
and in some cases already is.

There are a couple of approaches we could take here (keeping in mind
that the global variable will always have to be exposed for purposes of
ABI stability, even if we change the API):

 - keep things how they are now.  This has the side effect of still
   allowing the thread implementation to be replaced (which is
   questionably useful, of course).

 - remove the hackery and use normal functions, accepting the (extremely
   small) potential performance hit

 - use defines that call the pthread functions directly when we're on
   POSIX, just like we do for the atomic ops.  This forever binds us
   to never doing anything more interesting, since we will have binaries
   out there with pthread calls directly embedded.


One thing worth noting is that there is at least one custom thread
implementation in existence: the errorchecking mutex implementation.  It
could be nice to keep that around.


Another question about threads is if we should still require
g_thread_init() to be called.  There is currently a lot of setup code
that needs to be run and I'm not sure if it's possible to get rid of it
all.  Right now, how it works on the branch is that something that needs
the thread system to be initialised will call g_thread_init_glib()
directly, which will do the work.

It might be nice to get rid of the init call entirely and just have
threads that are always working, right from the start.  That would
certainly be necessary in order to drop the g_thread_supported()
conditional.  That would require a bit more work.

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLib plans for next cycle

[Ryan Lortie]

hi Colin,

On Thu, 2011-09-01 at 16:13 -0400, Colin Walters wrote:
> There's a huge amount of stuff here - how much of this is really
> dependent?  Feature branches are just way easier to review than one
> big "stuff".

All of it except the source API changes is dependent on the libgthread
merge.

My intention here is to mass-land this stuff after we branch the stable
GLib and use this to start the next cycle, thus the name glib-next.  I
do expect there will be significant rebasing as things are reviewed.

> > The proposed API changes are on the branch.  I've ported the timeout
> > source (which was a net reduction in code).
> 
> In particular I'd *really* like to see this as a separate branch.

This was a separate branch, actually, but I just nuked it to reduce the
noise of all the branches I've been pushing.  I'll split it back out and
push it again.

> >
> >>  - with the updated GSource API we can start looking at epoll in a
> >>meaningful way
> >
> > Big work to be done here.  This will take a while. :)
> 
> Right...defer this?

I consider GLib to be fully baked for this cycle -- strictly bugfixes
only at this point.

Everything in this email and on the branch is for the start of next
cycle.

> >  - use defines that call the pthread functions directly when we're on
> >   POSIX, just like we do for the atomic ops.  This forever binds us
> >   to never doing anything more interesting, since we will have binaries
> >   out there with pthread calls directly embedded.
> 
> Binaries - for a specific platform, yes.  Since we know Linux/glibc
> works - and these are in fact FOSS projects that we can contribute to,
> I don't see a problem just emitting pthread calls.

It might become a problem later if we decide that we want to run a
program with debugging mutexes or something.  Consider the case,
particularly, where we do things like passing a GCond* or GMutex* across
a library barrier -- if one library was compiled hard against pthreads
and the other is using some other library (like debugging mutexes) then
we're in a substantial amount of trouble.

We'd essentially be committing to "we will always use pthreads mutexes
as GMutex* and never anything else".

Your point that glibc is a free software project is a good one though --
why not just add the debug support there?

> I think glib should move more towards having separate "normal" and
> "full on super slow debug stuff" modes, similar to how the lockdep
> stuff is a config option for Linux.

I actually think the opposite.  I'd prefer if we could enable super-slow
debug mode with an environment variable.  It would make it way easier to
get debugging information out of users who are experiencing a problem
and don't want to rebuild their system glib or their application.

That's a story for another day...

> > Another question about threads is if we should still require
> > g_thread_init() to be called.

> If you're doing it in g_main_context_default(), that seems almost
> equivalent to not requiring it =)

Almost being the key word, of course.  If people expect that the
threading system is always implicitly initialised and then some day come
across the weird case where it isn't, they'll be quite confused/annoyed.

Ideally I'd like to solve this problem by always having the thread
system ready for use without explicit initialisation.  At the end of the
day, all initialisation that we do can be done by a GOnce at the first
time that we go to use the thing that needs to be initialised.  Even on
Windows, where we may not necessarily be able to have static mutexes
without initialisation, we can one-time bootstrap ourselves using a
spinlock based on atomic integer operations provided by the native
Windows interlocked API -- and I doubt it would even come to that.

Another option is to use library load constructors to run the
initialisation we need to do.  That's certainly possible on Windows
systems and anything using GCC.  I'm not sure if it's possible to do it
in a portable way from pure C, though.

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLib plans for next cycle

[Ryan Lortie]

On Tue, 2011-09-06 at 10:14 -0400, Behdad Esfahbod wrote:
> In HarfBuzz I'm using the C++ compiler without linking to libstdc++.  I found
> it as very rewarding experience.  You get library constructor/destructors for
> free there.  I think this approach to library design has serious merit worth
> considering.

Ha!

I was just writing an email along the lines of "why don't we just
compile a tiny bit of C++ code"? before thinking "oh... but then we'd
have to link libstdc++" and closing the compose window.

Good to hear :)

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

GLib 2.29.90

[Ryan Lortie]

GLib 2.29.90 is ready.

http://download.gnome.org/sources/glib/2.29/

95af3f46a40ad1a3ecfe75db59b27956b256c4ad02f000be2aa13c7abd32fba3  
glib-2.29.90.tar.xz

I consider this to be (almost) a release candidate.

There is probably a bug in GSettings that is causing lots of problems
with gnome-settings-daemon that will need to be fixed before the next
cycle.  Other than that, we're more or less frozen -- it should mostly
be docs and translations in the next release.

There are two API breaks in this release with respect to the previous.
One is a rename and the other is simple removal of a function that was
only added in the last micro release.  See below.

Overview of changes from GLib 2.29.18 to 2.29.90


* API/ABI changes:
 - unix signal watches now match the API of all of the other sources
 - revert the addition of g_date_time_source_new () from last release

* networking and other fixes for Solaris
 - we no longer support symbolic port names (ie: from /etc/services)
 - check if -lsocket is needed
 - fix g_socket_details_from_fd()
 - avoid getmntinfo
 - fix some harmless warnings

* GDateTime improvements:
 - generally improved standards compliance (with C99)
 - support C99-specified format strings: %g, %G, %V, %c, %C, %w
 - consult the locale for the preferred 12-hour time format (%r)
 - drop support for non-standard %N and broken %W
 - better support for formatting non-POSIX (eg: Arabic) numerals
 - locale-related test case fixups, and fix some leaks

* GTlsInteraction: add interaction method invocation guarantees

* gdbus-codegen: post-process all interfaces when parsing >1 file

* make GMainLoop, GMainContext and GSource boxed types

* fix a race condition in the first use of g_get_monotonic_time()

* lots gtk-doc cleanups

* better intltool compatibility when generating pot file

* avoid GCC-specific compiler options when not using GCC

* Translation updates:
 Belarusian
 Brazilian Portuguese
 Canadian English
 Galician
 Indonesian
 Korean
 Lithuanian
 Norwegian bokmål
 Portuguese
 Spanish
 Swedish


Thanks to everyone who helped:
 Alexandre Franke
 Andika Triwidada
 Aurimas Černius
 Changwoo Ryu
 Chun-wei Fan
 Dan Winship
 Daniel Nylander
 Duarte Loreto
 Fran Dieguez
 Ihar Hrachyshka
 Javier Jardón
 Jorge González
 Kjartan Maraas
 Matthias Clasen
 Og B. Maciel
 Patrick Welche
 Pavel Holejsovsky
 Stef Walter
 Tomas Bzatek
 Will Thompson

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

GLib 2.30 branch

[Ryan Lortie]

hi,

GLib has branched for the stable release ('glib-2-30').  All translation
effort should be focused there (since this is what will appear in GNOME
3.2).

The branch is to be considered frozen for code changes, except by
approval.

Thanks

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

no Gtk hackfest for now

[Ryan Lortie]

hi all,

I just sent an email to foundation-announce about Boston Summit being in
Montréal.  We're not going to attach a Gtk hackfest to that since the
notice is short and we already know that some important participants can
not attend.

The plan for now seems to be to have one early next year.

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

GLib 2.29.92

[Ryan Lortie]

hi all,

GLib 2.29.92 has been released.  This release is intended to be included
as part of GNOME 3.1.92.

http://download.gnome.org/sources/glib/2.29/

1f68d7990d03a52cf81284f039de94b041c3f5eb3d53663166b31e477557e8b1  
glib-2.29.92.tar.xz

2.30.0 will be released on or slightly before September 26th.

Overview of changes from GLib 2.29.90 to 2.29.92


This release contains only bugfixes, docs changes and translations
updates.  Translation will continue, but otherwise this should be
considered a release candidate for 2.30.0.

* GDBus bug fixes
 - fix segfault when remote property is invalidated (#659070)
 - take more care in connection teardown to avoid use-after-free
(#651268)

* GMappedFile: return an error when trying to map a device (#659212)

* GSettings: always deliver signals to the correct thread (#657255)

* some small documentation changes

* Translation updates:
 Belarusian
 Brazilian Portuguese
 British English
 French
 Hindi
 Hungarian
 Italian
 Japanese
 Latvian
 Norwegian bokmål
 Persian
 Polish
 Punjabi
 Russian
 Simplified Chinese
 Spanish
 Swedish
 Tamil

Thank you to the contributors to this release:
 A S Alam
 Alexandre Franke
 Antonio Fernandes C. Neto
 Arash Mousavi
 Aron Xu
 Bruce Cowan
 Daniel Mustieles
 Daniel Nylander
 David Zeuthen
 Gabor Kelemen
 I Felix
 Ihar Hrachyshka
 Jiro Matsuzawa
 Jorge González
 Josselin Mouette
 Kjartan Maraas
 Luca Ferretti
 Matthias Clasen 
 Piotr Drąg 
 Rajesh Ranjan
 Rudolfs Mazurs
 Simon McVittie
 Tomas Bzatek
 Yuri Myasoedov

Cheers


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

glib-2-30 hard code frozen

[Ryan Lortie]

hi everyone,

I've been trying to follow the GNOME 3.1 release cycle fairly closely
with GLib 2.29.  For that reason, I now consider the glib-2-30 branch to
be hard code frozen.  Please do not commit anything without first asking
for an exception.

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

GLib "next cycle" update

[Ryan Lortie]

hi everyone,

I've torn through a great deal of what I wrote about in "GLib plans for
next cycle" email.  Changes are on master.

I'm presently working on the "wip/mutexes" branch.  There are two
somewhat-related efforts on this branch:

First, I'm trying to slay bug #70598 by deprecating GStaticMutex and
creating a GMutex that you can do:

  GMutex mutex = G_MUTEX_INIT;

and the same for GCond while we're at it and GPrivate to a somewhat more
limited extent (for GLib internal use only, at present).

The benefit here is that we can have mutexes and condition variables
without any memory allocation at all, which is good for avoiding
initialisation dependency cycles inside libglib (where gmem depends on a
GMutex, but GMutexes are allocated with gmem, for example).

The most controversial patch here so far is this one:
http://git.gnome.org/browse/glib/commit/?h=wip/mutexes&id=aa55cd75ba2ff6ffaec6c247d34fdc663a2f3c56

which could be seen as causing an ABI Break for glib-using libraries
that export locks defined as a G_DEFINE_LOCK as part of their public
ABI.  That's unlikely.

It's also an API (but not ABI) break if you were trying to use the
undocumented G_LOCK_NAME macro (as GCancellable is doing, and thus
needed to be fixed).  This could be considered a bug in the application
and is easy to fix.


Second, I'm trying to nuke the few remaining reasons that
g_thread_init() is required at all.  The static GMutex/GCond/GPrivate
code is making this a bit easier, but there are some performance
considerations.

In particular, in the 'likely' case, gslice goes to substantial pains to
avoid any cross-thread synchronisation.  This is incompatible with
implicit initialisation in threaded contexts.  There are approximately
three ways that I can think of to address this:

 - suck it up and do a proper thread-safe implicit initialisation

   This is probably no performance decrease on Intel (where we have
   somewhat strict ordering guarantees and can probably avoid a fence). 
   It will definitely require fences on some platforms, however.

 - initialise on the first g_thread_create() call

   This seems like it would avoid any chance of races in gslice
   initialisation but it means that we wouldn't be safe with respect to
   threads that weren't created by GLib (like some asynchronous
   libraries do for callbacks).

 - use a __attribute__((constructor)) approach

   I have a patch here to introduce this concept as a quick hack:

 
http://git.gnome.org/browse/glib/commit/?h=wip/mutexes&id=9f29daafeb8133611a4ea24f5013ebb8bb623d73

   and two uses of it:

 
http://git.gnome.org/browse/glib/commit/?h=wip/mutexes&id=7dd937f96b19f41d4eda4890dbbb57c6451cf4b6
 
http://git.gnome.org/browse/glib/commit/?h=wip/mutexes&id=233e66c195ae828f75ecff3738124041d7b1e586

   For the record, I think that this is a somewhat inelegant solution.
   Maybe it's our best choice, though, given the constraints.  I know
   some others want to make use of this, and maybe we could even
   consider making the API public (and cleaning it up).

   I have doubts that we can ever support this everywhere in a portable
   way but we can probably get pretty reasonable coverage.  Matthias
   also raised some concern about the undefined order in which the
   constructors could be called (which means that we might have to
   refrain from calling gslice from other constructors, for example,
   since gslice may not have been initialised yet).

   A couple of solutions to that:

 - use the (priority) field of GCC

 - use internal rigging to ensure dependent inits are called first
   or just use one big initialisation function that does it in the
   right order

 - make the ENSURE macro do a thread-unsafe initialisation check
   even in the case that we support constructors so that we catch
   these sorts of problems.  This would be safe* because the ctors
   are always running at a time when we can be guaranteed the code
   is only being accessed by a single thread.

Cheers



* I can, in theory, imagine some truly absurd scenarios where this may
not be true.  They involve a CPU speculating reads from a library for
which dlopen() has yet to return a handle on another CPU.  I'm am not
overly concerned.

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

dconf 0.9.1

[Ryan Lortie]

hi

dconf 0.9.1 was just released.

I doubt there will be any changes before I release 0.10.0 in time for
the GNOME 3.2 release, but please test this release in case changes do
need to be made.

Download


http://download.gnome.org/sources/dconf/0.9/dconf-0.9.1.tar.xz  (169K)
  sha256sum: fd2ea1ed3b7933cf3d6841f8fc8794a0351c30ef5d7b8eb0b56cc3171e9e354e

Changes in dconf 0.9.1
==

  - give a g_warning() on failure to communicate with service

  - remove unworking 'set lock' call from dconf API and commandline tool

  - add code to exit gracefully on receipt of SIGINT, SIGHUP, SIGTERM

  - remove "service function" logic; always use the XDG runtime directory


Thanks for the help from Marc-Antoine Perennou and Robert Schwebel.

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

dconf 0.10.0

[Ryan Lortie]

hi,

dconf 0.10.0 was released with no changes at all.  It should be packaged
only as a matter of completeness.

  http://download.gnome.org/sources/dconf/0.10/

  9f744ccfb3da20163a4bb27916c960f6bf56048b3ec1112862c85414fc064ee2  
dconf-0.10.0.tar.xz


Cheers


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

GLib 2.30.0

[Ryan Lortie]

hello everyone.

GLib 2.30.0 has been released.

  http://download.gnome.org/sources/glib/2.30/

  d64c00b43409eabb89aad78501fcb1a992b002b314a4414a9bd069585cb7cdc1 
glib-2.30.0.tar.xz

This major release of GLib represents 1174 commits from 151 individual
authors, including 35 contributors with 5 or more commits.  Over a dozen
companies have made a substantial contribution to this release.
Countless others have contributed testing, bug reports, packaging,
online support and other valuable work throughout the cycle.

In addition to hundreds of bug fixes and enhancements made this cycle,
the following major features were added:

 - GDBus has been improved by the addition of a high-level object
   manager and code generation facilities that make use of it.  See
   http://davidz25.blogspot.com/2011/09/new-d-bus-features-in-glib-230.html
   for more information.

 - GLib has added an extensible TLS database where certificates and keys
   can be found and used, laying the foundation for integration with
   smart cards and other key stores.  GLib now also supports HMAC
   hashes (which are used when implementing web technologies like OAuth).

 - The atomic operations have been expanded to include bit operations
   (and, or, xor) and so that all operations are supported on
   pointer-sized operands.  The implementation has been made more
   correct and performant by way of GCC intrinsics and better use of the
   Interlocked API on Windows.  Bitlocks now work on pointer-sized
   operands.

 - New API has been added to allow UNIX signals to be dispatched via the
   mainloop.  Additionally, there is a new UNIX-specific API to allow
   race-free creation of close-on-exec pipes with a fallback on
   platforms where this is not possible.

 - GMainContext and GCancellable now use eventfd when available, instead
   of less efficient pipe pairs.

 - GApplication now supports non-single-instance applications.

We had one small API break to an interface that wasn't used except from
inside GLib itself: the name of the 'set_state' virtual function call on
the interface of GAction changed to 'change_state' in order to avoid
conflicts with the 'set_state' method on GSimpleAction.  To avoid
compatibility problems, those who will implement GAction going forward
are suggested to assume that this feature appeared for the first time in
this release of GLib.

This release of GLib has had a fantastic amount of work put in by
translators.  Despite being one of the most difficult modules to
translate, we have 100% coverage of 32 languages, including: Assamese,
Basque, Brazilian Portuguese, British English, Bulgarian, Canadian
English, Catalan (Valencian), Catalan, Chinese (China), Czech, Danish,
French, Galician, German, Hungarian, Indonesian, Italian, Korean,
Latvian, Lithuanian, Norwegian Bokmål, Polish, Portuguese, Punjabi,
Russian, Serbian, Serbian Latin, Slovenian, Spanish and Swedish.
Special mention goes to the translations of Tamil and Esperanto which
were both at approximately 50% last cycle and made it to 100% this
cycle.  12 other languages (Chinese (Hong Kong), Chinese (Taiwan),
Belarusian, Hebrew, Uighur, Finnish, Greek, Romanian, Vietnamese,
Armenian, Japanese, Gujarati) are above the 80% level.

Finally, Chun-wei Fan has invested a substantial effort to ensure that
it is once again possible to build GLib using Visual Studio on Windows.

Release announcements (and more detailed change summaries) for the
individual unstable point releases made during this cycle can be found
here:

  2.29.92: 
https://mail.gnome.org/archives/gtk-devel-list/2011-September/msg00153.html
  2.29.90: 
https://mail.gnome.org/archives/gtk-devel-list/2011-September/msg00018.html
  2.29.16: 
https://mail.gnome.org/archives/gtk-devel-list/2011-August/msg00034.html
  2.29.14: 
https://mail.gnome.org/archives/gtk-devel-list/2011-July/msg00038.html
  2.29.12: 
https://mail.gnome.org/archives/gtk-devel-list/2011-July/msg00034.html
  2.29.10: 
https://mail.gnome.org/archives/gtk-devel-list/2011-July/msg3.html
  2.29.8: https://mail.gnome.org/archives/gtk-devel-list/2011-June/msg00041.html
  2.29.6: https://mail.gnome.org/archives/gtk-devel-list/2011-June/msg00011.html
  2.29.4: https://mail.gnome.org/archives/gtk-devel-list/2011-May/msg00012.html
  2.29.2: 
https://mail.gnome.org/archives/gtk-devel-list/2011-April/msg00071.html

I won't try to list everyone who contributed to this release.  You know
who you are; a huge thank you to you all.


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: circular dependency between glib and pkg-config

[Ryan Lortie]

hi Stuart,

On Sun, 2011-09-25 at 13:45 -0600, Stuart Ambler wrote:
> Apparently pkg-config used to contain within it an old version of
> glib, used mostly for strings, lists, hash tables, and a few other
> things, that the new version has removed and instead made itself
> depend on glib.  glib documentation, on the other hand, says that 
> glib is dependent on pkg-config.

See the pkg-config README about this:

  http://cgit.freedesktop.org/pkg-config/tree/README#n33

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: _wstat on Windows (actually stat stuff in general)

[Ryan Lortie]

On Tue, 2011-09-27 at 11:36 +0200, Kean Johnston wrote:
> On 9/27/2011 9:08 AM, Steve Frécinaux wrote:
> > Won't you break ABI if you're changing the layout of the struct on
> > linux/unixes? As I understand this is not an issue on Windows since
> > everyone ships the libraries with the binary, but it is on Linux.

I was just about to write a reply mentioning this -- glad someone else
brought it up. :)

I disagree that we don't have an ABI to maintain on Windows.  I think
people on Windows are somewhat likely to download precompiled binary
versions of our DLLs for use with developing their software (since the
build process is so complicated).  We can easily introduce extremely
difficult-to-debug situations for people who assumed that the DLL was
binary-compatible with the old one.

> Nope. On linux there IS no ABI to break - everything is #define'd to its 
> libc name - so there is no real g_stat(). Any existing code out there will 
> just be calling stat(). If we make this change however we will be 
> introducing an ABI that will need to be maintained which is why its 
> important everyone agrees the data types are wide enough.

While I mostly agree with this, it's only true in the case that both the
code calling g_stat() and the code inspecting its result are always in
the same codebase.

If there is any API that takes a 'GStatBuf *' then that ABI will change
as a result of recompiling against the new GLib (ie: recompiling a
library with no code changes will change the ABI of the library).  I'm
not sure there are any cases of this, but it's something to be aware of.

A more practical concern, however, is the fact that GStatBuf was only
introduced somewhat recently:  

  
http://git.gnome.org/browse/glib/commit/?id=1229281d95802c4c190284c7d331f67194a2553e

This means that there is an awful lot of valid existing code (including
within GLib itself) that looks like this:

{
  struct stat buf;

  g_stat (filename, &buf);
}

which (if I understand your proposal correctly) would be badly broken.

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Please consider for inclusion in glib 2.30

[Ryan Lortie]

hi Kean,

On Mon, 2011-09-26 at 06:57 +0200, Kean Johnston wrote:
> https://bugzilla.gnome.org/show_bug.cgi?id=660095
> 
> Its small, it doesn't affect anything except Windows and it fixes an actual 
> build problem if your environment does have dirent.h. Thank you.

We were hard code frozen at the time you sent this mail and only hours
before the final release was rolled.

We'll take a look at it for the .1 release.

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: _wstat on Windows (actually stat stuff in general)

[Ryan Lortie]

On Wed, 2011-09-28 at 11:03 +0200, Kean Johnston wrote:
> So easily solved. Call the damned thing g_statfile() and have the structure 
> be GFileStat.

So then we would have 'struct stat' and 'GStatBuf' which would work with
g_stat(), g_lstat() and fstat().  Additionally we would add a
'GFileStat' that only works with new calls 'g_statfile()',
'g_lstatfile()' and (presumably) 'g_fstatfile()' (for fstat()
functionality applied to the new structure type).

My head is spinning...

> Only if you define "UNIX" as "Linux". OSX has other fields Linux doesn't. 
> Some UNIX variants have 16-bit uid_t's others have 32. Some have as low as 
> 16-bit ino_t's others have 64. There are all KINDS of ways in which it 
> differs. Offering a portable, no-ifdefs-required, 
> suitably-large-sized-to-accomodate-everyone structure ... yes *STRUCTURE* 
> that all code can use completely portably without having to worry about 
> anything ... SURELY you can see the value in that? GFileInfo from GIO? You 
> have GOT to be kidding me? As a replacement for stat()? When I want to look 
> up a file attribute I have to go through hash table lookups for attributes 
> and a completely open-ended size (GArray *attributes) and all that parent 
> class and instance overhead - versus having a single structure I can 
> sizeof() and write to a file? In what universe is that a better approach?

I don't find the ability to write 'struct stat' to a file to be a
particularly compelling usecase...

You propose to avoid indirection by moving people away from GFileInfo to
GFileStat.  At the same time, you'd be adding more indirection to the
g_stat() users though -- a copy of all of the various fields of the
system native structure to our shadow structure.

Unless you actually propose that we keep both APIs around and
undeprecated -- and my head is spinning again

I don't really appreciate the problems that are caused by different
sized inode, uid, etc. fields...  It might be unsightly or aesthetically
displeasing on some level, but the something like:

  if (buf.st_uid == getuid()) ...

will obviously always work properly.  I think, if anything, we cause
ourselves more trouble by breaking with the system definition.

The only benefit to your proposal (from a UNIX standpoint, at least) is
that it helps avoid accidental portability problems where a non-portable
field is used.  I'm not sure that it's worth all the drawbacks.

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Glib Atomic Operations

[Ryan Lortie]

On Fri, 2011-10-07 at 09:24 -0400, Morten Welinder wrote:
> > what is the purpose of  '(void) (0 ? *(atomic) ^ *(atomic) : 0)'?
> 
> Poor man's type check.  That expression isn't valid for every
> possible "atomic".

Specifically, it ensures that the destination of the pointer is an
integral type.  You can't perform ^ (xor) on a pointer, struct, double,
etc.

Notice that this check is omitted for the _pointer_ variant -- which is
(of course) expected to work on pointers.

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Function completion for GVariant maybe types?

[Ryan Lortie]

hi Markus,

On Tue, 2011-10-11 at 12:12 +0200, Markus Elfring wrote:
> > If you have a GVariant* variable, you should usually know what type it is 
> > already,
> > but if not, g_variant_get_type() will tell you.
> 
> Is a direct use of a function like "g_variant_type_is_maybe" recommended?

Yes.  It's there for exactly this reason.

I considered adding g_variant_is_array, g_variant_is_maybe,
g_variant_is_tuple, g_variant_is_variant, g_variant_is_int32,
g_variant_is_uint32,  but you can see why I wanted to avoid that.

If you want to find out things about the type of a GVariant then of
course the GVariantType API is the correct and appropriate way to go
about it.

> > GVariants are immutable. Once a GVariant instance has been created, you 
> > can't
> > change its value/contents - you can only throw it away and create a new 
> > GVariant.
> 
> Thanks for your clarification.
> 
> I am still interested in an addition to the interface "g_variant_new_maybe".

What addition?

> > You can reset a (GVariant *) variable to point to a variant representing
> > "nothing" the same way you'd make it point to anything else.
> 
> I imagine that this approach can be improved a bit.
> 
> How do you think about an interface like the following?
> 
> GVariant* g_variant_set_to_nothing(GVariant const * gv);

The name is a bit misleading because in our APIs _set_*() tends to mean
that you're modifying an object in some way (which is not what happens
here).

It's also worth noting that the new and the old object have absolutely
nothing in common except for their type -- which suggests that you
should just use the GVariantType interface to get what you want:

g_variant_new_maybe (g_variant_type_element (g_variant_get_type (gv), NULL);

(ie: create a new maybe-typed GVariant with no child value with the
element type equal to the element type of another GVariant 'gv').

> If the passed instance is a maybe type already, its "container" will be 
> removed
> while the contained type will be kept. (I would like to avoid the nesting of a
> maybe type into another one.)

This is complicated.  Your desire to avoid the nesting of maybe types is
understandable, but would introduce some inconsistency if we added it in
the API.  If you want to do that in your own code then it is very easy:

{
  GVariantType *type;
  GVariant *new_val;

  type = g_variant_get_type (gv);

  /* if the type is already a maybe type, strip off
   * the extra layer to avoid nested maybe types.
   */
  if (g_variant_type_is_maybe (type))
type = g_variant_element (type);

  /* create a new 'nothing' value of the correct type */
  new_val = g_variant_new_maybe (type, NULL);
}

Note that you don't need to free 'type' anywhere here due to how
GVariantType works internally to avoid copies.

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Function completion for GVariant maybe types?

[Ryan Lortie]

On Tue, 2011-10-11 at 19:37 +0200, Markus Elfring wrote:
> I stumbled on the detail that the functions "g_variant_is_of_type" and
> "g_variant_is_container" are provided directly while some predicates can only 
> be
> checked by the others.

g_variant_is_of_type (gv, G_VARIANT_TYPE_MAYBE) will do what you expect.

> > The name is a bit misleading because in our APIs _set_*() tends to mean
> > that you're modifying an object in some way (which is not what happens 
> > here).
> 
> Would you prefer a name like "g_variant_create_maybe_from_source" over my
> suggestion "g_variant_set_to_nothing"?   ;-)

I think I'd just prefer not to have such an API :)

> Why should it be easier to implement the special copy operation in my code?
> 
> Do more GLib software developers need the suggested functionality?

I'm not aware of anyone who does.

GVariant is typically used in situations where there are strong
expectations on the types of values in use and not much need for
converting between different types.

In fact, if we were to add any sort of 'additional flexibility' here, it
would be in terms of introducing functions that are more flexible with
respect to the different integer types... That issue has been raised a
couple of times, but even in that case there doesn't seem to be a
burning need.

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GThread struct now hidden

[Ryan Lortie]

hi

On Thu, 2011-10-13 at 13:26 +0200, Murray Cumming wrote:
> By the way, I also noticed that g_thread_init() is deprecated,
> presumably because you must now used g_thread_new(), so you don't need
> it, but I don't see a deprecation comment on g_thread_init().

g_thread_init() is deprecated because you simply do not need to call it.

g_thread_new() is rather a replacement for g_thread_create().

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GThread struct now hidden

[Ryan Lortie]

hi Murray,

On Thu, 2011-10-13 at 12:48 +0200, Murray Cumming wrote:
> This change in glib master does indeed break glibmm:
> http://git.gnome.org/browse/glib/commit/?id=d904612100120d12126f1a6623a106d8a5b02fa6

I had a feeling it might break something or other, and I didn't think
about bindings.  I'll back it out immediately.

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

GLib 2.31.0

[Ryan Lortie]

At long last, GLib 2.31.0 has been released.

  http://download.gnome.org/sources/glib/2.31/

  46fcaec884be7ce1b780feffb0da987b55e23850a870d94ed84356870532fe8c  
glib-2.31.0.tar.xz

Most people reading this announcement know that there have been a huge
number of changes in this release.  There were some breaks involved in
that, but I've been running it on my system (in /usr) for the past few
days now without detecting any issues.

Special thanks to Rico Tzschichholz who has been doing the same and
found two rather serious issues by doing so (both of which have been
fixed).

On to the NEWS...

(ps: the 500 commits are a lie[1])

Overview of changes from GLib 2.29/2.30 to 2.31.0
=

This release contains a huge number of changes (500 commits worth).  The
list below attempts to summarise, but not every change is listed.

* Major changes to threading and synchronisation
 - threading is now always enabled in GLib
 - support for custom thread implementations (including our own internal
   support for errorcheck mutexes) has been removed
 - a whole lot of dead code (to deal with the non-threaded case) has
   been ripped out.  This includes the racy path of GMainContext that
   caused deadlocks with respect to child process exits in
   single-threaded programs (such as gtester).
 - libgthread is now an empty shell and g_thread_init() is no longer
   required (and has been deprecated)
 - GMutex and GCond can now be statically allocated without explicit
   initialisation.  Dynamic allocation for these types is deprecated.
 - new types GRecMutex and GRWLock can also be statically allocated
   without explicit initialisation.
 - GPrivate can now be statically allocated and has an improved API.
   Dynamic allocation of GPrivate is deprecated.
 - GStaticMutex, GStaticRecMutex, GStaticRwLock, GStaticPrivate are
   deprecated.
 - GCond now uses monotonic time internally and a new API takes
   monotonic time for timed waits, deprecating the wallclock API
 - removal of the insane macro indirection used in the previous
   implementation of threading and synchronisation APIs
 - use SRWLock and CONDITION_VARIABLE APIs when available on Windows
   (Vista and later) and emulate them on XP
 - leaks of G(Static)Private-allocated data on some cases of thread exit
   have been fixed
 - simplified new thread creation API with the old API deprecated.  The
   concept of joinability has disappeared (all threads are joinable) as
   have priority levels, 'bound'ness (ie: kernel vs. userspace threads)
   and ability to manipulate the stack size.
 - GThread is now a refcounted type
 - other implementation details changed

* Move headers for some deprecated functionality to a separate
  deprecated/ directory.

* New support for attribute-based deprecations to issue compiler
  warnings instead of breaking the build and/or giving warnings about
  implicit declarations (and possibly miscompiling).

* GCache has been deprecated (after its last use was removed from our
  platform over a year ago).

* It is no longer possible to include individual headers (like
  "ghash.h") -- you must #include .

* The misguided experiment of allowing the program to stumble along with
  missing GSettings schemas is now over -- the abort is back.

* Clarify that fork() is not valid while using GMainContext.  This is
  because the internal resources of the GMainContext end up being shared
  by both processes.  We had an assert here but it was breaking existing
  (valid) use cases as well, so it has been removed for now.

* GApplication
  - add ::shutdown signal as logical dual to ::startup
  - don't use a GMainLoop: iterate the GMainContext directly (improves
quit logic)

* Several portability fixes for Windows, OpenBSD, Solaris

* Add new GValue API to specifically deal in signed chars (in case the
  platform defines 'char' as unsigned)

* some new API to mitigate the problems associated with calling setenv()
  in a multi-threaded program

* Use CLOCK_MONOTONIC unconditionally if the libc has support at compile
  time (ie: stop checking for kernel support at runtime).

* pkg-config files:
  - drop -uninstalled variants
  - remove gobject dependency on gthread

* New macro G_ATOMIC_LOCK_FREE is defined if the atomic operations are
  implemented without use of a mutex.  Cleaned up atomic-related
  compilation issues with mingw compilers on win32 systems.

* SOCKS proxy and resolver improvements

* Fix the spelling of G_IO_FLAG_IS_WRITABLE (was WRITEABLE) and
  introduce a macro for backwards compatibility.

* GDBus:
  - many code generation updates and improvements
  - some race condition fixes, including testcase hangs

* GVariant:
  - new g_variant_new_from_fixed_array() API
  - substantial docs improvements/clarifications

* GKeyFile is now refcounted and boxed

* mount monitoring is now based on /proc/mounts (where available)
  instead of mtab

* new macros G_SOURCE_CONTINUE and G_SOURCE_REMOVE for returning fr

dconf 0.11.0

[Ryan Lortie]

hi all,

dconf 0.11.0 is released.  This is the first unstable release going
toward 0.12.

  http://download.gnome.org/sources/dconf/0.11/
  cfe99f06f517e51e543266f2b27fd50a480565b2b59aa32996d4841887251b93  
dconf-0.11.0.tar.xz

There are some bugfixes:

  - don't install a system service file
  - "dconf update" no longer fails if the locks/ subdir is missing
  - port to the new GLib synchronisation APIs
  - stop using -Werror
  - get rid of maintainer mode
  - drop some dead code and no-longer-needed workarounds

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: experimental gtk+ 3.3.2 win32 build

[Ryan Lortie]

hi Pedro,

On Wed, 2011-10-26 at 16:14 -0300, Pedro Ignacio Guridi wrote:
> Hello everyone,
> I dont know if this list is the right place to post this information,
> my apologies if is not.
> I built Gtk+ 3.3.2, Glib 2.31, etc. under win32 (mingw32), I wanted to
> share the link if somebody is interested or finds it useful.

In general, we are interested in improving the situation with respect to
Windows builds.

We'd like to do this in a more robust way (ie: done with every version
and posted on gtk.org).  Ideally, this would be automated.

It's worth noting that it's already relatively easy for us to do mingw
builds and indeed we have a full set of them in the Fedora archive.
What we really lack is a good method of doing regular builds using
Visual Studio (which is necessary to get the correct debugging symbols
into the libraries).

Do you have any ideas how we could possibly automate this process?

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: A GTK+ hackfest opportunity

[Ryan Lortie]

On Wed, 2011-11-02 at 14:15 -0400, Matthias Clasen wrote:
> E.g. Benjamin might be able to attend both...

This is really the issue.  Having the gtk and a11y developers in the
same place is great -- but totally useless unless Benjamin can focus on
a11y while he's there.

For that reason, plus the reasons of less required synchronisation (and
the fact that Benjamin doesn't seem to mind the extra trip) the a11y
hackfest was separated out.

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

GLib 2.31.2

[Ryan Lortie]

GLib 2.31.2 is out.

This is a point release on the way to what will become GLib 2.32.0.

  http://download.gnome.org/sources/glib/2.31/

  19d7921671a487c3c5759a57df7b8508afdbadd7764d62a47a82fff7b399032b  
glib-2.31.2.tar.xz

Overview of changes from GLib 2.31.0 to 2.31.2
==

* Monotonic time is now properly supported on Windows

* glib-mkenums: fix @ENUMPREFIX@ with /*< underscore_name=... >*/

* EXPERIMENTAL: introduce new GSettingsSchema and GSettingsSchemaSource
  APIs for the convenience of plugin system authors and those who wish
  to introspect the contents of schemas.  This API may change.

* Improve the performance of GObject property notifies.

* GDBus:
 - fix a race when unowning a name immediately after owning it
 - thread safety improvements on GDBusConnection
 - fixes for exit-on-close functionality

* Deprecations:
 - add G_SIGNAL_DEPRECATED
 - don't use G_DISABLE_DEPRECATED masking for functions anymore

* docs
 - tmpl/ is finally dead for glib

* GIO:
 - GInetAddressMask: new type for internet address range matching
 - various GIO file and stream fixes
 - improvements to attribute and fileinfo handling

Thanks to the contributors to this release:

 Aleksander Morgado
 Alexander Larsson
 Alexandre Rostovtsev
 Benjamin Otte
 Christian Persch
 Chun-wei Fan
 Cosimo Cecchi
 Damien Lespinau
 Daniel Mustieles
 Dan Winship
 David Zeuthen
 Fran Diéguez
 Giovanni Campagna
 Jasper St. Pierre
 Javier Jardón
 Jorge González
 Josselin Mouette
 Jürg Billeter
 Kjartan Maraas
 Kristian Rietveld
 Lucas De Marchi
 Marc-André Lureau
 Matej Urbančič
 Matthias Clasen
 Murray Cumming
 Nicolas Dufresne
 Piotr Drąg
 Rico Tzschichholz
 Robert Nagy
 Simon McVittie
 Sjoerd Simons
 Will Thompson
 Yaron Shahrabani

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

dconf 0.11.2

[Ryan Lortie]

dconf 0.11.2 is released:

  http://download.gnome.org/sources/dconf/0.11/

  4625978257cd8c273a4d31ea7a8788326df63267fc0236b6d879e891cd48fad9  
dconf-0.11.2.tar.xz

This is a point release leading up to what will become 0.12.0.

Changes in dconf 0.11.2
===

 - many bugfixes and improvements to the editor, most notably porting to
   GtkGrid to avoid the GtkTable layout bug that was causing size to be
   incorrectly allocated

 - fix a crasher due to invalid string index of -1

Thanks to those who contributed:
 Robert Ancell
 Matthias Clasen

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GObjectClass.dispose and bringing objects back to life

[Ryan Lortie]

On Thu, 2011-12-01 at 19:26 +, Simon McVittie wrote:
> Hi,
> I've been looking into the details of how GObjects are destroyed,
> hoping to solve , in
> which disposing a global singleton GDBusConnection in one thread races with
> reffing and using it in another thread, causing resurrection and a crash if
> both happen. (Advice from GObject gurus on that bug would be very much
> appreciated.)

See https://bugzilla.gnome.org/show_bug.cgi?id=548954 for pretty much
the same issue.

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Function completion for GVariant maybe types?

[Ryan Lortie]

hi Markus,

On Mon, 2011-12-05 at 22:30 +0100, Markus Elfring wrote:
> How do you think about the following update suggestion?

See comments below.

> +GVariant *
> +g_variant_new_nothing_from_type (GVariant const * value)

We don't use 'const' in this way with GVariant (although I considered
doing so).

> +  if (value == NULL)
> + return g_variant_new ("ms", NULL);

Why arbitrarily "ms"?

> +  else
> +{
> +   GVariantType* type = g_variant_get_type (value);
> +
> +  if (g_variant_type_is_maybe (type))
> +{
> +   GVariant* contained = g_variant_get_child_value (value, 0);
This could fail -- the maybe value may not contain a value.

> +   type = g_variant_get_type (contained);
> +   g_variant_unref(contained);

It is far more efficient to just call g_variant_type_element() on the
original type, as Simon suggested.  The following line is also
theoretically invalid since 'type' belongs to the 'contained' GVariant
that you just freed (with the current implementation this happens to be
safe, but no promises that this won't change in the future).

> +   return g_variant_new_maybe (type, NULL);
> +}
> +  else
> +   return g_variant_new_maybe (type, value);
> +}

This function pretty much makes no sense to me:

  - if you pass in NULL, return a Nothing of (arbitrary) type "ms"

  - if you pass in a GVariant with a maybe type:

- if the maybe contains no value, crash

- if the maybe contains a value, return the NULL of the same type

  - if you pass in a GVariant with a non-maybe type, return the same
value as a nullable type

Even correcting the bugs, I can't imagine any situation in which this
function would be useful.  Can you please explain, at a higher level,
what you are trying to accomplish?

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

GMenuModel has landed

[Ryan Lortie]

hi,

Today I landed the GMenuModel work on glib master.  A release will be
following shortly.

There is related work in the 'wip/gmenu' branch of Gtk+ that will
hopefully be landing soon.  There is a trivial example in
gtk+/examples/bloatpad.c that demonstrates some of the ideas here.

The main thing to understand about this work is that we are changing how
menus work in Gtk+.  The days of constructing a GtkMenuBar widget and
packing it into a VBox at the top of your window are gone.

GMenuModel is an interface to describe the content of a menu and GMenu
is its obvious implementation (think GtkTreeView vs. GtkTreeStore).
Your application will construct a series of interlinked GMenu instances
to describe the content of your menus.  Fortunately, there is an XML
parser to do this automatically.  It is integrated with GtkBuilder.

Providing the menu in abstract form instead of GtkWidget form addresses
a few long-standing issues in Gtk.  The most notable one is that we will
finally have proper support for the menubar on the mac.

Menubars are no longer a per-window concept.  They are now set for the
entire application.  This is done for two reasons:

  1) every app already has the same menubar (content) in each window

  2) this is how the mac universe operates

The API to set the menubar for the application is, unsurprisingly:

void  g_application_set_menubar (GApplication *application,
 GMenuModel   *menubar);

A new type of menu has also been introduced: the application menu.  This
is the menu that gnome-shell currently only has a "Quit" item in.  Your
application can now control the contents of this menu by whipping up a
GMenu and setting it:

void  g_application_set_app_menu (GApplication *application,
  GMenuModel   *app_menu);


We may add other types of menus in the future.  A jumplist/dock menu
comes to mind.

GMenuModel is a strictly read-only API.  It describes the structure of a
menu, but has no support for invoking actions when items in the menu are
clicked.  This is handled through the already-existing (but now
improved) GActionGroup API.

When creating a menu item, you specify an action name.  This looks like
"app.preferences" or "win.fullscreen".  The part before the dot is the
location of the action (in this case the hard-coded strings "app" and
"win" refer to app-wide and window-specific actions, respectively).

For example:

  

Clicking this menu item would result in the 'quit' action being invoked
on your GApplication.

There is a new GActionMap interface that GApplication now implements.
It can be used to easily add actions to your GApplication.

Gtk also has a new class called GtkApplicationWindow that implements
GActionMap.  That's where the "win." actions go.  Even though the menu
is globally-specified at the level of the application, the actions are
correctly routed to the appropriate window automatically.

There are two new XSettings properties that have been added to
gnome-settings-daemon that specify if the shell will show the
application menu or the menubar.  These values have hard-wired defaults
on non-X platforms.

shows-app-menu   shows-menubar
  gnome-shell:  yes  no
  GNOME 2:  no   no
  unity:yes  yes
  mac os:   yes  yes

If a particular desktop environment doesn't show a menu then it will be
displayed at the top of each GtkApplicationWindow associated with that
application.  For example, on gnome-shell, the menubar set with
g_application_set_menubar() will be at the top of each window, but on
the mac, it will be at the top of the screen.


We're currently open to making changes to the APIs, so please check them
out and give feedback, but remember that they may change.  If you have
questions about how to use something, please reply here and I'll answer
it for the benefit of all.  I hope to use the contents of this thread as
the basis for writing some introductory material on the topic.

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GMenuModel has landed

[Ryan Lortie]

hi,

On Fri, 2011-12-09 at 01:34 +0100, Andrea Bolognani wrote:
> Does this mean different windows belonging to the same application will
> not be able to have different per–window menubars? I’m thinking about
> Empathy here, with its Buddy List and Conversation windows having
> different menubars, but it’s not an uncommon scenario.

I guess a reasonable question to ask here is what empathy would look
like if it were an application designed for mac os.

If people ask for it, I'm open to adding the ability to override menus
on a per-window basis, but it will be strongly recommended against.

I think a possible way of dealing with this would be to treat the
contact list and the chat windows as two separate applications -- it
almost seems that way these days anyway, with the messaging integrated
into the shell.

> I assume Windows will behave like GNOME 2 here. In the GNOME 2 case, is
> the app menu collapsed with the menubar somehow?

Correct assumption.

In the case that nobody is showing the application menu, an
"Application" item is added to the left of whatever would have otherwise
been the first item in the menubar.  If there is no menubar, then you
end up with a menubar with an "Application" menu and nothing else.

We're trying to decide what the best name for this menu should be.
Possibly it should be the same as the name of the application.


Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GMenuModel has landed

[Ryan Lortie]

hi,

On Thu, 2011-12-08 at 19:24 -0800, John Ralls wrote:
> I think that you misunderstand how mac os works. 
> 
> Yes, a single menu bar is displayed at the top of the screen. This is
> correct behavior according to Fit's Law, because you can bang the
> pointer to the top of the screen and it can't overshoot.
> 
> No, applications are not limited to having a single menu bar. It's a
> one-liner to switch menubars when different window (or notebook tab,
> for that matter) gets focus.

This is obviously true from the fact that an application can detect
which window has focus and the fact that the items in a menu can be
changed, but it has to be done manually and is exceedingly uncommon in
native mac os applications.

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GMenuModel has landed

[Ryan Lortie]

hi,

On Fri, 2011-12-09 at 09:18 +, jcup...@gmail.com wrote:
> I suppose I could have a single menu tree with everything from every
> window type rolled together, but then I'd need a way to grey out
> irrelevant items per-window, which is almost the same thing as
> multiple menus. And I'd think it would be frustrating for the user to
> have to work with a menu system where 2/3rd of the visible items are
> noise.

If you target your menu items to 'win.x' actions and action 'x' doesn't
exist on a particular window then, indeed, it will be greyed out.

This makes sense for global menubar type situations, but I agree that
seeing a menu full of greyed items within a window is a bit less
optimal.  Perhaps we could hide the items in this case, instead of
greying them...

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GMenuModel has landed

[Ryan Lortie]

hi,

On Fri, 2011-12-09 at 14:39 +0100, Nacho wrote:
> just one thing that I don't have quite clear...
> how will the extensibility be managed for the menus?
> i.e adding a new menuitem from a plugin.

If the plugin can gain access to the GMenu then it can modify it
(adding/removing items, etc).

In some ways this could be easier because of how 'sections' work in
GMenu -- any menu (including the menubar) can be composed of multiple
sections that are merged together.

If the plugin can gain access to the GApplication and/or
GtkApplicationWindows then it can add its actions there, as well.

No word on namespacing of actions or easy ability to remove all
menuitems/actions that were added by a particular plugin, though.

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GMenuModel has landed

[Ryan Lortie]

On Fri, 2011-12-09 at 09:50 +0100, Alexander Larsson wrote:
> Windows actually has an "application menu" thing. If you right-click on
> the application on the panel you can get app-specific operations in the
> menu. I'm not sure if the normal usecase for these match what the app
> menu is typically used for though.

Is this the so-called jumplist?  It sounds more likely that we'd treat
this as a 3rd type of menu -- since the shell, unity and mac os all have
this same concept these days as well...

Cheers

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list