[KPhotoAlbum] Associating multiple tags with one area?

[Hugues Ross]

> So, without changing the behavior, you can't use the second menu to add 
> additional tags. For each tag, the user would e. g. have to be able to choose 
> between "Replace tag" and "Add tag", with all candidates visible to all areas.
>
> Perhaps, there's a nice way to do it, but we do have to keep the GUI usable 
> and clear (it's already quite a lot of work to mess with the area stuff ;-). 
> Perhaps, a third menu could be added like "Add additional tags" with a list of 
> all tags that are selected but not associated with the area the context menu 
> is triggered on. Along with a third menu for removing tags.
I hadn't considered tag replacing, and I it's definitely important to keep that.
I can't think of any way to solve this issue without making it get messy,
except perhaps having some option of toggling between add+replace, and add+remove.
It still seems a bit much, so you're probably right. I noticed that there's some
sort of extension/plugin mechanism. Would that be capable of changing the UI to
a great enough degree to implement this?

> But you also have to think about how to put it in the database, how to get it 
> out and how to handle the loaded data (area moving, area removing, tag 
> renaming ...). In the database, we have a tag->area mapping. In the annotation 
> dialog, we have the opposite: the tag data is stored inside the area classes 
> and translated to the actual data when changing pictures or applying the 
> changes.
> 
> I think we would have to change the way the data is stored in the data 
> objects, as all this is currently intended to be used with one tag per area. 
> After all, I'm not sure if we could add this without problems ...
In the database, I don't think anything would need to change. It shouldn't be
too hard to detect if some tags have the exact same position and dimensions,
after all. The dialog might make things harder, though.

Thinking about this, maybe there could be a button to 'stack' areas together?
'Stacked' areas could have some link or identifier that could be generated
simply by detecting perfect overlap, which should be extremely rare in existing
circumstances. With some kind of identifier or link, making edits affect
all areas in a stack shouldn't be too difficult. Once in a stack(Which
could be known by checking for this theoretical 'link'), the menu could change
to add new tags to the set, or remove existing ones from it.

It's still not a perfect solution, but I think this would reduce the number
of changes necessary to way things are structured now.

I've got a copy of the git repo now, so I'll be taking a look at the relevant code
sometime later. Hopefully I'll be able to at least try some of these, and see for
sure if they would actually work.