1. 28 Sep, 2019 1 commit
  2. 24 Sep, 2019 1 commit
  3. 20 Sep, 2019 2 commits
  4. 11 Sep, 2019 1 commit
  5. 10 Sep, 2019 1 commit
  6. 07 Sep, 2019 1 commit
  7. 03 Sep, 2019 4 commits
  8. 31 Aug, 2019 1 commit
  9. 30 Aug, 2019 1 commit
  10. 29 Aug, 2019 1 commit
    • Michael Natterer's avatar
      app, libgimp: get rid of all ID GTypes and ID param specs · 392f00ba
      Michael Natterer authored
      Turn all ID param specs into object param specs (e.g. GimpParamImageID
      becomes GimpParamImage) and convert between IDs and objects in
      gimpgpparams.c directly above the the wire protocol, so all of app/,
      libgimp/ and plug-ins/ can deal directly with objects down to the
      lowest level and not care about IDs.
      Use the actual object param specs for procedure arguments and return
      values again instead of a plain g_param_spec_object() and bring back
      the none_ok parameter.
      This implies changing the PDB type checking functions to work on pure
      integers instead of IDs (one can't check whether object creation is
      possible if performing that check requires the object to already
      For example gimp_foo_is_valid() becomes gimp_foo_id_is_valid() and is
      not involved in automatic object creation magic at the protocol
      level. Added wrappers which still say gimp_foo_is_valid() and take the
      respective objects.
      Adapted all code, and it all becomes nicer and less convoluted, even
      the generated PDB wrappers in app/ and libgimp/.
  11. 28 Aug, 2019 1 commit
  12. 27 Aug, 2019 5 commits
  13. 24 Aug, 2019 3 commits
  14. 22 Aug, 2019 2 commits
    • Jehan's avatar
      libgimp: update def files. · de7447d8
      Jehan authored
    • Jehan's avatar
      app, pdb, libgimp: add a new GimpImage class for plug-ins. · 4db8cda2
      Jehan authored
      This means that all functions which were returning or taking as
      parameter an image id (as gint32) are now taking a GimpImage object
      The PDB is still passing around an id only over the wire. But we create
      an object for plug-ins to work on.
      This is quite a huge API break, but is probably the best bet for the
      future quality. It will make nicer API instrospection (and nicer API in
      binding), will fix the issues with pspec on GimpImageID in Python
      bindings (which makes the current Python API unusable as soon as we need
      to work on images, which is most of our plug-ins!), etc.
      Also it will allow to use signals on images, which will be a great asset
      when we will finally have bi-directionnal communications (i.e. plug-ins
      would be able to connect to image changes, destructions, and whatnot).
  15. 19 Aug, 2019 2 commits
  16. 17 Aug, 2019 1 commit
  17. 16 Aug, 2019 1 commit
  18. 15 Aug, 2019 1 commit
  19. 14 Aug, 2019 3 commits
  20. 13 Aug, 2019 3 commits
  21. 12 Aug, 2019 1 commit
  22. 11 Aug, 2019 3 commits