[gtk-list] Re: The new libgtk 1.2_1.2.3-1 breaks ...(really, rantNrave)

[Kurt Cockrum <kurt grogatch seaslug org>]

Havoc Pennington said:
>The problem is that he's calling gtk_widget_set_events() on a realized
>widget, or maybe Gtk is; either way, it's a bug, because that function
>only works if the widget is not realized (thus the error message :-)
>
>You're supposed to use gtk_widget_add_events() if the widdget is already
>realized.

How could anybody have ever figured this out?  We have 2 functions,
gtk_widget_add_events() and gtk_widget_set_events(), with not a clue as
to why they should even exist.  I can see why it would be useful to have
a method that sets the events a widget responds to, but why 2 variants,
where one chokes if the widget is *realized*??
What's the point of this?  The gtk_widget_add_events() function is called
*once*, in gtkdnd.c:gtk_drag_source_set(), nowhere else in all of gtk.
The other is called a bunch of times in various widgets.

How do developers benefit from the gratuitous proliferation of similar
but incompatible cruft-variant-functions?  You sure can't tell the
difference in functionality from the names.

The net effect is that it basically just increases traffic on the list,
bloats the code, and provides an opportunity to show off painstakingly
acquired knowledge, but what other good does it do?

In the FAQ () it says:
  1.7.  The gtk-list hasn't had any traffic for days, is it dead?
  No, everyone's just busy coding.

Well, the question seems kinda stale and ought to be tossed out; I've
never seen a day go by *without* gtk traffic, mostly the same old stuff
about problems with new versions replacing old versions and shared
library screwups.

Isn't it about time multiple versions of shared libraries learned
to live together?  With just a little smarts added to configure,
this should be possible.
With memory and disk space getting cheap as dirt, it seems like
a false economy for libraries to be stomping on each other, a la
the typical newbie redhat install, all because they are duking it
out in a resource-starved impoverished namespace.

"Just busy coding"?
glib/gtk/gdk is now up to something like 200 KLOC.
An awful lot of that seems to be chaff like
gtk_widget_add_events() and gtk_widget_set_events(),
and tautological comments (where any exist at all) like:
	/*************************************************************
	 * gtk_drag_source_set:
	 *     Register a drop site, and possibly add default behaviors.
	 *   arguments:
	 *     widget:
	 *     start_button_mask: Mask of allowed buttons to start drag
	 *     targets:           Table of targets for this source
	 *     n_targets:
	 *     actions:           Actions allowed for this source
	 *   results:
	 *************************************************************/
	void 
	gtk_drag_source_set (GtkWidget            *widget,
			     GdkModifierType       start_button_mask,
			     const GtkTargetEntry *targets,
			     gint                  n_targets,
			     GdkDragAction         actions)
which seem to be there mainly to satisfy the requirements of
some comment-counting metric, maybe the one used by the
PhD-grantors at UC Berkley?  I mean, duh, what *else* could
	"*targets"
*be* but a "table of targets", huh?

Maybe it's time to stop coding madly away and go back and finish up on
stuff like documentation and cleanup.  After all, with 1.2, things seem to
be *way* past the point where a lot of new functionality is being added.
I once saw something called "The GIMP Toolkit" by Peter Mattis that looked
like a *nice* start, but it mysteriously went away without ever getting
finished.  There are also annoying empty spots in the tutorial, too.
I hope the documentation project I've heard about fixes these,
rather than giving us a new set of incomplete documents.

I've lurked on this list for a couple of years now and have managed
to belly-crawl about 25 feet up the thousand-foot learning cliff :) .
It seems that this is the story of gtk.  The only reason I've figured
out for this state of affairs is that it's intended to separate out Real
Hackers from ordinary grunt C programmers (like me), but for what reason
I can't imagine.  I can only hope somebody benefits from this.
For all I know, it's RedHat's online employment/IQ test and I've flunked :) .

With all due respect to the Harlow book and the writers of the Gtk
tutorial (2 *small* sparks of light in a *vast* darkness, unfortunately
nearly indistinguishable IMO)  I'd sure
like to see some documentation on the rationale *behind* things like
(as one instance) the two functions mentioned above.

For example, why do widget states like "realization" exist at all?
How does that make a widget work better?  What's the difference between
"realization", "mapping", visibility, etc.

What's the difference between "stopping" and "blocking" a signal and
why would anybody want to do either?

Why do styles exist and how do they make something easier to do?  It looks
like they add an extra layer of complexity without any corresponding real
benefits.  Why are styles and .gtkrc's better than UIL or X resources?
Or are they just similar-but-different?

It almost seems like gtk was specifically *designed* to be the subject
of a high-traffic list, and only incidentally a replacement for motif or
some other widget-set.  It looks like the dark side of Open Source to me,
kinda like the tail's wagging the dog.

Other than the simple reason of "everybody else is doing it", I'd be
hard-pressed to say why somebody should choose gtk over say, lesstif
(or the other way around, for that matter).  Sure, somebody is going to
say that {less,mo}tif is uglier than gtk.  I guess I'd just have to take
that on faith, because I see no evidence before my eyes that would tilt
the scales of judgement one way or another.

Rather than dismiss all of this as just flamage, I would hope that
some people might see fit to seriously attempt to answer the above
questions/points.  It isn't my intention to step on toes, but I don't see
how I could ask such questions without at least appearing to.
Of course, there's always the chance I'm just a stupid Philistine,
blissfully unaware of the cause of my problems :) :)
--kurt
  NATO's unfair! If they can bomb Serbia's radio & TV stations,
  why can't they bomb ours?