On Fri, 21 Jan 2005 00:29:00 +0100, Sven Neumann <[EMAIL PROTECTED]> wrote:
> 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.
Well, the main point was that most users should not even see that
dialog once, unless they explicitely change the default option in the
preferences. This is in line with what other programs are doing and
it is IMHO better because most users should not have to care about
the details of the file format.
> 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.
Even though the current gimprc API in the PDB is rather simple (both
the query and set operations are limited to simple strings), it is not
too bad. It is of course a good idea to improve it, but it should not
be discarded too early. Using strings, there is the problem of
marshalling/unmarshalling the data, but having to use the PDB for this
is a good feature from my point of view: it automatically avoids some
concurrency problems that could occur if the plug-ins were accessing
files directly. It also provides a single point from which some
additional policies could be applied.
> 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.
This is again a good idea, but does this mean that the plug-ins
converted to use GimpConfig would then start accessing the config
files directly? I would prefer to make sure that all set/get
operations for the configuration options are going through the PDB and
handled by the core (this could of course be done transparently by the
GimpConfig implementation). If not, then it will be necessary to
implement some kind of locking mechanism for the files, in order to
avoid problems in case the core and a plug-in are trying to update the
same file. I am worried about the configuration parameters that could
be used by more than one plug-in.
> 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.
For the namespace, GimpConfig is fine. GimpProperty (or
GimpPlugInProperty) could be better for those who are familiar with
Java and persistent properties, but could also introduce some
confusion with the existing usage of properties that can be set on
objects. Regarding the features, I agree that nested objects would be
a bit overkill: being able to store simple data types (and edit them
with the appropriate widgets) would probably be sufficient.
Gimp-developer mailing list