OSNews

You seem to be mistaking my refutation that the GIMP isn't poorly designed and is indeed modular as some some admission that I think modular design is bad. Reading comprehension 101 please.

You don't understand it though. The GIMP is poorly designed and is not modular - hence why GEGL has actually come about. Logical fallacy. However, GEGL is still a large monolithic library that doesn't share much itself, so it isn't really going to help that much.

This has contributed to the GIMP's lack of features, simply because they're just not easy to add without affecting everything else. You're rather chasing your tail there.

You've obviously never looked at GEGL because it's not a single monolithic library.

Yes it is.

Can you tell me what toolkit GEGL is written with that has base graphical functionality available to, and used by, other applications and desktops (apart from some cursory usage of Glib which doesn't count)? It's not enough that you just include a large monolithic graphics library and call it 'reuse'.

Abstraction should also make things easier to program, as well as providing components that allow you to change and add new features easier. It's just an awful API to work with:

http://www.gegl.org/api.html

The core of GEGL should probably be in GTK as a bunch of decent, straightforward interfaces that everyone can reuse for free.

Really, this all has f--k to do with why GIMP doesn't have these features?

Because without the right architecture, they're extraordinarily more difficult to add. Other applications have many features it has taken the GIMP years to add. This goes to the root of what you don't understand.

The real reason is that nobody that wants them is willing to implement them.

It's the usual excuse, but the reason why people are unwilling to add features that lots of other software has is because it's too much effort to do. If they took less effort to do, people would be more likely to add them and would more likely have the time to add them - no?

Stop proclaiming yourself an expert on a code base to which you've _never_ even taken a passing glance.

I never proclaimed myself as an expert. I certainly have taken a passing glance, but it's rather difficult to explain what's going on to people who don't know that modularity is about more than just 'front-ends' and 'back-ends' and that reusing code takes forethought, time and effort and is logically linked to the functions you wish your application to perform and the base stuff everyone wants to be able to do.

Of course, being an VB "programmer", C might be a little over your head.

I'm not a VB programmer sweetheart (have used some on and off though as well as C, C++, Java, Python, Ruby and a few others), but I do know people who use it because it's right for the desktop systems they are producing.

I do find it rather astonishing that anyone has missed the concept of code reuse over the past twenty or so years. I recommend a good systems and analysis book, because this has nothing to do with showing your dick in public about C versus VB (which is the typical response from a C-oriented programmer to something he doesn't understand).