Hey Well the point I think John is making is certainly holds a bit of truth. The UI names are a lot C centric where as while most of the old people might use python/C#/ruby etc they have used C before. But some of the new league of programmers don't even touch C (kinda unfortuanate :(, but I myself was suprised when it I overheard a kid say so at Gnome Summit NYC)
Also Paolo's point stands, which I state more as, "" I can't believe we're arguing over such a small detail!!! "". If you feel the need, submit a generic patch (this is for John, and generic as in for most languages not just python) :-D and we'll review. until then I think none of the main guys wants to change it .. so a courteous and non-offensive :P Cheers! Archit Baweja "John (J5) Palmieri" <[EMAIL PROTECTED]> writes: > On Tue, 2004-01-13 at 14:15, Paolo Borelli wrote: > <snip> > > > > IMO adding one more widget (the dropdown) would make UI even more > > painful: the user already has to go trough a lot of pointing and > > clicking just to add a simple signal (as I said in another mail this > > could well be one of the reasons why most of the projects prefer simply > > using g_signal_connect() ). > > It take a couple of clicks. What would be nice would be for the most > common event to be assumed and all you do it type in the event callback > which would also be autofilled as it is now. That is a seperate issue > though. > > > > > Beside it would not work: FooHBox may have been subclassed from GtkHBox > > so in the TreeView with the list of the signals you should have *both* > > at the same time. > > In the signal TreeView you would have both (verbage is just an example): > > HBox for Gtk Signals: > ... > HBox for Foo Signals: > ... > > as opposed to > > GtkHBox Signals: > ... > FooHBox Signals: > ... > > > > We all might be programmers but if we want to make this easy for newbies > > > flooding them with GtkWindow when they might be writting Gtk.Window > > > might be confusing. If you split them from the begining they get used > > > to the fact that Gtk is actualy seperate from Window. Gtk is a > > > windowing toolkit package and Window is a class of that package. > > > > It *might* be confusing... lets stick to the facts, Glade2 uses > > GtkWindow since forever and I never heard a complain or a question. > > Well we just did here a complaint from a user who programs in Python and > got a bit confused. > > > Another thing to mention is the also on the first page of the Editor > > "Class:" contains GtkWindow. > > This is where I suggested adding the Package dropdown. So > > Class: GtkWindow > > Would become > > Package: Gtk \/ > Class: Window > > Not many people edit this so complexity is a moot point. It doesn't > realy change anything but does make it more generic and less C binding > centric. > > > > > I really think we are arguing over a detail... > > I don't know if arguing is the right word. I agree that it isn't all > that important but the topic was brought up so I thought I would share > my views. The details are realy important however as people might not > rabidly complain about it but it is still a consitency issue. Splitting > package and class solves that issue without adding all that much > complexity. In fact I belive it clears things up for those who are not > part of the super C coder club (Those who can redily apply OO tequniques > to a procedural language :-) It also cuts down on verbosity in the > interface. How many times do I have to see Gtk first when all I want is > a Window? I just see it as a good middleground between having Glade > become language sensitive or making alternitive language programmers > fell like they are second class citizens. > > Anyway I don't have time to program it right now so I'm not going to > care much one way or another. If somone sees my posts and says hey this > is a good idea and easy to do, then all the better. At the point Glade > gets integrated into Scaffold and I have time I might just write a patch > and see how people like it :-) So I leave it to the experts to decide > for now. > > -- > J5 > > > > > ciao > > paolo > _______________________________________________ > Glade-devel maillist - [EMAIL PROTECTED] > http://lists.ximian.com/mailman/listinfo/glade-devel _______________________________________________ Glade-devel maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/glade-devel
