From: Sven Neumann <sven@xxxxxxxx>
Date: 15 Aug 2004 02:39:20 +0200
Robert L Krawitz <rlk@xxxxxxxxxxxx> writes:
> Right. The problem is how the application determines whether a
> particular parameter is a measurement or just an arbitrary floating
> point number. The only piece of framework that Gimp-Print's going to
> have is a new parameter type that's a "unit" rather than a
> dimensionless floating point or integer number. How the application
> deals with that is up to it. Basically it sounds like we're in
> reasonable agreement here.
Yes, sounds like it. Perhaps it would be easier to speak in terms of
code snippets...
>From the libgimpprint standpoint, it's simply a matter of adding
STP_PARAMETER_TYPE_DIMENSION, along with the appropriate bounds and
defaults members to stp_parameter_t.
typedef enum
{
STP_PARAMETER_TYPE_STRING_LIST, /*!< Single string choice from a list. */
STP_PARAMETER_TYPE_INT, /*!< Integer. */
STP_PARAMETER_TYPE_BOOLEAN, /*!< Boolean. */
STP_PARAMETER_TYPE_DOUBLE, /*!< Floating point number. */
STP_PARAMETER_TYPE_CURVE, /*!< Curve. */
STP_PARAMETER_TYPE_FILE, /*!< Filename (NYI, need to consider security). */
STP_PARAMETER_TYPE_RAW, /*!< Raw, opaque data. */
STP_PARAMETER_TYPE_ARRAY, /*!< Array. */
STP_PARAMETER_TYPE_DIMENSION, /*!< Linear dimension. */
STP_PARAMETER_TYPE_INVALID /*!< Invalid type (should never be used). */
} stp_parameter_type_t;
> That's an issue for the plugin to deal with. Gimp-Print deals
> entirely in points (1/72"), and it's up to the application to
> translate that into units useful for people.
That's fine. As long as there's a clearly specified value, we can deal
with that.
Fine.
--
Robert Krawitz <rlk@xxxxxxxxxxxx>
Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf@xxxxxxxxxxxx
Project lead for Gimp Print -- http://gimp-print.sourceforge.net
"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
