Image Markup Tool blog

ImtLink, ImtLinkGrp, and ImtLinkGrpSet all have some properties and methods in common, so I've now derived them from an abstract base class called ImtElement.

Built most of the ImtLinkGrpSet class, which manages a set of ImtLinkGrp objects. This involved making some modifications to ImtLinkGrp, so that it is aware of the possible existence of its parent object and is able to add and delete itself in the parent where appropriate.

Lots of work still to do on this class, much of which will require that I do more detailed planning on how exactly it will interact with the ImtDoc object. I need to thoroughly test the readFromDomElement() function, and add functions such as getLinksForZone(), getLinksForTextEl(), and getters and setters for all the relevant members of ImtLinkGrp and ImtLink.

It makes more sense to have a class which handles a <linkGrp> element to be called ImtLinkGrp, so I've refactored the code and changed the file names. I've also made the namespace handling more sophisticated, so if the ImtLink or ImtLinkGrp classes have an assigned namespace, then they use createElementNS() to write themselves, but if not, they use createElement(). Finally, I've made ImtLink more sophisticated in its handling of linkType and nsUri properties: if it has a parent ImtLinkGrp, then it uses the properties from that, but if not it uses its own.

This class handles a <linkGrp> and its component <link> elements. It's now functioning well and tested; it can read and write itself from a DOM element successfully, and provide a list of links with a particular target <zone>, or target <text> element. I'm gradually getting a handle on how best to do all these things.

The issue of XML namespaces remains. I had assumed that if I set all elements to the same namespace explicitly, and then output the document as a text string, I would see a sensible serialization whereby child elements with the same xmlns as their parent would not have an explicit xmlns attribute. Instead, I see the xmlns attribute (I know it's not really an attribute, but there's no other practical word) on every single element.

So I'm now figuring that what I actually need to do is to make all my XML handling namespace-free, so that the root namespace for the document is set once, and all the elements that don't need an explicit namespace don't get one. That doesn't mean they have an empty one -- that just results in an empty xmlns attribute. They need to be created with createElement() rather than createElementNS().

Namespace prefixes can be handled with createElement("myNs:myElement") and setAttribute("myNs:myAtt" "myVal"), which is what I think I'll do with (for instance) @xml:id. So I'll have to refactor my <linkGrp> and <link> code to remove the namespace handling. Annoying, but things will be simpler. The issue of how to handle possible embedded SVG or other namespaces is still not clear to me.

Completed the ImtLink class, and documented it and the ImtConsts file using Doxygen. I'm building everything to be namespace-aware by default, which I think is the best approach. The QDom functionality is working well for me so far. I've now started work on the ImtLinkSet class, which is going to use a QSet to manage a group of links, and provide rapid lookup and i/o functionality for a TEI <linkGrp>.

I like the idea of using TEI <link> elements to manage the relationships between <zone>s and <text> elements, but there's one gotcha: they can have as many target ids as they want, and it's not clear what that means. I'm going to think more carefully about this. Using <link> and <linkGrp> gives me much more flexibility in categorizing and grouping links, and that's important; however, I think users will probably also want the option to output the other linking mechanisms (@corresp and @facs), and the question then is whether I give them both (meaning that they might get out of sync), and whether I actually try to read the other linking types, or just stick with my clean and separate <linkGrp>s.

Created a constants class for XML regexps for name checking etc, and began work on a link modelling class, ImtLink. Slow but steady progress.

Working through one of the example applications in Blanchette and Summerfield to get a grounding in QGraphicsScene etc, before I plan the class hierarchy for IMT 2. So far so good...

Got my bits of the proposal written and sent them off to MT.

Managed to integrate my code with MJ's zone handling code, and got zones appearing on top of the test image. Created a sample popup menu to illustrate how linking would work, and then discovered that in order to take a screenshot of the app, I had to cause it to lose focus, which caused the popup menu to disappear. Ridiculous problem. Something in QT seems to be disabling the OS shortcut for screenshots.

So I had to build screenshotting into the app itself -- not too hard -- and trigger it with the onAboutToHide() event of the popup menu, so that it would trigger as I clicked on a menu item. This worked pretty well, and I have my screenshots now. Learned quite a bit in the process, though.

I need to rewrite MJ's code significantly, to hive off the controller component and to convert the idea of annotations to the more accurate concept of zones. Annotations are not part of the new structure, in the old sense; although it will be possible to create a div on the fly in the IMT when creating a zone, the more conventional path will be to link to an existing element through its xml:id; zones themselves may keep lists of pointers to the elements they're linked to, or those links may simply be handled externally by a link manager. I think I like the latter option best.

Took my first shot at trying to integrate MJ's polygon zone controls with my mock-up application, and I'm finding that the only practical approach is going to be subclassing MJ's class to add the handler which draws the pixmap in the background. I think as long as I draw the pixmap first, it should work OK, but I don't want to waste too much time on it, because it's not actually going to be the real approach we take to writing this bit of the app. Nevertheless I keep learning new stuff as I go.