Devhelp development notes
Refactorings - misc notes
Variable/function name "keywords" actually contains all DhLinks of a book, not only keywords. So it's not a great name, a better name is for example all_links, like already done in dh-parser.c.
DhWindow: move code outside of new(), move it in init() for example.
DhWindow: factor out some classes, to avoid g_object_set_data().
DhWindow: copy_cb() doesn't seem at the right place.
Improve language management with DhLanguage, see this commit.
When storing DhLinks in GtkTreeModel, do not store them as simple pointers, take advantage of ref counting, to make the code safer in case a DhLink is freed but still stored in a GtkTreeModel.
- Parser: is the Devhelp index file format documented?
- Parser: write basic unit test.
Refactor the code to be more object-oriented instead of being procedural: currently there are some dumb data classes with only getters and setters, and at other places there are really big functions with for example 8 indentation levels. With an object-oriented style, a function delegates most of its work to other classes, resulting to smaller functions and to keep related data and behavior in one place. Classes containing big functions: DhKeywordModel (work has already started to have smaller functions). Are there other classes?
- See also FIXME/TODO/XXX comments in the code.