GIMP 3.2 Will Aim To Be Out Within One Year Of GIMP 3.0

[caligula]

Thanks for that. I suspected that might be the case. In principle, if the binding exists, you can use a GUI toolkit from any language (Python is used (!)), so it is just down to ease-of-use/productivity, in which case, using an OO language with an toolkit written in an OO language probably has the least 'impedance'. There's also an academic debate that could be had over whether 'pure' OO is sufficient/ideal for programming a GUI, depending on what someone defines as 'pure' OO (I don't want to go there - I have no wish to participate in a religious war, but it is sometimes interesting to watch from afar).
No matter what, when someone describes something as 'crazy', there's usually something going on. People do apparently crazy things for reasons that appear good to them, so understanding why can sometimes lead to useful insights. Thanks for the reply.

Well, there are many issues when doing GUI in C:

- First, the data and control abstractions are quite poor. C is not a strongly typed language. Yes that's an issue. Almost all current languages are moving towards strong typing (e.g. type hints in Python and PHP, JS -> TS, Rust, C++, Java, Julia, etc.). The compilers do various kinds of checks and optimizations regarding the objects and classes in OOP languages. JIT compilers can even optimize virtual calls. The memory layout is pretty optimized - see how compact the objects are in forthcoming Java 24. Other keywords here are encapsulation, class invariants, pre and post conditions, virtual tables, traits and other forms of multiple inheritance, generic classes and variance of generic data types. C doesn't even support easily expressing basic function signatures. It's quite common to see void* pointers instead.

- GUI programming involves handling resources. C++'s RAII, Rust's ownership types (affine types) solve some issues. Higher level languages have things like autocloseables and garbage collectors. Somewhat related, GUI often involves threads and asynchronous programming. That's also very verbose and error prone in C. Unfortunately threads are problematic in many other languages as well, but people are slowly learning. Another huge issue is the memory model. People also benefit from higher level thread abstractions like thread pools, executors, etc. They all involve special rules that cannot be expressed in C. C simply isn't the right language for this unless it will be revised in the future version.

- There are also issues with OOP as a paradigm for defining GUIs. Sometimes people want expressive DSLs (e.g. QML), sometimes reactive programming, sometimes functional stuff. Sometimes even plain C is better at expressing stuff like tables than OOP languages. OOP doesn't provide any meaningful abstractions other than encapsulation. Most of the GUI abstractions are design patterns on top of objects. These can be expressed in other ways in other paradigms. Just take a look at Haskell school of expression, a book from 1999.

Yes, the only benefit of using C is that language bindings are doable, but I'm not sure if this is a useful goal. We could just use native high level GUI libraries instead.

[Jumbotron]

It's called Krita

LOL...I'm embarrassed for you.

[Jumbotron]

I hope they can soon get to GTK 4.

Gimp 3.2 by 2026

Gimp 4.0 with full GTK 4 rewrite.....2050

[Old Grouch]

I can only speak for myself, but I think it is the last part that doesn't make sense. I guess it did back when GTK originated, as C++ was not yet standardized, many compilers had all sorts of bugs and quirks and maybe not even supported on some platforms. And also could have been more resource-heavy. Nowadays, however, I don't think C would make sense. C++ provides natively many of the things that are bolted onto GLib (like subclassing, reference counting). Or if one wants to use a simpler language, then there's Rust.

I'm sure there are reasons, like personal preference/skills etc. But I've used both, GTK and Qt, and for me, it is a night-and-day difference between how easy they are to use, and a lot of that boils down to the language they're based on.

Thanks for that. I suspected that might be the case. In principle, if the binding exists, you can use a GUI toolkit from any language (Python is used (!)), so it is just down to ease-of-use/productivity, in which case, using an OO language with an toolkit written in an OO language probably has the least 'impedance'. There's also an academic debate that could be had over whether 'pure' OO is sufficient/ideal for programming a GUI, depending on what someone defines as 'pure' OO (I don't want to go there - I have no wish to participate in a religious war, but it is sometimes interesting to watch from afar).
No matter what, when someone describes something as 'crazy', there's usually something going on. People do apparently crazy things for reasons that appear good to them, so understanding why can sometimes lead to useful insights. Thanks for the reply.

[fintux]

Do you object to the object-orientedness of the GUI, the use of C for a GUI, or doing object-oriented programming (in C)?

I can only speak for myself, but I think it is the last part that doesn't make sense. I guess it did back when GTK originated, as C++ was not yet standardized, many compilers had all sorts of bugs and quirks and maybe not even supported on some platforms. And also could have been more resource-heavy. Nowadays, however, I don't think C would make sense. C++ provides natively many of the things that are bolted onto GLib (like subclassing, reference counting). Or if one wants to use a simpler language, then there's Rust.

I'm sure there are reasons, like personal preference/skills etc. But I've used both, GTK and Qt, and for me, it is a night-and-day difference between how easy they are to use, and a lot of that boils down to the language they're based on.

[aviallon]

Interface Toolkits aside, IDGAF as long as the image transformations and engine is separate. And it seems like that's exactly what's done as GEGL can be scripted. So you want a Qt Interface? Start making patches, have at it. I'm sure a lot of people would love a Raster Qt tool.

It's called Krita

[loganj]

before GTA 7????

[FireBurn]

Sure Jan

[Old Grouch]

Unfortunately GNU usually means outdated technical standards. Lots of outdated programming conventions, stupid extensions, bloat (compare gnu coreutils with the musl based distros). Also doing object oriented GUI in C is just crazy.

Do you object to the object-orientedness of the GUI, the use of C for a GUI, or doing object-oriented programming (in C)?

[caligula]

It is kind of funny that GTK originally came from GIMP (the name stands for GIMP ToolKit), and now they are lagging behind it so far. Though on the naming in more general, the G in GIMP comes from GNU and in it in turn comes from GNU's Not Unix, which is a recursive acronym. So actually the G in GTK comes two hops from a recursive acronym.

Unfortunately GNU usually means outdated technical standards. Lots of outdated programming conventions, stupid extensions, bloat (compare gnu coreutils with the musl based distros). Also doing object oriented GUI in C is just crazy.