1. 31 Oct, 2020 5 commits
  2. 30 Oct, 2020 12 commits
    • Jehan's avatar
      f342b566
    • Jehan's avatar
      libgimpwidgets, plug-ins: continue GimpScaleEntry port to real widget. · 10dfaead
      Jehan authored
      I got rid of gimp_scale_entry_set_sensitive(), as we can now use the
      generic gtk_widget_set_sensitive(), and I ported the 2 plug-ins using
      this function.
      I also created gimp_scale_entry_set_value() to set the value (nicer than
      setting object properties).
      10dfaead
    • Jehan's avatar
      libgimpwidgets: better algorithm for GimpScaleEntry default increments. · ad8b4178
      Jehan authored
      For very small ranges, just dividing by 10 and 100 is not very good. You
      could end up with weird step values. It is often better to use 10^(-x)
      values just below your range.
      I.e for a 0.5 range, a step of 0.1 and page of 0.01 are probably fine
      (better than 0.05 and 0.005).
      
      Of course as usual these are default values only and setting custom
      increments is possible through available API.
      
      Also fixing a small bug in gimp_scale_entry_set_increments() added in
      commit 0f05825a.
      ad8b4178
    • Jehan's avatar
      libgimpwidgets: fix def files. · 99193230
      Jehan authored
      And consequentely the distcheck as well as Windows builds.
      99193230
    • Jehan's avatar
      app, libgimpwidgets, plug-ins: default increments for GimpScaleEntry. · 0f05825a
      Jehan authored
      Instead of setting always manually the step and page increments when
      creating a GimpScaleEntry, let's just generate some common cases
      automatically. Indeed the increments are rarely something you want to
      care about. The algorithm used is:
      - For a range under 1.0, use a hundredth and a tenth (typically a [0,
        1.0] range will step-increment of 0.01 and page-increment of 0.1).
      - For small ranges (under 40), step-increment by 1, page-increment by 2.
      - For bigger ranges, step-increment by 1, page-increment by 10.
      
      For use cases when you absolutely want specific increment values, I add
      the gimp_scale_entry_set_increments() function. It is much better to
      have a small and understandable constructor call followed by
      configuration calls (only when needed) rather than a constructor with a
      crazy amount of parameters. Hence gimp_scale_entry_new() went from 17
      arguments (absolutely unreadable calls) to now 5.
      0f05825a
    • Jehan's avatar
      app, libgimpwidgets: improve GimpScaleEntry API. · 1e81bdab
      Jehan authored
      * Add a gimp_scale_entry_get_value() because if we don't do a property
        widget, getting the value of the widget easily is a main point.
      * Move gimp_scale_entry_(set|get)_logarithmic() to the new class API.
      * Internally edit the GtkSpinButton width depending on min/max values,
        place digits, and possible value sign.
      * Emit a "value-changed" signal (similarly to other widgets with a
        value), for cases when just binding the "value" property is not
        enough.
      * Finally use the new API in palette-import-dialog.
      1e81bdab
    • Jehan's avatar
      d81b151e
    • Jehan's avatar
      libgimpwidgets: make GimpScaleEntry into its own widget. · 5238958e
      Jehan authored
      Instead of the gimp_scale_entry_new() which creates several bound yet
      independant widgets, and in the same time pack them into an existing
      grid and return a GtkAdjustment (while heavily relying on GObject data
      to link widgets), let's have a proper custom widget with its own clean
      API.
      This also simplifies the gimp_prop_scale_entry_new() property widget
      variant.
      
      First advantage is that we don't force the usage of a grid to use this
      widget (there are a few pieces of code which create a GtkGrid with only
      this inside just to be able to use this feature).
      
      Second thing is that I am creating a much simpler API.
      gimp_scale_entry_new() had 17 parameters! How crazy is that? So I
      removed all the grid packing related parameters. Also I moved the spin
      button/scale unconstraining parameters into their separate function,
      because the constrained behavior is the most common use case, so it's
      stupid to add 3 permanent dummy parameters for most calls. Instead the
      few times where we'll want different ranges for the spin button and the
      scale, we'll call the separate API gimp_scale_entry_set_range().
      
      Thirdly the tooltip can be set directly with gimp_help_set_help_data()
      since this is now its own widget. No need to have dedicated logics
      anymore, better stay generic. Similarly no need of a custom function to
      switch sensitivitivy (instead of generic gtk_widget_set_sensitive()).
      
      Fourth thing is that we should not use macros for the public API, but
      proper functions, because macros are not properly introspected for
      binding.
      
      For future improvements, maybe we could even make this widget implement
      GtkOrientable interface, in order to be able to use it vertically.
      
      Note: right now, I created a separate gimp_scale_entry_new2() and only
      modified the property widget API to use this new code. Eventually I will
      remove fully the old gimp_scale_entry_new() function (and the new code
      will replace it).
      5238958e
    • Jehan's avatar
      app, libgimp, pdb: improve a bit gimp_image_get_parasite_list() docs. · 1a5eea4f
      Jehan authored
      It is more accurate to say it returns a list of parasite names rather
      than a list of parasites (as we could take it as meaning a list of
      GimpParasite). Of course, we would soon see the actual element contents
      (if not for the introspection metadata (element-type gchar*)), but
      better being accurate in textual docs too.
      1a5eea4f
    • Jehan's avatar
      libgimpwidgets: store GimpFileEntry private data in appropriate struct. · 82ee4789
      Jehan authored
      There was a /* FIXME MOVE TO PRIVATE */ and anyway it makes sense to not
      leave such data in the public API.
      
      I note that the whole widget declaration is between #ifndef
      GIMP_DISABLE_DEPRECATED macros so maybe we should just delete it
      altogether for GIMP 3, but it might still have a usage. Maybe it could
      also be interesting to experiment with the file portal on such widget
      for plug-in usage? Let's see.
      82ee4789
    • Jehan's avatar
      plug-ins: fix PDB data identifier to be canonical. · c109a35c
      Jehan authored
      This is the bug which triggered me to do previous commit because the
      error message was talking about a procedure name. Now the error message
      is right, but let's not have an error at all! ;-)
      c109a35c
    • Jehan's avatar
      app, pdb: use gimp_is_canonical_identifier() for pdb-get|set-data… · 1fb24488
      Jehan authored
      … instead of gimp_pdb_is_canonical_procedure().
      The later would set an error saying "Procedure name '%s' is not a
      canonical identifier". Yet the data label is not a procedure name. It is
      a random name. I'm not sure why we need it to be canonical too, but why
      not. In any case, let's use the right function.
      1fb24488
  3. 28 Oct, 2020 1 commit
  4. 27 Oct, 2020 4 commits
  5. 26 Oct, 2020 17 commits
  6. 25 Oct, 2020 1 commit