[Pippy-devel]pippy wish list

[Tim C. <ch...@ia...>]

Since there hasn't been much legitimate traffic on the pippy list
lately, and since pippy development has moved to Sourceforge, I thought
that I would weigh in with my $.02 on what Python on Palm could be.
This is a future-seeing, pie-in-the-sky, wish list. I am not
criticizing current pippy development, but giving some examples of
features we may want to include in pippy.

First, Python Rules! I use it whenever possible for Unix (mostly Zope)
and Windows development. 

I have been using several very high level languages for PalmOS(tm)
development and I will describe them and several features that I wish
could be incorporated into a mythical future pippy. [That is the last
time here that I will put the (tm). Keep in mind that the words PalmOS
and Palm are trademarks of Palm Computing or PalmSource.]

Quartus FORTH

Forth is unique in many respects. It is both very high level and very
low level. The bottom of your program looks like English (or you
language of choice, because you make up the words) and the top of your
program looks like assembly. Quartus uses memos or docs for source
code. For UI, Quartus uses resources from a Palm resource database. You
can use one of several tools, including the onboard RsrcEdit (now owned
by Quartus) to create forms and all of the UI elements for the forms.
You then use the event queue to load the forms and respond to user
interaction with the form elements. Quartus also allows for direct
interaction with the PalmOS through system traps. You can compile a
stand-alone program that doesn't require a runtime. See
http://www.quartus.net/

PLUA

PLUA is a PalmOS port of the Lua programming language. Lua has some
similarities to Python. It uses "tables", which are similar to Python
dictionaries. The syntax is very clear. PLUA uses memos or docs for
source code. It has a built-in environment that is superior to that of
LispMe (at least older versions of LispMe, I haven't used it in a
while). Plua uses internal functions to draw UI elements. I don't like
this as well as using a Palm resource database. It is slower. It does
provide flexibility. However, Palm resources database elements can be
hidden and moved about, which also provides flexibility. If you haven't
ever heard of PLUA, check it out at
http://netpage.em.com.br/mmand/plua.htm

Poplet Kit

This is the most unique use of a very high level language on the Palm.
If pippy could do what Poplet Kit does, but take it a few steps
further, pippy would be the true PalmOS scripting language. "Poplets"
are written in Handscript which is very similar to ECMAScript
(Javascript). Poplets are launched in two ways.

The first way is via the command bar. Starting in PalmOS 3.5, when you
issue a Graffiti command stroke, a bar pops up at the bottom of the
screen. You can choose to copy, paste, etc. by clicking on the command
bar icons. Poplet Kit installs another icon on the command bar. When
you hit it, a menu pops up with all of the available poplets. You
choose a poplet and it runs. I know that PalmOS doesn't multitask and I
am not a computer science guy, so I am not sure what to call this
(cooperative multitasking?), but your poplet runs and interacts with
the current application. For example, you select some text in the
DateBook, or memo, or wherever, and run a poplet to make the text all
caps, or perform a mathematical manipulation on it, or translate it to
French. 

The second way to launch a poplet is via the palmcall: syntax in
Clipper (or another web clipping application or browser). In several of
the included examples, you launch a poplet within Clipper, your address
book pops up, you select an entry, and the poplet returns a Clipper
page with the address of the nearest Starbucks, ATM, etc. 

Poplet Kit's maker, Handwave (http://www.handwave.com) is focused on
the second use mentioned above, poplets as Clipper javascript. I see
great potential in the first use. The PalmOS system trap mechanism,
combined with the ability to launch from the command bar means that a
program could provide scripting capabilities both within applications
and within the operating system itself. For example, given the ability
to send an event to the event queue, you could automate button presses,
Graffiti strokes, any possible user interaction. Combine this with the
ability to retrieve events from the event queue, and you have a PalmOS
macro system.

Although interactive mode is one of the coolest features of Python
programming, I would gladly give it up to be able to use Python syntax
on PalmOS.

In short, here is my list of features I wish for in a Python on PalmOS:

Program Mode
1.Use and manipulate UI elements from a Palm resource database
2.Distribute applications either with or without runtime
3.Access to system traps to use features not directly implemented

Script Mode
1.Launch from the command bar
2.Interact with UI elements of the current application
3.Interact with the operating system (launch another app, turn on
backlight, etc.)
4.Distribute scripts either with or without runtime
5.Access to system traps to use features not directly implemented

Thanks for listening,

Tim Chase
Handbright PDA Software