[Glade-devel] [PATCH/Glade-2.0.0] Re-enabling signal handler's "user_data" parameter

[dragonm nexuslabs com (Dragon Master)]

On Tue, 22 Jul 2003, Jeannot Langlois wrote:

<snip>

> Re:  Re: I've been also wondering why the "data" field on glade-2 was
> disabled. Re: After reading the old mailing lists of glade, I found
> actually no really reasonable reasons why glade shouldn't support the
> "signal data".

I know of no legitimate reason either.  "Because it confuses people" is an
extremely poor reason to do anything that hamstrings those of us who know
what we're doing.  The user_data parameter has a long and hallowed
history, dating all the way back to Motif.  Just because beginners don't
get it is no reason to delete it.  If that were true, rm -rf / would be a
legitimate response to any new Linux user's questions.  :P

> Re: This was one of the argument:
> http://rpmfind.net/tools/glade/messages/0511.html , which is fine and
> nice, but why should this argument hinder glade to fully support the
> powerful signal concept of gtk?
>
> Yeps, it *seems* like a good reason, at least for the "Object" parameter
> (which I *REALLY* find complicated myself and I think they've got a
> point there), but *DEFINITELY NOT* for something as simple as
> "user_data".

I disagree.  I don't think it seems like a good reason at all.  See above,
for part of the reason why.  Beyond the "don't cater to the ignorant"
argument, the example quoted is horrific.  That sort of thinking is what
makes Java an acceptable solution to some people.  lookup_widget()?  In a
huge if else if else if search?  What are you nuts?  We started with O(1)
complexity and "improved" it to O(N) complexity or worse?  This is not
progress.  That whole block of code demonstrated should never exist.  The
GTK+ callback specification was written the way it was for a reason.  The
widget affected was _known_.  Throwing away valuable data like that is
frankly idiotic.  Those of us who understand that a single callback can be
registered for multiple widgets have no interest at all in an exhaustive
search for something we should be handed in the function call.

> If they stick to the idea of chopping every good features (like this
> one) in the next versions of Glade, then, "just too bad", I'll be happy
> to use my "home-made-patch"-ed version of Glade-2.0 for all my personal
> development needs.  That's the beauty of Open Source, at the very
> least... :)

I for one will be using the patched version.  I make extensive use of ALL
the original callback parameters and I refuse to shoot myself in the foot
for somebody else's misguided idea of simplicity.  All hail Open Source.

DM