HCMC Blogs

Meeting with SA, ML and JL regarding a possible bibliographic database project. Stewart is planning to blog the details...

Today I reimplemented the tree view based on a DomModel taken from the SimpleDomModel example, and hooked that up to a QTreeView, replacing the QTreeWidget. This works great. The next phase is to filter that model into QListView, which I'm assured by someone on one of the QT forums can be done by subclassing QSortFilterProxyModel, and implementing filterRows and filterColumns. This I've now done, but the results are not encouraging: nothing shows up in my list. At this point, I'm not sure whether this is because the filter method code is flawed, so it's never accepting a row, or because when a row is rejected, its children are never tested, which means that you can't get down as far as a list of elements which have @xml:ids; or even because child rows are never tested at all, so only the top level nodes get as far as the filter. At the moment, I'm tending towards the last option, because even when I make my function return true in all cases, only the top level nodes show up.

I'm sure I'm on the right track here, but it's going to take some more work...

Decision made.

Worked with SA to create a comparison matrix for the meeting this afternoon.

Trying to figure out model/view complexities for IMT.

Changed the list of xml:ids so that it's implemented with a true model based on QStringListModel, proxied through a QSortFilterProxyModel, enabling regular expression filtering. This is based on an example in Blanchette and Summerfield (pp. 250ff). The next step would be to replace the QTreeWidget with a QTreeView and build a similar model there, but I'm not quite sure how I would keep the two models in sync; the thing I don't yet understand is how, or even whether, you can have two distinct models which derive from the same underlying model, or one model which is simultaneously a QStringListModel and a custom tree model.

I've enhanced the map gallery so that something slightly more attractive than a tooltip shows the details of the maps when you mouse over them. I've also added some drop-shadows, so the maps look more like other documents on the site. I think there may be some more cosmetic changes in future, but I think this will do for now.

I'm finding that the garish colour scheme of the maps-for-free tiles are a bit much for this application. Points, in any colour combination tend to get lost in the intense range. So, I've been fiddling with some setting in the GIMP, and I have a more subdued scheme to try out.
I need a script (imagemagick?) that will adjust the tiles thusly:
In the GIMP > Colours > Hue-Saturation dialog, I made the following adjustments:
Master: sat=-25, hue=15
R: sat=-45, light=20, hue=1-
Y: sat=-35, light=45
G: sat=-50(-80 light=18)
C: sat=-45 (overlap=40)
B: sat=25, light=-10
and I think it looks better at least.

Now, I need to script something that will troll through all 17 million images and adjust each one with these settings...

PAB reported that an extraneous calendar event was showing up on the Beck site when it didn't have any connection with the Beck Trust. I discovered that the calendar parsing code was simply looking for the word "Beck" in any calendar announcements, and that one contained "Discussants: Detlef Beck". I fixed the code so that it now looks for "Beck Trust" (which PAB will now have to make sure is included in all announcements).

I'm doing the preliminary planning and reading for a document model which will provide three views on the underlying code in the TEI file:

• A read-only syntax-highlighted text view (MdhXmlEditor).
• A tree view (QTreeView).
• A string list view (QListView).

The last two will have access to right-click options to add new items, edit existing items, and presumably delete. The basic approach that seems best is outlined in this example project, which builds a tree view from a DOM model of a document. However, this example project has some key limitations that I need to work around. First of all, it's a read-only model, which means that it doesn't have to worry about updating itself when changes are made to the underlying document. Secondly, it only provides a single view of the data in a QTreeView; I need to bind the same model simultaneously to at least two different views (and probably three, if #1 above is integrated as a "view" in the model-view architecture rather than being handled in a more ad-hoc way). I now need to find more examples of multiple views, and I need to get a real handle on how views are updated when a model changes. I may even need a third view, which shows only one item and allows it to be edited; that would make things even more complicated. Perhaps the read-only view shouldn't be read-only; it should just show the selected item, and no surrounding code, and it might be the whole editing interface. You could see the whole document by clicking on the root element in the tree view.

This stuff is hard -- for me, anyway -- but it's definitely the correct approach.