On Mon, 07 Sep 2009 23:56:17 +0000, Albert van der Horst wrote: >>The main advantage of a GUI builder is that it helps prevent you from >>hard-coding the GUI into the program. You could get the same effect by >>coding a UIL/XRC/etc file manually, but a GUI builder tends to force it. > > A GUI builder results in hard coding the GUI. The code only resides > elsewhere.
Data (e.g. a UIL or XRC file) isn't code. But "hard-coding" is more a question of whether you can realistically change the data without changing the code. If the code craps out due to minor changes to the data, there isn't much advantage of having a separate data file. >>Creating a GUI programmatically is almost always the wrong approach. It >>tends to be adopted due to a path of least resistance, rather than any >>affirmative reason. > > In view of the above this is not quite the correct way to put it. > > What I resent is that it leads to a non-professional attitude > of the graphical part. Programming is over, lets now kludge > some screens together. No. The graphics part has to be carefully > designed, carefully tested, and carefully "written", even if it > is using a graphical tool. So, yes please, *do* create a GUI > "programmatically". My view is that the program should provide functionality without unnecessarily dictating the way in which that functionality is used. Essentially, it's an issue of "loose coupling". The interface really should be configurable by the user according to their needs. The code doesn't need to *know* the position or dimensions of a widget, or its label or colour or spacing, let alone dictate them. In most cases, the code shouldn't even get to dictate that specific widgets even exist. Rather, it should provide actions which can be bound to buttons, menu items and/or accelerators as the user chooses. -- http://mail.python.org/mailman/listinfo/python-list
