On Tue, 2007-04-17 at 19:07 +0200, David Nečas (Yeti) wrote: > On Tue, Apr 17, 2007 at 10:42:08AM -0400, Tristan Van Berkom wrote: > > > > If your program is a long term investment and undergoes frequent > > refactoring, then do it now :) you will significantly improve your > > code's legibility, reduce lots of code and as such; add value > > to your product, this is not just my pointed opinion - libglade > > reduces complexity from your code > > It redistributes complexity to other places and to relations > between the code and the other places, if that is what you > mean by `reducing complexity from your code', however it > does not reduce the total. The typical recommended use > scatters strongly coupled information to distant places, > destroys modularity and discourages refactoring into > functional (reusable) units such as custom widgets and other > classes. If the interface changes dynamically and/or it > reflects some data structures (unknown at compile time), > adding libglade into that is just a recipe for headache. >
Haha I never heard that one before, you must have had some kind of bad experience, I will explain a little further down what I mean by "reducing complexity"... > > the fact that you can later dynamically change > > your UI using a designer tool without editing your source code is > > only added sugar. > > Whether this is a featue or bug is yet to be determined. Well people have been using it in practice for over 5 years, i'd say that as its becomming more and more of a preference to have this behaviour, its definitly proven not to do any harm to distribute a dynamic UI, if it poses security threats (doubtfull), then the paranoid can always compile the glade file into thier program as a string constant. So its definitly not a bug, but I wouldnt call it a requirement, the abstraction is definitly a requirement - not the dynamic part (although that may have even become a requirement to some). > > Consider that adding a user visible feature to your > > program will become a matter of: > > a.) Adding a control widget to your GUI with a designer tool and then > > b.) Adding a callback function that will interface with your core > > application code to perform a task, maybe also > > c.) Fetching a widget pointer from the libglade built hierarchy to > > provide the user with feedback from the core. > > The code representing the dynamics of the user interface > forms the bulk of the code, accounts for almost all the > complexity and often shares bits with construction code. > If simplifying construction -- the easy and straightforward > part -- radically simplifies your program, your program is > most likely Hello world. Not a chance dude, if you are writing hello word, xcalc or any random peice of junk, you hardly need to implement a level of abstraction to get rid of all the bloat that is a handcrafted UI, but when your application starts to mesure hundreds of thousands of lines then you better brace yourself - if you can mangle out all the crap that touches your UI by hand then more power to you. > c) in its typical use is global variables in disguise (a > flat pool with everything). Well look at the devhelp sources for a simple example of what I'd call good use of libglade, any widget pointers that are needed for a given module are stored at that module's initialization process using glade_xml_get_widget() before discarding the GladeXML, you only store pointers that are needed on a structure that is only relevent to that module (or that UI interface to a core module or what have you). FYI, I have been using glade a long time before I was ever writing code for glade - we maintain an embedded jukebox system where the UI component (mesuring ~3000 lines of code without any UI construction code thank god, just IPC and library calls wherever needed and all driven by an FSM engine) is 100% dynamic and "gladable". Before we had the goodness of gtk+ and libglade we were running a modified DOS kernel and had our own UI description files and "in house" toolkit - I had to hand edit that description file and test it line by line to make sure I didnt leave any untracable mistakes, there was no designer tool, but at least we didnt have to hand code it. Think about it, with a gstreamer pipeline leading into a real time audio sound server (jack) over USB (quite experimental), a database of songs/artists/bookkeeping/statistics, a self updating software system & database over a secure network/telecom system, data mining and survey fluff systems to manage - not to mention the whole OS to fine tune and maintain (kind of like LFS or gentoo), device drivers for peripherals such as coin acceptors, an IPC to hold it all together - you think we could afford to mangle all the UI construction code into our system ? just imagine the cost ! Heres a screenshot of what the current interfaces look like using gtk+-2.0 and glade3: http://www.gnome.org/~tvb/glade-tt-screenies/glade3-drag-anim1.jpg Heres a screenie of what it looks like using the original libglade with gtk+-1.3 and original glade tool (was developed about 3 or 4 years ago): http://www.gtk.org/success/touchtunes.png Like I said before - if your application is not significantly big - then you might not need the abstraction of libglade - but eventually things get out of hand and you have to put your foot down :) Cheers, -Tristan _______________________________________________ gtk-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtk-list
