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 somekind of bad experience, I will explain a little further downwhat 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 tohave this behaviour, its definitly proven not to do any harmto distribute a dynamic UI, if it poses security threats (doubtfull),then the paranoid can always compile the glade file into thierprogram as a string constant. So its definitly not a bug, but I wouldnt call it a requirement, theabstraction is definitly a requirement - not the dynamic part (althoughthat 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, xcalcor any random peice of junk, you hardly need to implement a levelof abstraction to get rid of all the bloat that is a handcraftedUI, but when your application starts to mesure hundreds of thousandsof lines then you better brace yourself - if you can mangle outall 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 ofwhat I'd call good use of libglade, any widget pointersthat are needed for a given module are stored at that module'sinitialization process using glade_xml_get_widget() beforediscarding the GladeXML, you only store pointers that areneeded 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 everwriting code for glade - we maintain an embedded jukeboxsystem where the UI component (mesuring ~3000 lines of codewithout 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 hadour 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 realtime audio sound server (jack) over USB (quite experimental),a database of songs/artists/bookkeeping/statistics, a self updatingsoftware system & database over a secure network/telecom system, datamining and survey fluff systems to manage - not to mention the whole OSto fine tune and maintain (kind of like LFS or gentoo), device driversfor peripherals such as coin acceptors, an IPC to hold it all together -you think we could afford to mangle all the UI construction code intoour system ? just imagine the cost ! Heres a screenshot of what the current interfaces look likeusing 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 originallibglade with gtk+-1.3 and original glade tool (was developedabout 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 - buteventually things get out of hand and you have to put yourfoot down :) Cheers, -Tristan _______________________________________________gtk-list mailing listgtk-list@xxxxxxxxxxxxx://mail.gnome.org/mailman/listinfo/gtk-list
