Still Loving Python

Mike Meyer mwm at mired.org
Tue Dec 13 20:33:36 EST 2005


Peter Maas <peter.maas at somewhere.com> writes:
> Mike Meyer schrieb:
>> I agree. I've tried a number of different gui builders. I find it much
>> faster to type something like:
>>     ui.add_button("New", self.new)
>>     ui.add_button("Open", self.open)
>>     ui.add_button("Save", self.save)
>>     ui.add_button("Save As", self.save_as)
>> Than have to drag four menu buttons from a pallette, then open the
>> properties of each one to edit the text of the button and the callback
>> entry (or whatever dance they need so you can enter the required
>> text).
> If you design a moderately complex UI a designer will be faster. It's
> not the speed of typing vs. dragging that matters. You see the result
> instantly and don't have to start your program, look, type code, start
> again and so on.

But you only need to do that if you're wanting near-absolute control
over what's displayed. Once you provide reasonable accessability and
configuration features - letting the user specifiy fonts, which
buttons show up, which toolbars you're going to have, what's in the
menus, etc. In this case, "look" is trivial, and it seldom requires a
second pass.

> A GUI builder is more pleasant to work with, at least
> with a good one like Delphi or Qt designer.

That is your opinion, and I'm sure it's true for you. It isn't true
for me.

> It's not a good idea to do everything in code. I find it tiresome to
> create menus and toolbars by writing code.

Maybe you're doing something wrong? Or maybe it is tiresome for you,
and you should be using something else.

> Creating visual resources visually is the direct way, creating them in
> code is a detour. Code is too lengthy and too versatile for such a
> job.

Your application creates code in the end, so that's the direct
route. A visual representation of a modern app is a relatively static
version of the real interface, and thus at best an approximation.

Worse yet, there's a good chance your visual tool stores the
information needed to recreate either the visual version or the code
in either a binary format, or a proprietary one, or both. In the
former case, standard code analysis tools are nearly useless. In the
latter case, they own your code. While that price might be worth it if
you place enough value onj being able to manipulate images instead of
code, either is enough to make me avoid a tool.

      <mike
-- 
Mike Meyer <mwm at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.



More information about the Python-list mailing list