IDE for python similar to visual basic

Nobody nobody at nowhere.com
Fri Sep 11 08:02:04 EDT 2009


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.




More information about the Python-list mailing list