(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 _______________________________________________ Glade-devel maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/glade-devel
