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

[Owen Taylor <otaylor redhat com>]

> 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 :) :)

It is of course, just flamage. But I'll bite anyways.

Kurt Cockrum <kurt@grogatch.seaslug.org> writes:

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

gtk_widget_set_events() was never able to change the event mask
of an realized widget, and could not be modified to do so without
changing the way every widget was written. For DND, I needed
to be able to add events to an existing event mask; this was
not the semantics of set_events(), so created a new function
to do so.

Almost nobody would ever have to use add_events(); those that want
to use it either have to read the source, or wait for documentation.

If it bothers you, consider it an internal function. 
 
> 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.

How would developers benefit if I broke every custom widget
just so that I could do something in one corner of GTK+?
 
> 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.

I have no idea what this means. 
 
> "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?

Well, if the comment offends you, ignore it. (Or go read
some other GTK+ source file.) It is my comment, and I neither
am at UC Berkely, not have any expectation of having code
metrics run on that point of code.

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

So do I. In fact, I have been spending substantial amounts of time 
on it. Documentation is the #1 priority of the core developers
at this point. period.

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

Well, sometimes it suprises me too, but several millions of lines
of GTK+-based code have now been written, so people seem to be
figuring it out one way or the other.

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

"stopping" a signal means: don't call any more signal handlers
during the current emission. It tends to be very useful for
overriding default actions.

"blocking" a signal means to prevent it from being emitted
in the first place. Offhand, I can't say where it would
be useful. Grepping through the GTK+ and GIMP sources
might give some clue why it was added.
 
> 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?

Styles describe the appearance of a widget. They can be set
frmo a program, or from an RC file. 

They have no relation to UIL.

They are much simpler than X resources, because they only deal
with appearance, and not with behavior. 
 
> 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.

Funny, I really thought I was working on GTK+ because it was
fun, because it was useful to me, and because it was useful
to other people. Now I find I had a subconcious urge to
generate more mail in my inbox...

                                        Owen