Considering different languages.

Possible candidates are:

• Vala
• Nim

At first glance Nim looks very good, I am considering using it for the implementation. The reason is the set of articles I've read plus the fact that I have a background fitting to this language (Pascal, Delphi, Lisp, C, C++).

Heck, I liked Swift a bit, mostly for its syntactic sugar (like chaining of the optionals and type inference). Then I liked Vala for its simplicity and integration with GTK. Now I like Nim...

Looks definitely like the analysis paralysis.

Is GIMP worth spending time on it?

Now after reading a lot about the GIMP, I see that it has some critical problems.

Here are the links I have read (ones I have recorded):

• https://www.mail-archive.com/gegl-developer@lists.xcf.berkeley.edu/msg00612.html
• http://www.rileybrandt.com/2014/03/09/photoshop-to-gimp/
• https://mail.gnome.org/archives/gimp-developer-list/2015-February/msg00055.html
• http://www.thebloomapp.com/features/
• https://pixls.us/articles/freaky-details-calvin-hollywood/
• https://wiki.gnome.org/Design/
• http://www.gimpusers.com/forums/gimp-user/15297-how-to-design-new-gimp-themes-from-scratch
• http://www.maketecheasier.com/flat-gimp-icon-theme/
• http://blenderartists.org/forum/showthread.php?313266-New-Gimp-PS-CS6-Theme-with-icons
• http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.84.7715&rep=rep1&type=pdf
• http://gimp-tutorials.net/

Currently I see the following problems with GIMP development (if I am going to dive into it):

1. The software architecture. It is neither documented, nor obvious from reading the Object-oriented C code.
2. The architecture seems to be too monolithic to allow deep changes like the ones I am interested to introduce.
3. Lack of organization: what I see in bugtracker and wiki is very far from optimistic picture.
4. Strange choice of tools - as for 2015 - like plain C with "manual" OOP. I see no reason why they don't use at least Vala. I have a feeling that the language, despite being absolutely fine for OS kernel, is slowing the development down.

Here is what I see the most critical current problems of GIMP:

• Lack of non-destructive editing. Most flagrant is lack of affine transformation and color control.
• Awful UX design. I know that some people can disagree with me, but here is my opinion: there is an industry standard. Instead of fighting with it, GIMP interface could live with it. Why some professional artist who uses Photoshop on a daily basis should learn new habits? What for?
  I have read somewhere beautiful explanation: the tool (GIMP in this case) is an obstacle that stays between artist and his/her goal. The tool should prevent artist to do the job as little as possible. Therefore responsiveness and predictability matters. Therefore it is important to follow the industry UX standards. It is important, because people already have some habits (including me btw.) and these habits are a scarce: they are in fact an experience. And to be fair, for me my habits are more valuable than the tool.

All in all I have a feeling that the development of the GIMP is artificially slowed down.
Some ideas under the hood are brilliant (like GEGL abstraction), but some are horrible (like OOP implemented using plain C).

Thus I am seriously considering diving into Krita despite I don't like the KDE.

Docker for GIMP: task is on hold

After fighting with dependencies necessary to compile GIMP (yes, now I can do it professionally) I've got another idea: what if I put necessary parts into the docker container? Any newcomer could benefit from having such a preconfigured development environment. The need for the container is simple: it is difficult-to-impossible to automate one step in the build as the necessary libraries are:

• lcms2 
• gdk-pixbuf

...where lcms2 cannot be downloaded automatically (or at least I did not find how to do this) and gdk-pixbuf is placed on the ftp in the way so that I cannot link to the latest version without some sophisticated script. But I could create the docker container. Well, theoretically I can do it as I never did it before.
I thought about two different flavors of the containers: the smallest necessary one which would have only these two mentioned libraries and the complete, huge one which would have everything up to the ubuntu into it.

Anyway, as the solution seems to be only a half-measure because it would break in case any of three participants (gimp itself, lcms2 and gdk-pixbuf) would change in some incompatible way, I put this task on hold.

Alas.

Tools to understand larger amount of C code

To understand the structure of the GIMP project I try to use as much of modern tools as possible. I believe that accumulated experience in the field of analysis worth something. So I bet on them. Of course, reading the source code is still an option, but the last resort, so to say.
Here I put the links on the tools I considered so far.

• Wikipedia article to the software that creates the call graph based on the source C code 
• NCC compiler (never heard of it before, but the description sounds promising)
• kcachegrind (the one I use currently)

---

 Now, the current topic is GLib main loop. Links:

• Official documentation of the main event loop 
• GLib: GMainContext

Also helpful:

• "Delivering Signals for Fun and Profit" - Michal Zalewski 
• man 2 poll
• man 2 select

The very old document on GIMP architecture

It is good to have Google...

Looking for GIMP architecture in internet I've found the paper "The Software Architecture of the GIMP" (2006). Yes, it is old, but it's all we have. I wonder if anyone has anything better.
The funny thing about the document is that it is not available directly using the site (citeseerx.ist.psu.edu), but Google gives you the direct link to it.

Installing and configuring software is the ultimate form of Yak Shaving.

Fighting the GIMP, I spent enormous amount of time setting the development environment.
On the last iteration I've found this beautiful article related to the Docker.
The "Yak shaving" metaphor describes my process so precisely that I could not resist to store it here.
If I would have found this article earlier, I could have saved much much much time. On the other hand, how could I know, how much time would it save? It is so ironic...

Creeping features

I don't like the pantheon terminal outlook on the Elementary OS. It is better than others including the one in OSX (I tried only the default one though). But why the heck does it have all these bells and whistles like header, tabs and so on? Just asked a question at stackexchange and got a hint how to do it. So, long story short, I tried to strip all the decorations with some simple hacks, without diving deep into the GTK+/Glade and so on. But the problem has to be solved fundamentally, with some settings. Anyway, I put my thoughts there, in the initial question.
And yes, it is just another spin-off from the main topic of hacking the GIMP. Just a spin-off...