Re: Ann: GtkCanvas 0.1

[Havoc Pennington <hp redhat com>]

Count Zero <countzero@cyberdeck.org> writes:
> This is yet another reason why interdependancies are a bad thing.  I
> applaud the author of GtkCanvas.  

The author of GtkCanvas is Federico, Andy Tai has just cut-and-pasted
it. As I said in another mail, it's not a fork, just a mechanical
relocation of the code. This would be necessary short-term even if
Federico agreed to break GnomeCanvas out of gnome-libs, because
gnome-libs 2.0 won't be out for a while and we can't break
binary/source compat at the moment.

> Small standalone libraries are
> consistant with the unix philosophy, and GNOME is consistantly going
> against this time-proven way of doing things.  Of course, since
> Miguel's attitude is in opposition with the unix way of doing
> things, this isn't surprising, but I am always glad to see
> developers who are willing to stand up and show, with code, that
> GNOME's monolithic way of doing things is not acceptable.
> 

While I agree with you that GtkHTML should be available as a GTK-only
widget, Larry Ewing (who maintains it) did say he would take a patch
to break apart the GNOME-dependent portion. Until you submit that
patch and he rejects it, I don't think forking is justified and I
think you're doing the wrong thing with CSCHTML.

Of course people shouldn't have flamed you for wanting a GTK-only
widget, but since the widget still requires tons of work (such as UTF8
support), a fork at this point is a pretty poor idea.

If you make an honest effort to work out a way to break the current
codebase into GTK-only and GNOME-dependent portions, and Larry won't
take a quality patch to do that, then you have a reason to fork.

There are several ways to hack the current widget; the simplest one
would be to simply build two libraries with different names in the
Makefile, one with the GNOME bits and one without. Then install them
both. Or you could do something with dynamically loaded modules, or
you could have a core library libgtkhtml and add-on libraries for the
printing and component stuff. Possibly you need to virtualize some
functions then make a subclass for the GNOME-ized widget. There are a
number of technical approaches that could be explored. But I'm sure
one of them would work fine.

Havoc