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

[jeannot12 linuxmail org (Jeannot Langlois)]

(CC'ing this message to the glade-devel mailing list...)

Hello,

Re: On Tue, 22 Jul 2003, Jeannot Langlois wrote:
Re: 
Re: <snip>
Re: 
Re: > Re:  Re: I've been also wondering why the "data" field on glade-2 was
Re: > disabled. Re: After reading the old mailing lists of glade, I found
Re: > actually no really reasonable reasons why glade shouldn't support the
Re: > "signal data".
Re: 
Re: I know of no legitimate reason either.  "Because it confuses people" is an
Re: extremely poor reason to do anything that hamstrings those of us who know
Re: what we're doing.  The user_data parameter has a long and hallowed
Re: history, dating all the way back to Motif.  Just because beginners don't
Re: get it is no reason to delete it.  If that were true, rm -rf / would be a
Re: legitimate response to any new Linux user's questions.  :P

Eheheheh. :-).
 
Re: > Re: This was one of the argument:
Re: > http://rpmfind.net/tools/glade/messages/0511.html , which is fine and
Re: > nice, but why should this argument hinder glade to fully support the
Re: > powerful signal concept of gtk?
Re: >
Re: > Yeps, it *seems* like a good reason, at least for the "Object" parameter
Re: > (which I *REALLY* find complicated myself and I think they've got a
Re: > point there), but *DEFINITELY NOT* for something as simple as
Re: > "user_data".
Re: 
Re: I disagree.  I don't think it seems like a good reason at all.  See above,
Re: for part of the reason why.  Beyond the "don't cater to the ignorant"
Re: argument, the example quoted is horrific.  That sort of thinking is what
Re: makes Java an acceptable solution to some people.  lookup_widget()?  In a
Re: huge if else if else if search?  What are you nuts?  We started with O(1)
Re: complexity and "improved" it to O(N) complexity or worse?  This is not
Re: progress.  That whole block of code demonstrated should never exist.  The
Re: GTK+ callback specification was written the way it was for a reason.  The
Re: widget affected was _known_.  Throwing away valuable data like that is
Re: frankly idiotic.  Those of us who understand that a single callback can be
Re: registered for multiple widgets have no interest at all in an exhaustive
Re: search for something we should be handed in the function call.

You're sooo right.  Especially for that Java-culture thing too.  

I just want want to ammend what I said concerning the "Object" feature.  I find it a little complicated just 
because it allows signal receivers to be modified (or something like that) and getse confusing.   But it's 
just my opinion, because I don't fully understand it doesn't mean it should not be there... eheh :-).  I 
guess I should have said it in another way.  Sorry for that :-).  But about the "user_data" feature, I can't 
honestly see why they would like to remove it (??).  

Unclear.
 
Re: > If they stick to the idea of chopping every good features (like this
Re: > one) in the next versions of Glade, then, "just too bad", I'll be happy
Re: > to use my "home-made-patch"-ed version of Glade-2.0 for all my personal
Re: > development needs.  That's the beauty of Open Source, at the very
Re: > least... :)
Re: 
Re: I for one will be using the patched version.  I make extensive use of ALL
Re: the original callback parameters and I refuse to shoot myself in the foot
Re: for somebody else's misguided idea of simplicity.  All hail Open Source.
Re: 
Re: DM


Great, thanks for you "moral support" too! :)  Ehehe.

Good'day to all,



--
Jeannot Langlois
B. Sc. Computer Science
jeannot12 AT linuxmail DOT org
-- 
______________________________________________
http://www.linuxmail.org/
Now with e-mail forwarding for only US$5.95/yr

Powered by Outblaze