"Alastair M. Robinson" <[EMAIL PROTECTED]> writes:

>  > 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?

You misunderstood me. What I was saying is that GIMP 2.0 has the API
to implement all this and I would have loved to see this added about a
year ago when it was proposed quite detailed already. Since that
didn't happen we can now also do some useful changes to the modules
API and to the core to integrate it even better. GimpDisplayConfig is
however definitely the wrong object to add this stuff to. I will try
to write down my ideas on how to share color management configuration
somewhen this weekend.

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

I don't think so. It will only cause more work. Instead we should
discuss here what changes we actually need. The actual implementation
is the minor part.

> 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.

The proof filter should do proofs and nothing but proofs. What you are
suggesting sounds more like a new filter.

Gimp-developer mailing list

Reply via email to