Hi,
David Odin <David@xxxxxxxxxxx> writes:
> > Actually the plan was to let the plug-in previews respect the settings
> > from gimprc that already exist:
> >
> > (transparency-size medium-checks)
> >
> > Sets the size of the checkerboard used to display transparency.
> > Possible values are small-checks, medium-checks and large-
> > checks.
> >
> > (transparency-type gray-checks)
> >
> > Sets the manner in which transparency is displayed in images.
> > Possible values are light-checks, gray-checks, dark-checks,
> > white-only, gray-only and black-only.
> >
>
> How hard would this be to implement?
It would involve two changes:
(1) Add transparency-size and transparency-type properties to
GimpPreviewArea and use them when drawing the checkerboard.
(2) Somehow get the preferences to the plug-in.
Step 1 should be pretty much straight-forward. The properties can be
copied more or less directly from GimpDisplayConfig (app/config).
Checkerboard rendering will become slightly more complex but I don't
expect any noticeable slowdown. The code has still some room for
optimizations anyway.
There are two possibilities to implement step 2. Either we add a PDB
API to access the checkerboard settings:
gimp_gimprc_get_transparency_type() ??
gimp_gimprc_get_transparency_size() ??
or (and I'd prefer that), we pass these settings to the plug-in in the
GPConfig message. This is a message that is sent to each plug-in when
it is started. We handle this in libgimp and allow the plug-in to
access the settings using a simple API. See for example
gimp_show_tool_tips() or gimp_display_name().
Using the config message is definitely the prefered way of doing this
but unfortunately we are completely braindead and didn't add any
padding to the GPConfig struct :( However, there's still hope but
things are becoming ugly now. Readers with a weak stomach, please
leave now...
The GPConfig struct contains an unused member which is "gamma". This
is a double and IIRC a double is guaranteed to be always 8 bytes. So
we could remove "gamma" and replace it with two 32bit integers and use
those for the transparency settings. We could even squeeze the
transparency settings into less than 8 bytes and keep the remaining
bytes for future use. Might become useful pretty soon, for example as
a way to pass whether color management should be enabled or disabled.
Can anyone think of better ways to do this? Are there any strong
objections against the ugly hack I outlined above? Did I overlook
something (like for example platforms where a gdouble is not 8 bytes)?
Sven
