Sorry, silly me to think that Netscape would do it right.
Here are the relevant parts ASCII encoded.
Part of discussion on [EMAIL PROTECTED]
KN is Karl Nelson <[EMAIL PROTECTED]>
CP is me <[EMAIL PROTECTED]>
KN Even better is if glade had a connection layout tool like
KN This
KN
KN ___________
KN | Button | _________
KN | | | Window |
KN | List of ^| | |
KN | signals & | O--------| show() |
KN | methods V| | |_________|
KN | | |
KN | pressed >|-----------O
KN | |
KN |___________|
KN
KN For simple connections and the ablity to click on a method and add to
KN its implementation with C or C++ code.
CP That's a really good idea. But I'm not looking forward to coding this
CP in C/Gtk
CP (within glade).
CP Also the fact that C and glade does not honor an OO scheme for your
CP callbacks
CP clearly lead to the present situation (flat namespace). If glade had
CP been less C
CP centric (remember: I have limited ressources and am also willing to
CP accept 90%
CP solutions) this tool would have been one of the first things
CP implemented. I
CP tried an OO approach via the 'seperate class' attribute in glade.
KN I kind of wish we had our own code generator. Glade tailors
KN toward being a bolt on for the missing C functionality. On other
hand,
KN we aim to that functionality in our classes because expanding a class
KN after declaration in C++ is not posible. (You can't just add a
KN new method to Gtk_Widget later.) We have run into this
KN problem often and our end solution has been chuck the C code and make
KN our code generator do the same trick. Sadly this means same
KN functionality repeated over and over.
CP You speak about glademm? (otherwise I don't undestand this sentence).
CP
CP I have the feeling that names get confused sometimes:
CP - glade is a GUI builder wich emits XML files (and C code)
CP - libglade is a runtime library to construct and configure widget
trees
CP out of a
CP XML file/string
CP - glademm is a XML to C++ converter
CP - libglademm is an (yet to be done) extension to libglade to make
CP connections with
CP C++ callbacks which aims at compatibility with (compile time built)
CP glademm's C++
CP code.
KN No, libglade for the C functionality (XML loader/unloader) and glade/
KN VDKbuilder for building interfaces. I think that that glade the
builder
KN will always tailor towards the needs of the C gtk+ code. Yes,
KN converters are clearly possible. I wish we had gotten at least one
KN builder project of our own tailering the builder to the needs of
KN C++ code generation.
KN> > new method to Gtk_Widget later.) We have run into this
KN> > problem often and our end solution has been chuck the C code and
make
KN> > our code generator do the same trick. Sadly this means same
KN> > functionality repeated over and over.
CP>
CP> I know the problem but can't understand this solution.
CP> Could you name the function/class in Gtk-- for an example?
KN <rant>
KN Yes, I can name many in fact.
KN Gtk::ItemFactory, Gtk::Menu_Helpers, Gtk::Bin, Gtk::Toolbar,...
KN
KN In each case, we came to the point where trying to provide the
KN gtk+ interface to the C++ user became more complicated or
KN ill conceived then rewriting the same interface into C++.
KN ItemFactory was a bolted on Object which connected to Menus to
KN construct them (much like libglade with arrays!) This
KN was a clear place where they added methods to an existing
KN class just under a different name! We recreated the whole interface
KN in C++ as Menu_Helpers. Bin has dozens of mechanisms exposed from
KN the lower layer that don't apply (very bad OO). We still can't deal
KN with that. Toolbar had 12 interfaces to add a limited set of objects
KN on to a list. We ended up replacing it with a clean and
KN typesafe interface.
KN
KN To do this our code generator has grown from a little
KN thing to insert our signal proxies, to a monster which
KN can generate and rearrange code in uncounted ways.
KN Not to mention that we have over 20 options for how to
KN wrap a signal, because gtk+ can't take an idea and stick with it!
KN Before we were drownding because we couldn't maintain all
KN the interfaces, now we are having people understand how
KN we build the code. We swapped one problem for another, luckly
KN I think it was a good trade.
KN
KN The simplest solution that makes the most reuse of code with
KN as few special cases as possible is best, but I am increasingly
KN believing that gtk/gnome was build by cut/paste/modify.
KN </rant>
KN
KN (Sorry, I have had that one pent up for a while. It is
KN not directed at you, as I value glademm and your contributions.)
CP> Is this really an issue which should be addressed in Gtk--? I might
even
CP> think about a library similar to libglade which does not construct a
tree
CP> but change some attributes according to a given XML
structure/string/file.
CP> This is even a small step if you take libglade as your starting
point.
KN Well I certianly won't avoid glade. I think it is best to start just
KN with set_arg and get_arg which are most integrated with the
KN internals of the widget. Where it goes from there is driven
KN by what the users want and what contributors are willing to code.
KN
KN The xml parsers and things that set_args, get_args and build will
KN call are outside my experience. (Hopefully knowledgable contributors
KN like yourself will get involved.)
+---------------------------------------------------------------------+
To unsubscribe from this list, send a message to [EMAIL PROTECTED]
with the line "unsubscribe glade-devel" in the body of the message.
