Commit graph

9 commits

Author SHA1 Message Date
Jehan
a46d0c3117 app, libgimp, pdb: further improve function documentation.
- Consistently add the text about inserting items into the image after
  creation, with correct function links/references.
- Consistent grammar for function blurb.
- Make @name argument nullable for gimp_path_new().
2025-10-11 22:10:30 +02:00
Michael Natterer
69f84942fa app: rename app/vectors/ to app/path/ 2025-07-07 15:44:15 +02:00
Jehan
dc3e815ff0 app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/.
Several types functions were using the wording "float" historically to
mean double-precision, e.g. the float array type (which was in fact a
double array). Or the scanner function gimp_scanner_parse_float() was in
fact returning a double value. What if we wanted someday to actually add
float (usually this naming means in C the single-precision IEEE 754
floating point representation) support? How would we name this?

Now technically it's not entirely wrong (a double is still a floating
point). So I've been wondering if that is because maybe we never planned
to have float and double precision may be good enough for all usage in a
plug-in API (which doesn't have to be as generic so the higher precision
is enough)? But how can we be sure? Also we already had some functions
using the wording double (e.g. gimp_procedure_add_double_argument()), so
let's just go the safe route and use the accurate wording.

The additional change in PDB is internal, but there too, I was also
finding very confusing that we were naming double-precision float as
'float' type. So I took the opportunity to update this. It doesn't
change any signature.

In fact the whole commit doesn't change any type or code logic, only
naming, except for one bug fix in the middle which I encountered while
renaming: in gimp_scanner_parse_deprecated_color(), I discovered a
hidden bug in scanning (color-hsv*) values, which was mistakenly using a
double type for an array of float.
2024-11-02 15:00:03 +01:00
Jehan
b8712b27de Issue #12011: gimp-path-import-from-file etc. are misnamed. 2024-09-11 16:26:45 +02:00
Alx Sa
d701b70336 pdb, libgimpbase: Rename GIMP_VECTORS_STROKE_TYPE...
...to GIMP_PATH_STROKE_TYPE as part of
the GimpVectors -> GimpPath API
update.
2024-07-19 15:07:43 +00:00
Alx Sa
2e6938b3da app: Rename app/core GimpVectors vectors API...
...to path.
Changes the names of
gimp_vectors_* () API to
gimp_path[s]_* (). Renames related files
to [path] instead of [vectors], along with
relevant enums and functions.
2024-07-13 05:07:57 +00:00
Alx Sa
e8df68fb65 libgimp, app, pdb: Rename GimpVectors to GimpPath
This commit renames the GimpVectors
object to GimpPath in both app/core and
in libgimp. It also renames the files
to gimppath.[ch] and updates the relevant
build and translation files.
There are still outstanding gimp_vectors_* ()
functions on the app side that need to be renamed
in a subsequent commit.
2024-07-12 06:16:25 +00:00
Alx Sa
853f37bed9 app: Rename app/core GimpImage vectors API...
...to paths.
Similar to d0bdbdfd, but covering the
app/core versions of the API instead of
libgimp. Changes the names of
gimp_image_*_vectors () API to
gimp_image_*_path[s] ().
Also renames some related functions such
as gimp_image_pick_path (). The next step
will be to rename the gimp_vectors_* () to
gimp_path_* ().
2024-07-11 01:17:49 +00:00
Alx Sa
b90b6bce00 pdb, libgimp: Rename libgimp GimpVectors vectors API...
...to paths
Follow-up to d0bdbdfd. Changes all
gimp_vectors_* () PDB to gimp_path_* ()
and renames relevant PDB files from
vectors to path.
The next step will be to rename
GimpVectors in libgimp to GimpPath,
removing the last (public) trace of it.
2024-07-08 23:39:51 +00:00
Renamed from pdb/groups/vectors.pdb (Browse further)