Modernizing dupeGuru: the data modules



No software design is perfect, and dupeGuru certainly ain't no exception. In fact, with refactoring being of much importance in my development style, I much prefer imperfect ad-hoc designs than imperfect "Grand Designs" which are much harder to refactor. Anyway, enough rambling. My itch of the day: the data modules in core and core_* packages.

These data modules contain code that is specific to each edition of dupeGuru, but that is common to all platforms: Columns and the data that is displayed in their respective cells as well as sorting behavior. That data module is imported by the GUI layer and passed as an argument to core.app. The whole thing works without too many problems, it's just that this code is at the wrong place and it gets annoying after a while. For example, column information should be in a subclass of core.gui.result_table, not in a data module.

With the new prioritization feature, I had to add a new function to the data module to return a list of criteria categories supported by each edition of dupeGuru. Yet, another function that doesn't belong there.

The obvious first step to do is to take all that stuff in data and put it in core.app subclasses (one for each edition) in core_* packages. From there, a mechanism to host result_table and priority_dialog subclasses could eventually be devised (no rush, a refactoring that does too much at once is a buggy refactoring).

Well, the problem is that the Qt layer's app class (in qt.base.app) subclasses the app class in core.app instead of holding a reference to it. This means that making edition-specific app subclass would create "parallel" subclasses, making it necessary to have some complex multiple inheritance, and doing that is asking for troubles.

So before doing that data/core.app merge, a refactoring of the qt.base.app is necessary.

I want to do this before the next feature release.