1. 05 Feb, 2019 1 commit
  2. 03 Feb, 2019 1 commit
  3. 02 Feb, 2019 1 commit
    • Leesoo Ahn's avatar
      main-toolbar: Enable the gear menu only when the item is loaded · 354f925d
      Leesoo Ahn authored
      The "app.gear-menu" GAction is enabled and disabled from both
      photos_application_actions_update and the MainToolbar when the mode
      changes. This makes things unpredictable by relying on the order in
      which the callbacks are invoked. Currently the MainToolbar was
      winning and rendering parts of commit 031df27c ineffective.
      
      Instead, this should only be handled in one place -
      photos_application_actions_update. It's a lot more fine-grained and
      informed than the MainToolbar itself. eg., the MainToolbar only knows
      about the mode changing to PREVIEW, but doesn't know whether the item
      has finished loading.
      
      This code was added in commit 7e12154b, and the above rationale
      held true even then. However, back then, the item's loading state was
      not looked at. This is probably why the problem got overlooked.
      
      !94
      354f925d
  4. 18 Jan, 2019 1 commit
  5. 17 Jan, 2019 1 commit
  6. 11 Jan, 2019 1 commit
  7. 02 Jan, 2019 1 commit
  8. 13 Dec, 2018 1 commit
  9. 11 Dec, 2018 1 commit
  10. 07 Dec, 2018 3 commits
    • Debarshi Ray's avatar
      72bd0382
    • Debarshi Ray's avatar
      gegl: Allow overriding the number of threads · 085e6634
      Debarshi Ray authored
      A subsequent commit will use gegl:path to create images that will be
      used as input data for testing. It turns out that, for hitherto
      unknown reasons, using multiple threads causes minor disturbances in
      gegl:path's output which interferes with the tests. Therefore, it is
      useful to override the number of threads used by GEGL for affected
      tests where the multi-threading isn't part of the code that is being
      tested.
      
      Since gegl_init reads the GEGL_THREADS environment variable, it has to
      be called later so that it can override the default GEGL
      configuration.
      
      !84
      085e6634
    • Debarshi Ray's avatar
      gegl: Style fix · cf0e0fde
      Debarshi Ray authored
      cf0e0fde
  11. 30 Nov, 2018 3 commits
    • Debarshi Ray's avatar
      gegl, thumbnailer: Don't use gegl:save-pixbuf · 38cea1a9
      Debarshi Ray authored
      ... to convert a GeglBuffer to a GdkPixbuf. This is part of a general
      trend of moving away from using graphs to convert a GeglBuffer to and
      from GdkPixbuf.
      38cea1a9
    • Debarshi Ray's avatar
      gegl: Add photos_gegl_pixbuf_new_from_buffer · 5f54518a
      Debarshi Ray authored
      This is part of a new set of APIs for GeglBuffer that don't require the
      creation of a graph. These will allow decoding and encoding image file
      formats to and from a GeglBuffer through asynchronous and cancellable
      methods with error handling. These will follow GIO idioms and be
      similar to the codec APIs for GdkPixbuf. There will be a compatibility
      layer to convert a GeglBuffer to and from GdkPixbuf for legacy reasons.
      
      These APIs will address the current lack of cancellation and error
      handling in gegl:load, and make it easier to port existing code away
      from GdkPixbuf.
      
      Bump minimum GdkPixbuf version to 2.36.8.
      5f54518a
    • Debarshi Ray's avatar
      7128f1df
  12. 23 Nov, 2018 1 commit
  13. 22 Nov, 2018 1 commit
  14. 31 Oct, 2018 1 commit
    • Debarshi Ray's avatar
      application, thumbnailer: Remove redundant GResource registration · 8a70b969
      Debarshi Ray authored
      GResources in the form of C source files generated by
      glib-compile-resources(1) without the --manual-register flag, are
      automatically registered as long as the compiler supports constructor
      and destructor functions. Given that there's no explicit desire to
      support compilers without such support, codified by the lack of the
      --manual-register flag, calling g_resources_register is redundant.
      
      Such statically compiled and linked GResources are automatically added
      as GStaticResources to a list internal to GIO by the generated
      constructor function, and are lazily registered whenever their
      contents are referred to by their global path or URI.
      
      This is unlike standalone *.gresource bundles. Those are GVariant
      database (or GVDB) files, which need to be explicitly registered with
      g_resources_register after being loaded with g_resource_load, so that
      their contents can be referred to by their global path or URI.
      
      GNOME/gnome-photos!77
      8a70b969
  15. 23 Oct, 2018 1 commit
  16. 20 Oct, 2018 6 commits
  17. 19 Oct, 2018 1 commit
  18. 18 Oct, 2018 5 commits
  19. 11 Oct, 2018 4 commits
    • Debarshi Ray's avatar
      build: Unbreak by generating the library headers before using them · bac5e70c
      Debarshi Ray authored
      ... from outside the library.
      
      As suggested by Emmanuele Bassi.
      
      Fallout from 37a598b0
      
      GNOME/gnome-photos#63
      bac5e70c
    • Debarshi Ray's avatar
      build: Split some code into a private shared library · 37a598b0
      Debarshi Ray authored
      The overall idea is to start adding unit tests, wherever possible.
      Putting the tested code in a private library makes it accessible from
      test cases because they can link to it.
      
      Subsequent commits will add a new codec API for GeglBuffer. It will be
      very important to have unit tests for those code paths because:
        * That code will be inherently testable and tests are great.
        * That code is likely to be security sensitive, will handle all
          sorts of dodgy input from untrusted sources, and written using
          very old APIs with brittle error handling.
      
      This is a step towards that.
      
      A private shared library seems better than a private static archive
      because the most easily testable code paths are shared across the main
      application and the thumbnailer. Therefore, the assumption is that the
      benefits of sharing that code across both processes outweigh the
      drawbacks of having to resolve symbols from yet another shared library
      on startup. However, this is just an assumption. There's no data
      behind it.
      
      GNOME/gnome-photos#63
      37a598b0
    • Debarshi Ray's avatar
      build: Rearrange the Makefile.am for subsequent changes · dc342489
      Debarshi Ray authored
      A subsequent commit will split some common code into a private shared
      library. It's desirable to ensure that each binary artifact doesn't
      inadvertently grow new dependencies.
      
      So far, there was a global AM_CPPFLAGS and target-specific LDADDs.
      It means that the build would've only failed for unintended linker
      dependencies while linking the final binaries, and not while compiling
      the individual translation units into object files. This is improved
      by replacing the global AM_CPPFLAGS with target-specific CPPFLAGS. It
      is likely to catch such issues sooner because linker dependencies are
      often accompanied by matching preprocessor dependencies; and also
      prevent against inadvertent preprocessor-only dependencies.
      
      Using target-specific CPPFLAGS does have the negative side-effect of
      building the common source files multiple times - once for each target.
      Hopefully this will only be a temporary setback until the common code
      is split out into a private shared library.
      
      The target-specific variables were moved closer to their SOURCES
      counterparts for better readability.
      
      GNOME/gnome-photos#63
      dc342489
    • Debarshi Ray's avatar
      image-view, preview-view: Remove overhead when drawing the background · b81579f1
      Debarshi Ray authored
      The draw-background originated in gegl-gtk. Any use of a signal implies
      taking a global lock in glib/gobject/gsignal.c, which is better avoided
      in code paths aiming to achieve 60 frames per second.
      
      (Emitting a signal is even worse than just checking if there's a
      pending handler. It involves marshalling the arguments through GValue
      and a lot of extra code over and above taking the lock. Just avoiding
      that much yields visible performance improvements. [1,2,3])
      
      Therefore, it's better to get rid of it, and have ImageView draw its
      own background. It's also more idiomatic in GTK+ 3.x.
      
      [1] GNOME/gnome-shell!153
      [2] GNOME/gtk@cdd951e9
      [3] GNOME/gtk@68e50d20
      b81579f1
  20. 09 Oct, 2018 2 commits
  21. 04 Oct, 2018 3 commits