mirror of https://github.com/GNOME/gimp.git
49 lines
2.0 KiB
Plaintext
49 lines
2.0 KiB
Plaintext
On making Gimp OO
|
|
|
|
This document outlines the ideas of the conversion to using the GTK
|
|
object system in gimp core.
|
|
|
|
The basic problem with gimp's internals is that it is _old_. Some of
|
|
the stuff dates from the 0.54 era, before layers, before GTK. This has
|
|
caused the current source to be what some people call a "mess". You
|
|
don't want to hear what the other people call it.
|
|
|
|
Some of the main problems are that there are far, far too many headers
|
|
included everywhere. That is, encapsulation doesn't work. This causes
|
|
nasty dependencies, and doesn't exactly do good for compile times,
|
|
either. In addition, there are too much integer ids on objects. These
|
|
should only be used for pdb, and even there there'd probably be better
|
|
ways of passing them. The gtk object system will better facilitate
|
|
data hiding and encapsulation.
|
|
|
|
Then there are the tools. The tools have a primitive object hierarchy,
|
|
but it is a mess when compared to gtk's system. Restructuring the
|
|
tools will make the world a better place, and new tools easier to
|
|
implement.
|
|
|
|
GTK's object system has many other features that will make gimp
|
|
programming easier, the chief one being signals. When gimp's images
|
|
and displays have signals that you can connect callbacks to, different
|
|
components of the program will be better able to keep up with the
|
|
state of things.
|
|
|
|
Also, having all types in the gimp core use a standard object system
|
|
will make it easier to export these types as CORBA objects when the
|
|
time comes for that.
|
|
|
|
|
|
Some guidelines:
|
|
|
|
Everything should be as modular and independent as possible. Core
|
|
image manipulation classes should have no hard-coded relations with an
|
|
"UI". There should be no global variables in the classes.
|
|
|
|
All gimp classes should derive from GimpObject. This is just in case
|
|
we need some common debugging functionality or something.
|
|
|
|
For a future locking system, and just for code clarity, things should
|
|
be made const correct. That is, if a function doesn't modify an
|
|
object, it should take a pointer to a const object.
|
|
|
|
|