On Thu, Mar 29, 2018 at 07:30:13PM +0200, Christoffer Holmstedt wrote:
2018-03-29 13:35 GMT+02:00 Tavmjong Bah <tavmjong@...8...>:
Hi Christoffer,
Thanks for your input!
On Thu, 2018-03-29 at 12:14 +0200, Christoffer Holmstedt wrote:
It has been a year or two since I touched the Inkscape codebase but have recently been introduced to the idea of a "Screaming architecture by Robert C. Martin/Uncle Bob" [1, 2] in other development efforts and started to practice it. It might not be doable right now for Inkscape but goes along the idea that we want WITH_UI flag in the build system (be able to build headless inkscape that is). Also it should make it easier for new developers to understand the codebase just by looking at the file/directory structure.
Interesting ideas, which I mostly agree with. The problem, I think, is that truly descriptive names are going to be too long.
Yea, that is for sure my experience as well. It is a trade off between longer more descriptive names or putting the information in documentation somehow.
It's a good point though that terms like 'Object' and 'Item' and so on can have project-specific contextualized meaning that will not be obvious to first-time readers. A top level glossary explaining the jargon might be a way to address that need without having to come up with overly long names.
### Inside "src" folder There is nothing in the directory structure that clearly shows that this is an awesome SVG application.
- What is the difference between "display" and "ui"?
display is for drawing the SVG and controls on the canvas. Perhaps is should be renamed to 'render' or 'canvas'.
'render' seems good if it includes both the SVG and the controls. 'canvas'
implies only the SVG parts for me. In the end maybe that is what we want separated "render::canvas" and "render::controls"
We just discussed this terminology a bit further at the hackfest, and looked at some historical architectural documents.
- Is "ui" a gui or also command line?
Both.
For me it sounds like those should probably be separated "ui::gtkgui" and "ui::commandline"
Long term, I think we need to plan for a diversity of interfaces, including not only our current GUI and current command line, but perhaps new kinds of interfaces built atop a GAction-based API.
Since presently we don't have specific items to go under commandline, it could be left out for now.
Bryce