Current issues

• Can't call /src/setup.py agonistically of working directory
  • I don't know where build artefacts should be placed (e.g. setup.py demo)
• How do we separate program code from assets?
  • To be fair, the code exclusively resides in /src/lib/ and /src/gui/

I think the current layout is pretty clean compared to e.g. libmypaint.

I propose the following change to use same layout as most other GTK apps (e.g. Builder):

• build-aux – files for building packages and development
  • appimage
  • flatpak
  • glade – Glade does not support GTK 4 so this can be removed
  • windows
• data – non-code files
  • backgrounds
  • desktop
  • palettes
  • pixmaps
  • svg
• doc
• src
  • gui
  • lib
• po – translations
• tests

setup.py would remain in the root as the build system entry point.

This is my first GTK project so I really appreciate your input -- this directory structure looks seriously good!

I would perhaps move po to data as most users won't use the directory frequently, but at the same time maintaining consistency with other projects would make it easier for contributors who are used to working with GTK acclimate to our codebase.

I'll update my PR to attempt to recreate this

Yeah, I would like moving po to data as well but decided to keep it in root on consistency grounds for now.

I'm in the process (beginning, really) of vastly improving the developer documentation, so I think if we're both in agreement here we can make up for discrepancies in consistency with improved documentation.

Aside from logical scoping of directories, it should be trivial to give new developers an overview of the project directories.

https://aesarab.github.io/mypaint-website/design/backend

Yeah, after giving it a thought, we do not really need po/ in the root. People really should not edit the message catalogs manually anyway. Just need to be careful when doing the move to also update the links in docs and Weblate configuration.

Though, I would caution against relying on documentation too much, especially for stuff that people actually need to know. Maintaining docs has a real cost and, when documentation is too big, finding the important bits will be hard and people will skip reading it. Best documentation is one that is not needed.

<rant>
This is also why I dislike “Git flow” – it has a distinction between main and development branches that is not intuitive. When opening a pull request, I would ideally just fill in the description and not need to change the branch, unless I need I am backporting a patch from development branch to a stable version.

If I understand the process right, the separation is to allow to test merged changes for a while before considering them stable and then merging them to main (basically a more stable development branch). But we still need to test the main branch before stable branch-off, so we would be essentially testing the same thing twice. That is a lot of effort for a small project without many resources, like MyPaint – continuous testing in single main branch sounds more cost-effective to me.

What GitKraken calls “GitLab flow” (not sure why, the same process has been used e.g. by GNOME project for years before GitLab was a thing) is much easier and natural since it gets rid of the main×develop distinction.
</rant>

I realised when you wanted to merge to the primary branch instead of development that you may not have known that we use Git flow. Immediately this is not a problem, as the codebase is similar. But very quickly after several commits to the development branch a contributor may make a fix based of the primary branch, instead of the development branch.

I'll open a discussion about this. For the time being I'll merge development back into master, because I really do not want to make any contributors rebase because of something stupid like this.