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.
Per Pippin, the only color model that can
have double precision is RGB/A.
Therefore, we need to switch all others to
use float instead. This patch converts the
HSV and HSVA double babl formats.
I also changed a bit the new color serialization by adding a (color …)
symbol framing the contents, for cases where we don't have a specific
property name, e.g. for the color history list stored in colorrc, unlike
for GimpConfig GeglColor properties.
While doing this, I moved GeglColor property deserialization code into
gimp_scanner_parse_color() which is now able to recognize both older
(color-rgb|rgba|hsv|hsva with no color space) and newer serialization
formats ("color", color model agnostic and space aware).
Since it appeared with GLib 2.68.0, we could not change this until we
bumped the dependency which has only become possible a few days ago
(since Debian testing is our baseline for dependency bumps). Cf.
previous commit.
As this is a drop-in replacement (just a guint parameter changed to
gsize to avoid integer overflow), search-and-replace with:
> sed -i 's/g_memdup\>/g_memdup2/g' `grep -rIl 'g_memdup\>' *`
… followed by a few manual alignment tweaks when necessary.
This gets rid of the many deprecation warnings which we had lately when
building with a recent GLib version.
Negative int values were not correctly handled because value.v_int is unsigned
causing a conversion to a large positive value.
To fix this we cast it to gint64 first before making it negative.
Especially need to watch out with forgetting `(array)` and `(out)`
annotations, as they can really give a different API in certain (if not
most) bindings.
Allow calling gimp_scanner_new_string() with a NULL `text` and a
negative `text_len` (which is interpreted as 0), instead of
requiring `text_len == 0` in this case. This allows passing a
negative `text_len` unconditionally to infer the length, even when
the string may be NULL.
A number without a decimal point can be put into a gdouble just fine,
no need to refuse them. Moreover, g_ascii_dtostr() serializes doubles
without fractional part without a decimal point, and we are soon going
to use it.
instead of choking and aborting parsing of the entire config file. The
negative values are still clamped away after parsing, but at least we
properly read them now.
because it confuses gtk-doc and breaks some links. Also change the
"Index of new symbols in GIMP 2.x" sections to be what seems to be the
modern standard (looked at the GLib and GTK+ docs), and update some
other stuff.
Move all code from gimp_scanner_new_file() to gimp_scanner_new_gfile().
If the passed GFile has a path, use a GMappedFile like before, otherwise
GIO-read the entire file into an allocated buffer and parse that buffer.
2009-01-17 Michael Natterer <mitch@gimp.org>
* all files with a GPL header and all COPYING files:
Change licence to GPLv3 (and to LGPLv3 for libgimp).
Cleaned up some copyright headers and regenerated the parsers in
the ImageMap plugin.
svn path=/trunk/; revision=27913
2007-10-27 Sven Neumann <sven@gimp.org>
* libgimpconfig/gimpscanner.c (gimp_scanner_parse_color):
initialize GimpRGB, just to be sure.
svn path=/trunk/; revision=23975
2005-09-28 Sven Neumann <sven@gimp.org>
* libgimpconfig/gimpscanner.c (gimp_scanner_new_file): mmap the
config file using GMappedFile. Let's see how well this works...
2004-05-18 Michael Natterer <mitch@gimp.org>
Allow plug-ins to register menu icons. Fixes bug #120500.
* app/core/core-enums.[ch]: added enum GimpIconType which can
be one of { STOCK_ID, IMAGE_FILE, INLINE_PIXBUF }.
* app/config/gimpconfigwriter.[ch] (gimp_config_writer_data)
* app/config/gimpscanner.[ch] (gimp_scanner_parse_data): new
functions which write/parse raw binary data. Needed for storing
inline pixbufs in pluginrc.
* app/config/gimpconfigwriter.[ch] (gimp_config_writer_identifier):
new function which writes out an unquoted and unescaped string.
* app/plug-in/plug-in-proc.[ch] (struct PlugInProcDef): added
new members "icon_type", "icon_data_length" and "icon_data".
Reordered members so file_proc specific stuff is at the end.
(plug_in_proc_def_get_stock_id)
(plug_in_proc_def_get_pixbuf): new functions to access the
procedure's icon.
* app/plug-in/plug-in-rc.c: save/restore the registered icons.
* app/actions/file-dialog-actions.c
* app/actions/plug-in-actions.c: set the action's stock ID from
the procedure's stock ID.
* app/widgets/gimppluginaction.c
(gimp_plug_in_action_connect_proxy): if the procedure provides a
pixbuf, set it as icon for the menu item.
* app/menus/file-dialog-menu.[ch]
* app/menus/file-open-menu.c
* app/menus/file-save-menu.c
* app/xcf/xcf.c: changed accordingly.
* tools/pdbgen/pdb/plug_in.pdb (plugin_icon_register): new PDB
function which can be called during query().
* tools/pdbgen/enums.pl
* app/pdb/internal_procs.c
* app/pdb/plug_in_cmds.c
* libgimp/gimpenums.h
* libgimp/gimpplugin_pdb.c
* libgimp/gimpplugin_pdb.h
* plug-ins/pygimp/gimpenums.py
* plug-ins/script-fu/script-fu-constants.c: regenerated.
* plug-ins/common/plugindetails.c
* plug-ins/common/uniteditor.c
* plug-ins/print/print.c: register stock_id icons.
* plug-ins/common/screenshot.c: register an inline_pixbuf icon for
testing purposes (used emblem-camera.png from gnome-icon-theme).
* app/actions/dialogs-actions.c
* app/actions/file-actions.c: unrelated: added some more icons
to menu items.
2004-01-19 Sven Neumann <sven@gimp.org>
* app/*/*.c: include "libgimpbase/gimpbase.h" where needed; removed
now unnecessary inclusions of "file/file-utils.h".
2004-01-19 Sven Neumann <sven@gimp.org>
* app/file/file-utils.[ch]: removed file_utils_filename_to_utf8() ...
* libgimpbase/gimputils.[ch]: ... and added it here as
gimp_filename_to_utf8(). Added some docs that promise less than
the current implementation holds so that we can change the
implementation later.
* app/*/*.c: use gimp_filename_to_utf8() where
file_utils_filenames_to_utf8() has been used before.
* libgimpbase/gimpbase.def: changed accordingly.
* configure.in: reset GIMP_INTERFACE_AGE.
