1. 25 Aug, 2011 7 commits
  2. 24 Aug, 2011 7 commits
  3. 23 Aug, 2011 6 commits
  4. 22 Aug, 2011 11 commits
    • Chun-wei Fan's avatar
      Update VS property sheets · d51e0615
      Chun-wei Fan authored
      Stop the "installation" of gio/gtimezonemonitor.h as it has been removed
      from GIO (commit 5b68b49b)
    • Chun-wei Fan's avatar
      Update GLib Visual C++ Projects · 7e5874dd
      Chun-wei Fan authored
      Define USE_SYSTEM_PCRE for all configurations which uses the PCRE that
      was already built and "installed" beforehand (i.e. the *_ExtPCRE
      configurations) so that the compilation will not pick up the
      GLib-bundled pcre.h when one wants to use the PCRE "installation" on
      his/her system.
    • Chun-wei Fan's avatar
      Update config.h.win32.in · 09a322c8
      Chun-wei Fan authored
      Make the pre-configured config.h(.win32.in) for Windows more like the
      config.h that would be produced during ./configure on Windows systems.
    • Colin Walters's avatar
      GTimeZoneMonitor: Revert addition of this class · 5b68b49b
      Colin Walters authored
      The main rationale for adding it was to avoid having gnome-shell
      mmap'ing /etc/localtime once a second.  However, we can just as easily
      run inotify there, and given no one else was clamoring for a way to
      detect when the time zone changes, I don't see a need for public API
      here - at least not yet.
      In the bigger picture, I just don't believe that the vast majority of
      applications are going to go out of their way to instantiate and keep
      around a random GTimeZoneMonitor class.  And if they do, it's has the
      side effect that for other bits of code in the process, local GDateTime
      instances may start varying again!
      So, if code can't rely on local GDateTime instances being in a
      consistent state anyways, let's just do that always.  The
      documentation now says that this is the case.  Applications have
      always been able to work in a consistent local time zone by
      instantiating a zone and then using it for GDateTime constructors.
      We fix the "gnome-shell stats /etc/localtime once a second" issue by
      using timerfd (in glib) and inotify (in gnome-shell).
    • Chun-wei Fan's avatar
      Update VS property sheets · 5fbf3c93
      Chun-wei Fan authored
      -Added glib/ghmac.h to the list of files to copy during the "install" stage
      -Cleaned up a bit (glib-2.0->glib-$(ApiVersion), where $(ApiVersion) is
    • Colin Walters's avatar
      gmain: Clarify that timeouts are in terms of monotonic time · f0db0d22
      Colin Walters authored
      Also note that monotonic time does not include time spent while
      suspended (at least on Linux).
    • Matthias Clasen's avatar
      GDateTime: use nl_langinfo() when available · 527dc867
      Matthias Clasen authored
      This makes g_date_time_format() react to LC_TIME, which is
      what people expect.
      Translators: this change means that the GDateTime strings
      are only used when the C library does not already provide
      suitable translated strings for these (month names, etc).
    • Matthias Clasen's avatar
      GDateTime: cosmetics · 040dcc8a
      Matthias Clasen authored
      Shuffle things around a bit, to move locale-dependent
      things together.
    • Matthias Clasen's avatar
      GDateTime: cosmetics · 6fae33b1
      Matthias Clasen authored
      Don't hide the recursion in g_date_time_format() behind
      a macro, make it explicit.
    • Matthias Clasen's avatar
    • Matthias Clasen's avatar
      GDateTime: don't use separate strings for upper/lowercase am/pm · 2282036b
      Matthias Clasen authored
      We can just as well change the case ourselves.
  5. 21 Aug, 2011 3 commits
  6. 19 Aug, 2011 6 commits