Model images in FW-Lite

[myieye]

Probably approximately just this:

class Sense
{
   List<Image> Images // probably jsonb? Like Complex-forms, semantic domains etc. the Image/Picture instances are owned by the sense
}

record Image // counterpart of CmImage from LibLcm
{
   Guid Id // LibLcm has Guids on images and the MediaUri is not necessarily unique even in the scope of a single sense, so we need this
   MediaUri Id // contains Guid for looking up the file on the media-server
   MultiString Caption
   // anything else?
}

We are already not persisting/syncing audio-file metadata (file size, image size, license) to a DB table in Lexbox, so we can probably ignore that for the time being for images as well.

[rmunn]

FieldWorks puts images in Sense fields: you can click the dropdown next to a Sense and choose "Insert Picture", and it pops up a picture-selection dialog (which lets you choose a picture, crop it, and add metadata like copyright and license info).

For starters, we need to model the picture field in Senses in a way that reflects the liblcm data model, and be able to handle the metadata fields for license, copyright, and so on — which are quite important: in some parts of the world, governments scrutinize this stuff very closely. (Same issues apply to licensing for audio files as well). So it's important that we preserve any licensing info that FieldWorks has, and also make it easy for FW Lite users to provide the same data, in a way that's at least as easy as what FieldWorks does. (If we can find a way to make it easier, then we should of course do so).

[rmunn]

FW has some fields in CmPicture (LayoutPos, ScaleFactor, LocationRangeType, LocationMin, and LocationMax) that appear to be unused in dictionaries; see #2232 (comment) for full analysis. We can probably omit them from the FW Lite model, and set them to 0 (or the enum equivalent of 0) when FW Lite creates a new CmPicture object. They appear to be unused in dictionaries (they are a holdover from when FW was going to incorporate a translation editor), so they are probably safe to ignore in FW Lite.

[rmunn]

The LexSense object in liblcm has a m_PicturesOS field (and corresponding PicturesOS property), which contains only the pictures owned directly by that sense. It also has a Pictures property (no OS suffix), which contains the pictures owned by that sense and all its subsenses (in that order, directly-owned pictures first). Implementation of that Pictures property is:

return PicturesOS.Concat(from LexSense sense in SensesOS from picture in sense.Pictures select picture);

So if subsenses themselves have sub-subsenses, the order will be "sense 1 pictures, sense 1.1 pictures, sense 1.1.1 pictures, sense 1.2 pictures, sense 1.2.1 pictures", and so on.

[rmunn]

That design sketch in the OP is probably going to be enough. The liblcm CmPicture class seems to want you to use its UpdatePicture method for either creating or changing pictures. That takes a filename (string), a caption (ITsString, not a MultiString), a folder (string, which is expected to be CmFolderTags.LocalPictures), and an integer writing system ID for the caption.

[rmunn]

Started designing this. Design choices I've made so far:

• Went with Picture (rather than Image) to align with the CmPicture name in liblcm.
• Went with having a Guid (and the rest of IObjectWithId) so that we can look up pictures by Guid when loading liblcm data. May find that this is unnecessary later, in which case I'll go with the simpler "store as jsonb" route that the initial design sketch suggested.