On Thu, 22 Jun 2006 08:10:19 +0200, Sven Neumann <[EMAIL PROTECTED]> wrote:
> On Thu, 2006-06-22 at 00:35 +0200, Raphaël Quinet wrote:
> > Cleaner code (core/GUI separation, maintainable by different people),
> > lower overhead (especially when changing many properties) and more
> > importantly providing the start of a solution for avoiding the
> > concurrency issues that I mentioned earlier.
> Sorry, but I don't follow you on the first arguments, they seem
> unrelated. Where the code lives has nothing to do with how clean it is.

Well, let's say that it makes it a bit easier if the code is at least
split in separate directories (even if a library is not required for that).
As for the lower overhead, it does make a difference if the file plug-ins
can link with a library directly or if they have to convert all data and pass
it through the PDB for every action, especially when these PDB calls have to
spawn a new process which in turn decodes the data, re-encodes it again for
the PDB (setting the parasite) and then only returns the result to the
initial plug-in.  These 4 encoding/decoding steps and spawning of new
processes have to be done for every single property that is set or read by
the file plug-ins.

> So the argument for having this library now is that it allows avoiding
> the concurrency issues. But that's something that we will only get later
> anyway. That makes me think that it will be best to keep the code in a
> plug-in, accessible over the PDB. That should give us everything we need
> for 2.4 and avoids the need for defining an API now that we might have
> to support for quite a while.

To be frank, I thought that you agreed with the principle of moving the
metadata core into a library when we discussed it last time.  I thought
that the discussion about the API would be mainly about the features that
the API should expose, rather than whether it should exist as a library API
or be limited to the PDB.  I got a bit bored with the PDB implementation
and its limitations, that's why I expected to be more motivated to work on
the remaining issues after getting rid of the extra PDB calls.

> > > [...] I wouldn't want to see the core crash because
> > > some camera manufacturer made a mistake and the camera creates images
> > > with corrupt metadata.

By the way, crashing the core because of corrupt metadata is not that
likely: the core would only handle the metadata that is already in the
parasite.  Except for corrupt XCF files (unlikely to come from a camera!),
the only way for the metadata to be put in the parasite is via the editor
(the user enters some data) or via the file plug-ins, which would be based
on the same libgimpmetadata library.  So even if there is a bug that could
crash the parser despite the safeguards in the code, that bug would affect
the file plug-ins before they have a chance to store the metadata in the
parasite and hand it over to the core.  Of course there is always Murphy's

> I understand your concerns. But since you said that we aren't going to
> have this code in the core for 2.4, what's the point of preparing that
> move now? If we have a little more time, we can find other ways to avoid
> the concurrency problem. The core could for example signal image changes
> to plug-ins that ask for such notifications. That would be useful for a
> lot of plug-ins and we could add such functionality right after 2.4.

I agree that such a notification feature would be useful for a lot of
plug-ins.  However, my goal is really to have the metadata in the core,
handled like any other information about the image: resolution, colorspace,
image comment, etc.  With the metadata handling in the core, I would like
to have some parts visible in the preferences: the "Default New Image" tab
has an expander with "Advanced Options".  Instead of the generic "Comment"
field, there would be separate options to specify "Author" and "Copyright"
and I could also add an option for selecting a default license.  Another
point of integration in the core would be a dockable dialog similar to the
"Pointer Information" dialog (or maybe to the currently non-dockable
Image->Image Properties dialog) that displays some of the most important
parts of the metadata for the active image.  This could be configurable:
some users may be interested in the date and location, while others are
more interested in the dc:description or dc:creator.  The core could also
notify the user if there is an explicit copyright on an image (some other
programs warn you if you attempt to modify or save an image that has a
copyright, but I would rather go for a non-intrusive notification).

You can probably argue that some of these features could also be
implemented outside the core, but then they would not be very well
integrated.  For example, it would be difficult to select a default
license for all new images if this is not done in the main preferences.

Gimp-developer mailing list

Reply via email to