life: after the “exam craze” (two in five days) that took the best part of the week, me and Marta have resumed cleaning up the house. Since I have moved in with her, there has been so much work to do that we haven’t really felt the whole “moving in” part; but I assume it will get us, sooner or later. Next week we’re going to visit my parents, and get some of my books/DVDs/whatever that I left behind.
hacking: after moving the RecentManager to new new BookmarkFile parser/writer object, I resumed working on the actual separation of the recently used resources viewer widgets (implementing the RecentChooser interface) and the list controller (the RecentManager object). Last week I removed every trace of sorting and limit handling code involving the manager object from the widgets, and recoded them directely into the widgets themselves. Thus, it’s now possible to have a single manager instance and multiple viewers bound to it, instead of creating a manager object per widget:
Two widgets, one manager
Sorting, filtering and the list limit property are still present in the RecentManager object; this way you could have a custom sorting and filtering functions set into a manager, and then multiple views attached to it.
Separation was a job the the current EggRecentModel/EggRecentView objects didn’t handle well enough; basically, you could feed you own model to a EggRecentViewGtk widget, but every other widget using the same model would display the same data, with the same sorting, filtering and list size. This behaviour doesn’t really match the MVC paradigm; for instance, using the same TreeModel you could set up many TreeView widgets, each of them showing only some part of the data stored in the model. Filtering, sorting and size are handled by the TreeView code, not by the model.
The same should happen with the recently used resources list; also because this could lead to the creation of a default singleton instance of the manager object, in order to reduce memory and locking issues due to the on disk storage.