Re: [MacPerl] Porting an Inside Mac QuickDraw example routine

[Lasse Hillerĝe Petersen <lassehp@imv.au.dk>]

Chris Nandor wrote:

>Having the MacPerl Toolbox modules as they are is, to my mind, essential
>and exactly how it should be.  We must have the low-level functions to
>create, later, high-level ones.  Maybe when you learn Perl well, you can
>take a shot at it, if no one else does.  It is certainly a worthy project.

I have just been skimming this thread, and would like to throw an idea into
the discussion.

What you and ilir seem to be discussing is whether there should be a higher
level interface for GUI programming. Something like MacApp, PowerPlant or
Tk, I suppose.

I never got around to write any applications with either MacApp or
PowerPlant, and I have never studied Tk, so I can't say much about them.

I have used HyperCard and SuperCard, however, and in many ways, I believe
the development style of HyperCard and SuperCard applications (stacks)
suits Perl very well, because like HyperTalk/SuperTalk, Perl is an
interpreted language.

Therefore, I think it would be very nice to have an application with a GUI
to design windows and dialogs with text fields, buttons, scroll-bars, menus
and other controls, and a simple and direct way to attach perl code event
handlers to these controls. (Compared to the more awkward way the similar
thing is achieved for example with PowerPlant and the PowerPlant
Constructor.)

Of course, all items should be available from the Perl side, much like the
%ENV hash, in form of a small set of global data structures, or a tree
structure accessible from a global reference.

I'll see if I can think up an example in a hurry:

Let me design an application "Hello" that has only one menu item "Hello" in
the File menu, which displays a window containing two fields: a static text
field (initially blank), and an edit text field, and a button "Hello".
Typing a name in the edit field, and pushing hello, yields the text "Hello
$name, how are you today" to be displayed as the static text.

Let's assume the existence of some application/GUI editor, in which we can
design the interface.

First, we open the menu editor window, add a file menu, and add a Hello
item to the menu. Then we click a button called "Handler", and type the
perl code to handle the creation of a window. This should be just one line
that refers to the window we'll create next.

Next, we open the window template editor window, make a new window
template, and start drawing the controls. We don't need any handlers for
the text fields, their default behaviour is OK. We call the edit field
editHello, and the static field staticHello. If we wanted, we could add
various handlers for mouseOver, mouseDown, doubleClick etc, but we have no
need. The only item in need of a handler is the Hello button.

The click handler for the button is simply something like

$app->FrontWindow()->{"staticHello"} = "Hello ".
	$app->FrontWindow()->{"editHello"}.
	", how are you today";

a suitable tie takes care of the rest. No worry about event loops, update
events, or WaitNextEvent. That should all be hidden behind the scenes for
all common tasks.

As I said, this is just a hurried note of an idea, I hope you get my meaning.

The application should of course have MacPerl embedded, and there should be
ways to get to lower level data structures as necessary. In theory I
suppose the entire editing application could be written in MacPerl itself,
although I wonder what the efficiency of such a strategy would be, compared
to a native C solution with MacPerl compiled in. It might be surprisingly
efficient, however.

The application should know about numerous types of "controls", including
graphics of all kinds: polygons, ovals, rects, roundrects, pixmaps,
splines, etc. It should be possible to create these objects in a
traditional OO manner from a script, or draw them and later modify them, by
moving them around, changing some of their anchor points, etc. Changing
attributes should be achieved by plain assignment to the appropriate tied
attribute.

If written in MacPerl, it could probably be "bootstrappable" in some way, like:
- first the framework for an application should be defined.
- second, the a primitive editor should be written using the framework, as
if it had been generated from the editor itself.
- third, the primitive editor should be used to modify, enhance and improve
(a copy of) itself.

Voila: A Perl equivalent to HyperCard, but much more powerful, or what?

Unfortunately, writing this would require strong knowledge of Perl, OO
programming in Perl, and the Mac Toolbox, as well as an enormous amount of
available time. I have neither the knowledge nor the time. I would very
much like to use such a tool, however, even to the point that I would pay
hundreds of $ for it, were it a commercial product. If it could be made
platform-independent somehow, it would be even better.

Now, the likely thing that will happen is that someone will tell me that
this is in fact how Perl/Tk works, and I should look into that. :-) By all
means let me know if you think I'm babbling. Personally, I don't feel I'm
babbling, just dreaming.

-Lasse



# ===== Want to unsubscribe from this list?
# ===== Send mail with body "unsubscribe" to macperl-request@macperl.org