Introduce gimp_vectors_get_bezier() which creates the bezier
representation on demand and then caches it for subsequent calls
until the vectors object is frozen.
At some point we should introduce GimpVectors::changed instead
of relying on the fact that a vectors object is always frozen
and thawn whenever it is changed...
In order to make a clear separation between the core modules and the
UI modules, move the necessary enums from display-enums.h and
widgets-enums.h to config-enums.h and the files
gimpdisplayoptions.[ch] from the display to the config module. This
removes the config -> display dependency.
This change has three main benefits
* It lets us remove includes of display files from the config module
* We don't have to link gimp-console and test-config with a subset of
object files from the display module
* It is reflected in devel-docs/gimp-module-dependencies.svg that the
application is made up of core modules and UI modules and that no
core module depends on any UI module
Some single-window mode tasks are completed, and some bugs on the 2.8
milestone have been postponed. New estimated release candidate date is
2010-12-27, but I expect more bugs and features to be de-scoped. The
updated estimates are put in a new snapshot, i.e. put in a new column.
Add an OpenOffice.org Calc document that contains a list of tasks that
needs to be done before GIMP 2.8 is ready for release. An estimate of
the time to complete each task, in 8-hour work days, is also
given. Based on this data an estimated date when we will have a GIMP
2.8 release candidate ready is calculated. The formula includes a
“days worked per week”-factor that specifies how many 8-hour work days
that the GIMP community together produces per week. There is also a
sheet where things planned for GIMP 2.10/3.0 is put. With this
document we will be able to better plan what features to include in
what version.
Add an SVG illustration of GIMP library and core modules and the
dependencies between them, created with
tools/module-dependencies.py. One obvoiusly evil dependency is
app/config -> app/display, if we get rid of that the cycle between
core modules might be broken.
This document describes how the GIMP UI framework functions and is
implemented. Here, "UI framework" refers to the system that saves the
UI layout between GIMP sessions, i.e. how docks, dockable dialogs etc
are setup.
Martin Nordholts