Modernizing dupeGuru: the data modulesVirgil Dupras
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
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
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
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
(one for each edition) in
core_* packages. From there, a mechanism to host
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
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
core.app merge, a refactoring of the
qt.base.app is necessary.
I want to do this before the next feature release.