"Freddie Unpenstein" wrote: > You're going backwards here... Having the code generation part of > Glade limits you to what the Glade developers have done, and how good > they are at doing it. Having the code generation seperate, allows > someone else to take over that burdon, who could potentially be better > at it than they are.
Since Glade code generation supports ALL features which are supported by the Glade GUI, I think this is a "limit" one can live very well with. Even the primary replacement project, libglade, didn't for a long time. I'm not aware of any secondary replacement projects (alternate code generation projects) at all as yet. I don't see how they could support more features in translating Glade XML to C source than Glade GUI supports at all? > So where's the loss of freedom of choice? I already see messages from > someone planning to pick up the torch. I only saw messages from people claiming that it's (pretty) easy to do. I haven't seen anyone picking it up or actually planning to do so. > Reinventing the wheel is sometimes the only way to remove the kinks. > If the tyre on my car blows, I don't try to stitch it back together, > I get a new one. But more importantly, I do so with the knowledge of > how that last one performed, and what to look for in the next one. Reinventing the wheel != replacng a blown wheel with a new one. _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
