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.
 
### Inside "src" folder
There is nothing in the directory structure that clearly shows that this is an awesome SVG application.

1. 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"
 
2. Is "ui" a gui or also command line?

Both.
 
For me it sounds like those should probably be separated "ui::gtkgui" and "ui::commandline"
 

3. "Manipulation", it is impossible to understand what it is being manipulated with just a one-layer folder structure.

True. Each folder will have a README to explain what is in the folder. I can't think of a better name.

4. "Object", it is impossible to understand what an "object" is in this application without reading the code.

This is the name we've always used. I can't think of a better one. It's explained in the README.

The README solution sounds like a good trade off at this point in time.
 

5. "extensions", what is the difference between a functionality implemented as an extension and right away in the core of the application? In my opinion the word "extension" is to vague.

I agree with this. Will bring it up for discussion today.

6.  "libraries" folder, 3rd party libraries included as source code, this is good idea but shouldn't 3rd party lib folder be next to "src" not inside it?

I'll bring this up for discussion.

I did a quick example on the Inkscape wiki [3]. This is just an idea and I'm not sure how feasible it is for Inkscape as I don't understand the codebase that good. The main idea is that business logic, that is SVG functionality goes into "core". The core parts knows nothing about the entrypoints (gui, command line, http API) nor data providers (file system, in-memory data storage).


-- 
Christoffer Holmstedt