Hi Sven,

<quoted text pulled over from Bugzilla>

> There is currently no way a plug-in or a display filter could access
> these values if they become part of gimprc. If we would make them
> parasites, that should work out of the box w/o any changes to the
> core. Since parasites can be accessed from plug-ins, the configuration
> should also be done in a plug-in.

While I can see the logic in that from a technical standpoint, I can't help feeling that from a user-interface perspective configuration should be done in the prefs dialog. Is there any reason (apart from technical inelegance) why the gimpdisplayconfig code that would handle getting and setting these options couldn't take responsibility for maintaining some suitable parasites?

> That's what I was expecting to happen outside the core GIMP
> development based on the GIMP 2.0 API already. Of course we could
> decide to do it differently now that we have the chance to do changes
> to the core.

We need some minor changes to the core - presumably we want to avoid anything too drastic!

From my point of view, I think it's important to tweak the display module system so that the display modules can fetch parasites on a per-image basis (rather than just global ones) - this will let me implement the features I want in the display module.

This conflicts slightly with the goal of applying a filter to the colour selectors - but this should be solved easily enough with a NULL argument.

The other major core change will be setting up default display filters - it's currently extremely tedious enabling the filter manually for each and every image that's opened!

Time, perhaps, to open Bugzilla issues for these changes?

I'm about to attach a proof-of-concept patch in Bugzilla that expands the proof module to do regular source->monitor colour correction, with optional soft-proofs, instead of just soft-proofs limited to sRGB source and monitor.

All the best,
Alastair M. Robinson
Gimp-developer mailing list

Reply via email to