Still Loving Python

[Bengt Richter]

On Tue, 13 Dec 2005 20:33:36 -0500, Mike Meyer <mwm at mired.org> wrote:

>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.
De gustibus non disputandum, or whatever ;-)

>
>> 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.
>
If that is your concept of Delphi, it is wrong. A text view of what you have
created visually is available. I put four buttons on a blank form with
captions per your example. The result is

object Form1: TForm1
  Left = 200
  Top = 108
  Width = 696
  Height = 480
  Caption = 'Form1'
  Font.Charset = DEFAULT_CHARSET
  Font.Color = clWindowText
  Font.Height = -11
  Font.Name = 'MS Sans Serif'
  Font.Style = []
  PixelsPerInch = 96
  TextHeight = 13
  object Button1: TButton
    Left = 64
    Top = 48
    Width = 75
    Height = 25
    Caption = 'New'
    TabOrder = 0
  end
  object Button2: TButton
    Left = 152
    Top = 48
    Width = 75
    Height = 25
    Caption = 'Open'
    TabOrder = 1
  end
  object Button3: TButton
    Left = 240
    Top = 48
    Width = 75
    Height = 25
    Caption = 'Save'
    TabOrder = 2
  end
  object Button4: TButton
    Left = 328
    Top = 48
    Width = 75
    Height = 25
    Caption = 'Save As'
    TabOrder = 3
  end
end

You see the above sort of text if you are looking at a form you are working and you press Alt-F12.
If you do not violate the format, you can edit it as text right in the window you are looking at
and round-trip it back to a visual view with another Alt-F12, and you will see the adjusted visual view.
Other aspects of objects show up too if you set non-default conditions one way or the other. E.g.,
adding an individual mouse-over hint is a matter of typing the text in a slot in the object inspector
which is automatically showing the properties of the button etc that you have visually selected
on your form/dialog. E.g., above button with hint added.

  object Button4: TButton
    Left = 328
    Top = 48
    Width = 75
    Height = 25
    Hint = 'Opens a file dialog for saving'
    Caption = 'Save As'
    ParentShowHint = False
    ShowHint = True
    TabOrder = 3
  end

A single click compiles, links and runs the resulting independent windows .exe in a fraction of a second
for the above, and I can see the hint, kill the .exe, and go on where I was.

Of course, as you see, I could select the text and put it in the clipboard, and post it here.

BTW, Delphi also compiles and links in a blink (literally for small programs), and generates
a small .exe. Delphi also lets you code without GUI and gives you a command line compiler for
its object pascal, and you can write very small executables that way if you like, even using x86 builtin assembler.
And it compiles and links _hella_ faster than C/C++ ;-) And you can make DLLs, and link also with non-Delphi.

Not that I've used it for quite some time, though ;-)

Anyway, I wouldn't diss Delphi too casually. I don't think you would if you'd spent enough time to
get fluent in it. (I don't know what the current state of Delphi is though. I'm speaking from experience
mostly with the ancient Delphi3 whose output you see above ;-)

Regards,
Bengt Richter