I'll only answer the questions I feel qualified to answer.

1. Yes, the circular dependencies are messy. I think we'd like to get rid of them, just nobody has gotten around to it. Patches are welcome.

3. The main difference is that modules tend to be more tightly integrated with the gimp core, while plugins are almost stand alone. Modules are shared objects that run in the gimp process, while plugins are separate executables, which are run in a different process. Modules implement eg. display filters and different input controllers, while plugins implement eg. filters and file loaders/savers. Plugins are limited mostly to accessing image data.

The reason for the distinction is that while plugins are more limited in their capabilities, they are also run out of process, so if one crashes, gimp doesn't go down with it.

5. Other parts of the gimp already contain unit tests too. Example: libgimpcolor/test-color-parser.c

It's just that the core is the most important part, so it has the most tests written already.

More unit tests are welcome.

On Sat, Jun 15, 2013 at 8:10 AM, scl wrote:

Hi,

while getting into deeper touch with GIMPs code I also dealt with its software architecture. For this I analyzed and visualized the #include-dependencies with the Doxygen tool [1]. You can see the results at my blog [2].

The following questions arise to me: 1. The diagram show obvious circular dependencies between some components (marked in red and noted textually). There are also more circular dependencies within some components. Also in the code, like in /app/tests I found hints on circular dependencies, but it was worked around them instead of solving them. Such circular dependencies make it hard to test or substitute single components, introduce undesired side effects and thus make the code harder to maintain, see also [3].
I think all could be benefit from a clearer code. How it could look, shows the GEGL example [2].
I respect the hard maintaining work that has been done yet and don't want to lecture anybody, so I just ask:
- Are they in the code by intention? - If not, are there objections against removing them?

2. The directories /devel-docs and /tools both contain developer tools. If we had them together in the /tools directory and the /devel-docs directory only contained only documents, the architecture would be easier to understand, because one component in the diagram would be dropped.

3. Both modules and plug-ins provide optional functionality and can be de-/activated dynamically at runtime. With a few exceptions they use the same libgimp* libraries. Why is there a distinction between modules and plug-ins? Can we simplify the architecture and the UI by removing this distinction and handle them the same?

4. What exactly is the Wire protocol and how does it work? I already read, that it is a transparent, not threadsafe, shared memory for communication between the GIMP core and the plug-ins. But that's all I found yet and it doesn't give me enough understanding of the protocol.

5. Why does only thee /apps directory contain (unit) tests and not the whole application? Are there objections against having such tests in the other parts of GIMP?

6. Which considerations played a role in the past for the architecture, like optimization for performance, maintainability etc.?

7. Who else here cared or cares about such questions?

As we all developers could benefit from clarifying these questions, I'd be glad about your answers, even if they answer only a few questions. When we have something for the real, I could take it to the wiki and/or /devel-docs directory.

Thank you in advance.

Sven

[1] http://www.stack.nl/~dimitri/doxygen/ [2]
http://sclaussner.blogspot.de/2013/06/some-already-noticed-it-im-active-in.html [3]
http://stackoverflow.com/questions/1897537/why-are-circular-references-considered-harmful

_______________________________________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list