RaphaÃl Quinet <[EMAIL PROTECTED]> writes:
> So the default should be to open the images with the correct
> orientation without asking, and there should be an option in the
> preferences (gimprc) that allows the user to ignore the EXIF
> Orientation tag or to be asked every time. The threshold for adding
> new options to the gimprc should be high, but I think that this one
> deserves it.
Sure, that has never been questioned. The best thing would probably be
to add a "[ ] Don't ask me again" toggle to the dialog. But I would
suggest that this is delayed until we have established a framework for
plug-ins to deal with such preferences. It would be wrong to depend on
a modifications to the core here. All plug-ins should have an easy way
to store configuration and presets. The current gimprc API in the PDB
is not really sufficient for this.
If we want to improve the image export functionality, and I think we
want to do that for 2.4, we will also need such functionality. I want
to suggest that we implement this by moving most of the GimpConfig
functionality from the core to libgimpbase or, alternatively, to a new
library, maybe called libgimpconfig. We should try to get this done
early in 2.3 since it will allow us to solve quite a bit of useability
issues that people have with plug-ins.
In the core we already make heavy use of the GimpConfig interface. It
basically adds serialization capabilites to any GObject that
implements it. There's a default implementation that takes care of
serializing and deserializing all object properties that have a
certain flag set in their GParamSpec.
GimpConfig was originally developed to solve the problem that it used
to be a PITA to add a new configuration value to gimprc. Nowadays this
is as simple as adding a new property to one of the classes that form
the GimpRc object. Adding a property to a GObject involves registering
a param-spec, a description of the property that defines the type of
the value and includes a default value, a description and more.
This information can then be used to serialize the value (generate a
string representation) and to deserialize it (load the serialized
values back in). No extra code needs to be written for this.
The addition of the object properties also pays out when a user
interfaces is needed to control the properties. We have a couple of
convenience constructors in the core. The more generic ones could also
be moved to libgimpwidgets. We use these functions to create the
widgets in the tool-options dialogs and also the preference dialog.
For example in order to create a check-button with a label next to it,
gimp_prop_check_button_new (config, property_name, label_text);
The returned button is a view on the property value. It is synced with
the object config. Any change to the button is applied to the object
and the button will also change it's state if the value changes by
other means. Having this functionality available for all plug-ins and
modules will certainly improve things. Plug-in user interface often
mainly consist of a couple of widgets to control a number of
configurations. If the plug-in implements an object that represents
this configuration, the GUI code reduces to a few lines. Implementing
a Reset button boils down to calling gimp_config_reset(). This will
reset all object properties to their default values. Saving the
current values as new default values would also become trivial. Even
maintaining a couple of configurations like we do for the tool-options
is easy. We can probably implement that as convenience functions in
The next step would of course be to move the PDB to using object
properties as well. The work invested in porting plug-ins to
GimpConfig will pay out again then.
There are a few things that we will need to decide upon, like in which
library this should live, what namespace it should use (is GimpConfig
a good name?), and how much of the core GimpConfig we actually want to
expose to plug-ins and modules. There are a couple of features like
the ability to nest objects that would perhaps better be kept for the
core only as they add quite a bit of complexity.
Gimp-developer mailing list