Re: [Gimp-developer] Questions on GIMPs technical architecture

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:

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 <scl gplus gmail com> wrote:

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.



gimp-developer-list mailing list
gimp-developer-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]