On Fri, 21 Jan 2005 00:29:00 +0100, Sven Neumann <sven@xxxxxxxx> wrote: > Raphaël Quinet <quinet@xxxxxxxxxx> 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. -Raphaël
