good proposal overall! I'd make some changes & remarks though (I think there are a bit too many folders): 2geom -> libraries/2geom extension -> extensions io -> extensions/io manipulation/knots -> ui/knot-manipulation manipulation/misc -> manipulation/ manipulation/chemistry -> manipulation/ manipulation/selection -> manipulation/ packaging -> ../packaging (same as now) - What's the point of display/control ? - *nothing* UI-related out of ui/ - *nothing* non-needing-absolutely-UI in ui/ (so ui/widget/actions -> manipulation/actions (or "verbs", but I'd prefer "actions" )) ( the goal will eventually be to put in the root cmakelists a "if(WITH_UI)include_directories(ui)endif()" ) - do we need ui/menu/ while we should have a generic menu generator from share/ui/menus/*.xml ? Same for toolbars & dialogs, if we have GActions and xml or glade files, we should not have much code to put in those folders (?) (Or maybe we can start with that and silmplify once there is less code) -- Mc inkscape ├── packaging/* ├── po/* ├── share/* └── src ├── extensions │   ├── dbus │   ├── internal │   ├── io │   └── plugins ├── libraries │   ├── 2geom │   ├── adaptagrams │   └── libnrtype ├── manipulation │   ├── actions │   ├── live-effects │   └── snapping ├── objects │ ├── containers │ ├── filters │   └── shapes ├── rendering │   └── filters ├── svg ├── ui │   ├── cache │ ├── dialog │ ├── knot-manipulation │   ├── tools │   ├── view │   └── widget ├── util(this_folder_needs_cleaning_btw) └── xml

On Thu, 2018-03-29 at 00:13 +0200, Eduard Braun wrote: Definitely not a library... The files contain code that really belongs in a lot of different places but splitting it up would be painful. And is handy to have all the font/text stuff in one place.

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. ### 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"? 2. Is "ui" a gui or also command line? 3. "Manipulation", it is impossible to understand what it is being manipulated with just a one-layer folder structure. 4. "Object", it is impossible to understand what an "object" is in this application without reading the code. 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. 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 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). [1] https://8thlight.com/blog/uncle-bob/2011/09/30/Screaming-Architecture.html [2] https://www.slideshare.net/mattiabattiston/real-life-clean-architecture-6... - One example on how "screaming architecture" could be implemented. [3] http://wiki.inkscape.org/wiki/index.php/Source_Directory_Structure_Scream... 2018-03-29 3:41 GMT+02:00 Martin Owens <doctormo@...400...>: -- Christoffer Holmstedt

2018-03-29 13:35 GMT+02:00 Tavmjong Bah <tavmjong@...8...>: 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. implies only the SVG parts for me. In the end maybe that is what we want separated "render::canvas" and "render::controls" For me it sounds like those should probably be separated "ui::gtkgui" and "ui::commandline" The README solution sounds like a good trade off at this point in time. -- Christoffer Holmstedt

On Wed, 2018-03-28 at 21:28 +0200, Marc Jeanmougin wrote: We plan on moving this out of Inkscape. This is the current name. 'extensions' might be better but... See doctormo's reply. Will have to look at what is actually inside. Could evolve to this once things are cleaned up. Everyone agrees, mistake on my part. There are quite a few files for drawing controls (nodes, control lines) that have nothing to do with rendering SVG. That is the goal... but may take a few iterations especially with text. We plan on migrating verbs to GActions but it will take some time. Alex has a three step plan. He's well on the way to finishing the first step. But it will take awhile.

On 03/28/2018 01:31 PM, Tavmjong Bah wrote: Sounds great! For the most part Git does okay with renames... so I'm not sure there's a huge amount of benefit in waiting. But if there's specific cases you know of, that's fine. Looks good, curious about the logic behind moving packaging into src ? I think that's a good idea, but please make sure it is a test that fails. Relying on humans to police it will cause it to decay quickly. Ted

Hey, I have heard that this is a big issue with Inkscape development, and this is one of those that prevents new coders from helping out. If the issue is more than just the directory, I believe there should be changes in the source code to make it easier for developers. How feasible is fixing the source code? ML From: Tavmjong Bah<mailto:tavmjong@...8...> Sent: Wednesday, March 28, 2018 2:51 PM To: inkscape-devel<mailto:inkscape-devel@...6...> Subject: [Inkscape-devel] Upcoming directory restructuring Hi all, At the hackfest we discussed a revised directory structure to better organize our code, This is a heads up that we plan on doing this reorganization in a couple of week (to give time for existing patches, etc. to land). The purpose of the reorganization is to make it more obvious where to find different pieces of code. At the moment our code tends to be distributed over lots of different directories (especially the code that manipulates SVG and the code for our 100+(!) GUI elements). The proposed directory structure can be found at: http://wiki.inkscape.org/wiki/index.php/Source_Directory_Structure You can comment on the proposed change here or on the wiki page. We also discussed a requirement that all files should have at least one or two sentences to document what their contents does. This should really help new developers (and prevent code duplication). Tav ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel