On Thu, 22 Jun 2006 08:10:19 +0200, Sven Neumann <sven@xxxxxxxx> 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 law... > 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. -Raphaël _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
