1. 02 Sep, 2018 3 commits
  2. 01 Sep, 2018 2 commits
  3. 31 Aug, 2018 3 commits
  4. 30 Aug, 2018 5 commits
  5. 29 Aug, 2018 1 commit
  6. 28 Aug, 2018 2 commits
    • Debarshi Ray's avatar
      Don't freeze the UI when launching Settings -> Online Accounts · 924fb4ec
      Debarshi Ray authored
      The UI freezes for a moment when launching Settings -> Online Accounts
      because g_application_register does slow I/O. After creating the
      GApplication's GDBusActionGroup, it queries the list of remote actions
      from the primary application instance over D-Bus to populate it.
      Fortunately, it's not necessary to fill in the GDBusActionGroup for
      activating a GAction. Therefore, this can be solved by directly using
      a GDBusActionGroup instead of going via a launcher GApplication.
      This does lose the platform data that the launcher GApplication would
      have passed when invoking the remote GAction, but hopefully that
      won't prove crucial.
      The loss of error handling doesn't matter. g_application_register was
      the only fallible step, and it could have only failed while querying
      the list of actions from the primary, something that's not needed
      anyway. If anything, it simplifies the code.
      Fallout from 556a9f30
    • Debarshi Ray's avatar
      utils: Style fixes · 0b05ddd4
      Debarshi Ray authored
  7. 26 Aug, 2018 1 commit
  8. 25 Aug, 2018 1 commit
  9. 24 Aug, 2018 1 commit
  10. 23 Aug, 2018 1 commit
  11. 22 Aug, 2018 1 commit
  12. 21 Aug, 2018 3 commits
    • Cheng-Chia Tseng's avatar
      Update Chinese (Taiwan) translation · fc526144
      Cheng-Chia Tseng authored
    • Debarshi Ray's avatar
      build: Drop ChangeLog and INSTALL, and silence Automake warnings · cc681022
      Debarshi Ray authored
      The ChangeLog generation was broken forever because it used
      $(top_srcdir)/missing, not $(top_srcdir)/config/missing. Including the
      Git log in tarballs isn't particularly useful. People are better off
      using the Git repository directly.
      A nice side-effect of switching Automake to "foreign" is that it
      silences these warnings:
        src/Makefile.am:563: warning: shell $(GLIB_COMPILE_RESOURCES:
          non-POSIX variable name
        src/Makefile.am:563: (probably a GNU make extension)
      The loss of INSTALL, caused by "foreign", isn't a big problem because
      the upcoming Meson port would have rendered it obsolete anyway. Users
      can easily look up how to build a Autotools-based project.
    • Baurzhan Muftakhidinov's avatar
      Update Kazakh translation · c772ba1a
      Baurzhan Muftakhidinov authored
  13. 20 Aug, 2018 1 commit
  14. 19 Aug, 2018 1 commit
  15. 17 Aug, 2018 11 commits
  16. 15 Aug, 2018 1 commit
  17. 14 Aug, 2018 1 commit
  18. 13 Aug, 2018 1 commit
    • Debarshi Ray's avatar
      build: Restore optimized builds by default · cfc3985f
      Debarshi Ray authored
      Building with AX_CHECK_ENABLE_DEBUG([yes]), which is what happens by
      default for non-release builds, turns off compiler optimizations and
      overrides any optimization specified via CFLAGS in the build
      environment. This means that the nightly Flatpaks, and almost all
      other non-release builds, are built without any optimization. It's
      very likely that this has a negative impact on the image processing
      loops in the built-in GeglOperations.
      It can be useful to turn off compiler optimizations to get a better
      debugging experience, but it becomes a problem if it stomps over the
      build environment while doing so. The person doing the builds should
      should get to decide between ease of debugging and reasonable
      performance. After all, debugging is not the only thing that a
      developer does. Performance measurements are important too, and one can
      use GDB reasonably well with the Autoconf default, which also happens
      to be what most distributions use, of "-g O2".
      This wouldn't have been such a problem if AX_CHECK_ENABLE_DEBUG
      attached its flags before the values from the environment instead of
      after, because in case of multiple -O options, the last such option is
      the one that's effective.
      Thankfully, "no" doesn't override the environment, which is what
      happens for release builds, and distributions generally set their own
      CFLAGS. Otherwise every single user-facing build would have been
      broken. Note that any release build without CFLAGS set in the
      environment would neither get debug symbols (ie., no "-g") nor any
      compiler optimization because AX_CHECK_ENABLE_DEBUG always suppresses
      the Autoconf defaults of "-g -O2".
      One solution could have been to default to "info" for non-release
      builds and recommend the use of --enable-debug=info while building from
      Git, but that would not address release builds without CFLAGS.
      Given that the only other thing the macro does is to define the NDEBUG
      pre-processor macro when debugging is set to "no", which isn't widely
      used in the GLib-based GNOME platform [1], it seems better to just
      remove it altogether.
      Interestingly, this also seems to unmask some valid cases of
      -Wclobbered and -Wmaybe-uninitialized with Fedora's
      gcc-7.3.1-6.fc27.x86_64 build.
      Fallout from 8f6fb686. The deprecated
      GNOME_DEBUG_CHECK macro didn't set any debugging or optimization flags.
      [1] glib/gio/xdgmime is the only widely used code path where assert(3)
          is used. It's also used in gio/kqueue/dep-list.c, which is
          *BSD-specific and in GTK+'s Broadway backend. All those can
          probably be replaced with g_assert*.