graphics: canvas vs. gnome-print and GIMP

[Gediminas Paulauskas <menesis delfi lt>]

11 Mar 2001 14:15:27 -0600, Chema Celorio ra??:
> I am all for splitting modules v.s. merging them.
> 
> Smaller pieces are easier to get from cvs and to update as a binay
> package. From a maitainer point of view, they are easier to make releases.
> For example planing a gnome-print release with lauris is like 15 irc lines
> of talk. If gnome-print where to be inside gnome-libs, we would not be as
> flexible as we are now to make releases.

There is only one point I can think about better-merge-than-keep-splitted.
It's libart_lgpl, gnome-canvas and libgnomeprint. In libgnomeprint there is
a lot of files (some of them private) just copied from both libart_lgpl and
libgnomeui/gnome-canvas*. It is obviously a bad thing. Also, while
gnome-canvas is a very cool thing, anything your draw cannot be printed, or
am I totally wrong?

In general, there is one feature: vector-based drawing on screen and
printing on paper, and manipulation of various properties of graphical
objects (basically color management). Currently this is splitted up into
libart, gnome-canvas (these are in gnome-libs), gnome-print, Pango, Gtk+,
and, never forget it -- The GIMP, which is not part of GNOME!

GIMP has it's own printing architecture, color selectors, dialogs, color
management, selection tools, Dynamic Text Tool, module/plugin browsers,
recent file stuff etc. It is very bad situation, because other apps cannot
use these features, they write their own. On the other hand, GIMP does not
use things which are also in gnome-libs etc., so it's interface is not so
cool (menus and buttons without icons, no docks, different translation base,
etc.) I like triangle color selection tool of GIMP, and wanted that it was
everywhere where I click on gnome-color-picker. But it's not possible.

So features should be carefully pulled out, sorted and merged where they are
most useful -- Pango, Gtk+, libgnomeui, libgtkcanvas or libbonoboui.

> However a bigger library is indeed easier to build (from my experience) so
> we need to find a way to fix this. The scenario that itp brought up is a
> _daily_ royal pain for hackers and to-be-hackers.

I am not angry when Evolution changes required version of GAL twice a day --
just because it is easy to build. However I have not tested gnome-libs
1.4beta, because I could not build it or there were problems using it. So I
use what Debian provides -- just because it's too hard to build. When "make
distcheck" fails in last directory which has a very simple fix, you have to
waste two hours to build everything again till that point. Horrible.

-- 
Gediminas Paulauskas