Re: Ann: GtkCanvas 0.1

[Steven Kordik <stevek voila net>]

On 24 Jul 2000 01:58:34 -0400, Havoc Pennington said:

> 
>  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.

I am sorry for the confusion, I did not mean to imply that Andy Tai had
written a new widget from scratch.  Even if all he has done is a
cut-and-paste job, he still did THAT, and as such, is the "author" of
that cut and paste job... I am really surprised at how touchy people seem
to be about this... He went out of his way to make clear to everyone that
his work was merly a re-packaging of Frederico and Raph's work... But
Andy IS the author of the re-packaged work, even if his only claim to
authorship is cut-n-paste...
  
>  > 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.

A) I was under the impression that Ettore Perazzoli was the maintainer
for GtkHTML.  If he is not, I have been e-mailing the wrong guy.  (Which
may explain why we are getting nowhere fast with our talks regarding a
no-GNOME GtkHTML.)

B) Just what kind of patch should I submit?  There are two routes this
could take:

	1) A compile time flag --with-gnome (or --without-gnome) that
would not compile in the GNOME related features, but would instead
require a re-compilation of the library, if at a later date, the user
decided to use the GNOME features.

	2) A splitting of the functionality, where you have a core
GtkHTML widget (with no GNOME deps) and then several GNOME modules that
extend/depend on GtkHTML.

In my mind, (and as you suggest below) option 2 is the best option.  But
lets look at why I cannot simply "submit a patch" to impliment option
2...  It requires CO-OPERATION with the developers of GtkHTML...
co-operation that so far is not forthcoming.  After the recent round of
e-mails on this list, (the last of which was nearly a month ago on June
30th) I have sent several e-mails to Ettore to discuss how we could
proceed with a good Gtk only GtkHTML widget, and have recieved only a
single response.

His response was (in summary) "I don't see why anyone would want this"
and "submit a patch" Well, I responded and explained that I needed some
input from him as to the direction a patch should take... Option 1
(above) is something I could easily independantly cook up as a patch, but
option 2 requires a re-thinking of the way the current widget is built,
and is a bit more invasive.  And it also requires a shift in the way
future development would go ... In other words, it is something that the
current developers of GtkHTML would need to agree on and help with... 
Sadly, I have yet to recieve any sort of response to my latest e-mails.

Oh, and as far as "putting code where my mouth is" or being a "backseat
coder" I maintain that I do not qualify as either, since I have put my
code where my mouth is in the form of CscHTML.

As I have said before, I am VERY willing to work WITH the GtkHTML
development team to create a single GtkHTML widget that can be bundled
with Gtk+ and benefit the WHOLE community (not just GNOME developers) 
If, however, the GtkHTML team continues to ignore my attempts to discuss
this issue and work with them, I will be forced to continue to develop
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.

I agree 100%

>  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.

I am making an honest effort, and have been stonewalled (so far)

>  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.

I agree, and I have attempted to initiate communication to explore these
options, so that I can write the CORRECT patch, but my efforts have been
ignored...

>  Havoc

-Steve
-- 
---------------------------------------------------------------------- 
Steve Kordik					      stevek@voila.net 
System Administrator				      Tel 212.332.5045 
VOILA - France Telecom North America		      Fax 212.332.2362 
1270 Avenue of the Americas			New York, NY 10020 USA 
---------------------------------------------------------------------- 
Customized Search Engines for your web site at: http://voilasearch.com 
----------------------------------------------------------------------