The Image Markup Tool version 188.8.131.52 has been released. This is a minor update with one small improvement, documented on the web site.
HB wrote to ask for a keystroke shortcut for "New (with same categories)", so I've added one. I also updated the version info and date on the Help.
PC found a bug in the interface translation code while translating the Markin program. Fixed the bug in Markin at home, then migrated the fix to IMT and did a new release. I took the opportunity to update the way the site handles version numbers and download links, as I've been doing for the Markin site, to centralize all references to versions, making new releases easier and more reliable.
Version 184.108.40.206 of the Image Markup Tool has now been released. It's available from the IMT website. This version includes a new feature for automatically checking for updates, a small bugfix, and some updates to documentation.
Taking more code from the Markin program, I've implemented the update checking routines into the application. I also customized a Nuvola icon to use for the Update action, generated bitmaps for it, and rebuilt the icon dll to include it. Then I coded the PHP page which parses the version info passed to it, and shows customized update information (only the updates done subsequent to the user's version number).
"Check for updates" now seems to be complete and working, so the next stage is to update the documentation -- I think I could mention the update checking on the "Installing and Unistalling" page, and I'll also need to update the version info on the Help file itself. Then I can document the new feature on the updates page itself, build an installer, and do a new release. Should be done by lunchtime tomorrow.
Added the key update code to TFormStateSaver, and got to the point of compiling it, but haven't yet been able to test it. I'll begin testing in the Markin program at home, then bring any fixes back in. The logic is slightly complicated, but I think it's all functional.
One thing lacking from the application is a regular update-prompt system which would help users migrate to new versions (without pushing them too hard). We've been developing a strategy for this as part of the Markin program, and I think a similar system could work for IMT and Transformer. These are the details of the plan worked out so far:
I. Checking for updates:
- App keeps a record of the last time it checked for an update for this user, in the user's Application Data folder.
- On startup, it checks that info. If the last check was more than a month ago, it asks the user whether it should check.
- If the user says OK, the check is made.
II. Mechanism for checking.
- The update URL is stored in the application itself; it points to a PHP page.
- When a check is invoked, the app calls the update URL, appending a GET parameter which includes the current version number:
[site].../update.php?userVersion=220.127.116.11It passes the URL off to the browser, which makes contact with the server.
- The update script runs on the server, and creates a customized page which shows the user's current version, the current release version, and a list of all the changes between the two; it also has a link to the recommended download. The page is created by PHP, which simply customizes existing XHTML by including or not including relevant rows in the bug/update table. The page is maintained by me, like HotPot and IMT update pages. When no version parameter is passed to the page, the whole update report table is shown.
- The user can choose to download, or, even if they're not an administrator on the machine, they can print the page with all the update info and pass it to the administrator, who can decide if an update should be done.
There's more detail in the Markin development notes. The next decision is how this object should be coded. The options are:
- A completely distinct object. This would be a bit inefficient, because the object would have to do parsing of version info, and we already have a
TAppVersionInfoobject to do this.
- A new feature of
TAppVersionInfo. This would require that
TAppVersionInfobe able to determine the application data folder, which would make it dependent (currently) on the rather bloated
GenFunctions.paslibrary. Alternatively, the
AppDataFolderfunction content could be abstracted from there and used directly in
TAppVersionInfo. On the negative side again, this would require that
TAppVersionInfobe able to save and load a file, which is more bloat for an object that's used several times in some of my apps.
- A new feature of
TFormStateSaveris already quite large and complicated; it has its own TAppVersionInfo instance, and is already saving and loading files from the application data folder anyway. All it would need would be a new item to save in the file (the date of the last check), code to read and write it, a field for the URL of the update page, and a function that would construct and call the URL. The GUI aspects could be controlled from the main application, so GUI strings are not required in
TFormStateSaver. There would be a function to determine if it's time to check (
isTimeToCheckForUpdate), one to get the URL (getUpdateURL), and a property to record that the user was prompted (updatePrompted), which, when set to true, would cause the object to store the current date.
Based on this discussion with myself, I think the last option is the best, and I'll start implementing it. The PHP on the server side is a different problem, but not too complicated either, I don't think.
With Delphi 2009 due to arrive soon, it's time to start planning the feature set and data structures for IMT 2.0. The overall plan is to make the application much more flexible; it needs to handle documents with multiple images, and to allow much freedom in associating any "annotation" div and any zone on any image. These are my initial ideas:
- An IMT document is rooted on
<TEI>, and contains:
<facsimile>element, which contains multiple
<surface>elements, with each
<zone>elements, and each
<surface>element containing one
<graphic>element linking to an image file
<text>element which contains a single
<div>, which in turn contains a
<div>for each annotation or transcription block. Each of these
<div>s is associated (through
@corresp) with one or more of the
- Each image/
<surface>is presented as a separate tab in the GUI, so you can move from image to image by clicking on the tabs.
- The annotations/transcriptions (we need a new word for this -- "zone-div"?) are presented in the current format, as a scrolling list, which can be filtered by category.
- Any zone-div can be associated with one or more
<zone>elements, on one or more
<surface>s. In other words, you can create a single zone-div which links to (say) three
<zone>s on three different
<surface>s. This enables efficient re-use of zone-div data, where features on different
<surface>s need the same explanatory information. This breaks the current one-to-one correspondence between an annotation
<zone>, in IMT 1.8.
- Associations between
<zone>s and zone-divs will be handled by giving each zone-div object a list in which to store links to
<zone>elements (as opposed to the single pointer that currently exists). The zone-div parent list will have methods for finding associations by interrogating its children, in order to discover which zone-divs link to any given
<zone>, or which
<zone>elements are linked from any given zone-div.
- The above change will pose problems for the user interface. At present, when you click on a
<zone>on the image, the associated annotation can be highlighted and displayed in the annotation window, because there is no ambiguity -- only one associated annotation exists. The same is true in reverse: when you click on an annotation in the annotation window, the associated
<zone>can be highlighted. In the new system, not only can one zone-div be associated with more than one
<zone>, but one
<zone>can also be associated with more than one zone-div, so it's much more complicated to provide an efficient and helpful interface. This might be handled in the following way:
- If you click on a zone on the image, and only one zone-div is associated with it, that zone-div will immediately be selected in the annotation window (retaining the simplicity of the current interface where the data structure allows it).
- Similarly, if you click on a zone-div (annotation) in the annotation window, and that zone-div is associated with only one zone on only one surface, then that surface (image) will be shown, and that zone highlighted.
- However, if you click on a
<zone>with which multiple zone-divs are associated, a popup menu will appear, listing those zone-divs (by their tag-stripped titles), so that you can select one of them.
- Similarly, if you select a zone-div in the annotation window which is associated with multiple
<zone>elements, a popup menu will allow you to select which of them should be highlighted (listing them by image filename and coordinates).
- This takes care of navigating existing data, but a much more complicate problem arises with regard to creating such links in the first place. Since zone-divs and
<zone>s are now only loosely coupled, we need to consider how a user might want or need to go about adding new
<zone>s and zone-divs. These are some of the operations the GUI will have to enable (while, I hope, remaining simple and intuitive):
- Adding a new
<zone>and zone-div together, as currently; both are created at the same time, and are automatically linked. This should probably be the default behaviour, since most people will probably create most of their markup in this way.
- Adding a new
<zone>, but associating it with one or more existing zone-divs. Perhaps this would be
Control + Add Zone, and would pop up a scrolling checkbox list of zone-divs in a modal dialog; if you select one or more and press OK, the
<zone>is added and linked, but if not, the
<zone>creation is aborted. When a
<zone>is successfully created, the first zone-div of those associated with it would be selected.
- Adding a new zone-div, but associating it with an existing
<zone>. This might best be done using a right-click on the
<zone>itself, and/or a right-click on the zone-div editing area. Another possibility is to have a drop-down list in the zone-div editing area, which has an entry for each associated
<zone>, along with buttons to add and delete associations. Selecting an item in this list would foreground the
- Adding an association between an existing
<zone>and an existing zone-div. This should probably also be done using a right-click on the
<zone>element, and should also be available in the zone-div editing area.
- Deleting an association between a
<zone>and a zone-div. This could easily be done in the zone-div editing area, but it would be harder to do it through a right-click menu on the
<zone>element, so perhaps this should be limited to the zone-div editing area.
- Deleting a
<zone>element. This would require pruning of all associations between zone-divs and the deleted
<zone>(and might result in orphan zone-divs -- see below). The operation should also probably ask the user whether any zone-div which is ONLY associated with the
<zone>which is to be deleted should also be deleted.
- Deleting a zone-div. This is simpler than the above, because the associations are all stored in the zone-div object; but as above, it might result in orphan
<zone>elements. This operation should also ask the user whether to delete any
<zone>elements which are only associated with this zone-div.
- Handling of orphans. If you can delete associations, then you can easily delete all associations between zone-divs and
<zone>s, so any given
<zone>may be left without any associated
<div>, and vice versa. This is not a problem at all, in fact, but it may be something users should be warned about at the point where they create the orphan(s). The software as a whole needs to handle orphans of both kinds without problems.
- Question: would it ever be necessary to allow the addition of a zone-div without an associated
<zone>? It would be possible to create such a thing by adding a normal pair, then deleting the
<zone>, but do we need to allow for direct creation of unassociated zone-divs?
- Adding a new
One more thing we need to think about is the question of metadata, both at the document level and at the level of
<surface>. Where there are multiple images, each will perhaps require distinguishing data at the level of the surface tag, and we'll need to provide a good interface for that. At the same time, as the overall complexity of the document increases, people will probably want to add more complex information in the header. I don't know how we could make that easier, without actually creating an XML editor for it, so perhaps we can leave that as it is.
The most difficult aspect of the rewrite will be retaining, as far as possible, the simplicity of the current interface, so that existing users have little trouble adjusting, and are able to continue to work on simple, single-image documents in the way they're used to working, while making all the new options easy to access.
Finally, validation: do we want to think about that? It would be extremely hard to implement, especially with RNG schemas, but if it could be done, and errors could be retrieved and shown correctly in the GUI, it would be quite useful.
PC reported that the About box was showing two versions on Win98 and WinME, the old 18.104.22.168 version and the new 22.214.171.124. On investigation, I found the application options "Product version" setting was set to the old version; however, I don't use this information when creating the About box, so I suspect that Win9x is incorrectly reading the product version info from the executable. Since the problem doesn't show up on Win2000+, and we don't officially support Win9x, I've just made a silent change of the Product Version to "1.8" (which is what it should be, rather than the full dotted version, which is stored in a different place). Waiting to see if that makes a difference. What seems to be happening is this:
In my app, I output a string between the copyright info and the link, based on the "Comments" field in the executable version info. In IMT, there is no comments field, so there's nothing to output; on Win2000 and above, nothing appears there at all (in fact there isn't even an empty line). However, on Win9x, it seems that if there's no Comments field, Windows just reads the Product Version field instead. I think that's where the information is coming from.
PC pointed out that the licence text file was showing the wrong version number, so I updated that and rebuilt the installer.