[Charlie, please subscribe to the 'freetype-devel' mailing list.] > Therefore, I'm planning to bring forward the next phase (Part 2 in > the timeline), which is refactoring the current base.
OK. > * You're creating a lot of "extra" widgets by inheriting the > original widgets in Qt. This creates a lot of tiny source files. > Should we move them into one single file? I don't know. What would be the advantage of having everything in a single file? > * The "Engine" class is highly coupled with the main GUI, accessing > a lot of fields in the main GUI. Maybe I should decouple this > and try to sort out the data flow between the GUI and the engine. Sounds good. > * There's a filesystem watcher to monitor and reload font files on > the disk - I hope for further explanation for this. What's its > purpose? The original idea was that you have three programs open: * A text editor to modify the control file needed for `ttfautohintGUI`. * `ttfautohintGUI`, which is a GUI front-end to the 'ttfautohint' library. (https://freetype.org/ttfautohint) * `ftinspect`, looking at the output file of `ttfautohintGUI`. If you finish editing the control file, you press a button in `ttfautohintGUI` to regenerate the output font. `ftinspect` should notice the update file and automatically update its display. This is very similar to the editing cycle of, say, a LaTeX input file: The PDF viewer automatically refreshes the display of the PDF output file after `pdflatex` has been executed. [BTW, the Acroread program on Windows can't do that – it takes access control of the PDF file and doesn't allow writing to it while being open. For this reason you should use another PDF viewer on Windows for such cycling with pdflatex.] > * Some "override" modifiers are missing. Well, I didn't use C++11 when starting with coding :-) Please be careful to *not* use features more recent than C++11! > * I learned the code style (so different from mine :) ) Well, the coding style of `ftinspect` is *far* more standard than the FreeType library itself :-) Please note that we (roughly) use the 'GNU style for ChangeLog files' for writing commit messages. You are normally on the safe side if you imitate the commit message format I use for my commits. Werner
