Re: [Pippy-devel]pippy wish list

[Jeffery D. C. <jco...@bo...>]

Tim Chase wrote:

>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. 
>  
>
Sorry for the slow response.  I needed some time to dig up some old data 
for reference
purposes.  Thanks for this information.  It is very informative.

>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/
>

The IBM J9 JVM uses the system traps to call into the PalmOS api.  While 
there is a higher
risk of crashing the device (which is unpythonic), it would avoid the 
necessity of creating
an extension module every time a PalmOS call is needed.  This may be an 
acceptable way
for dealing with the GUI problem, too.

>
>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. 
>

I've received other suggestions for using Pippy for this purpose.  Pippy 
(using prc-tools) uses
a GLib shared library for the storage of the interpreter.  Embedding 
this in a small front-end
program and finding someplace to store the 100K global variable space 
necessary for running it,
we should be able to make calls into it in a way similar to the poplets. 
 The 100K of heap space
seems a bit excessive for small scripting purposes.  I do prefer python 
to just about anything
else, though....



>
>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
>  
>
These are all excellent suggestions.  I have been told that items 1 & 2 
(or portions of these) hav
been completed by a possible contributor, but haven't yet received 
patches.  Item 3 is of particular
interest to me.  Patches encouraged.

>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
>  
>
This project was moved to sourceforge to encourage more active 
development from the Python/Handheld
community.  I would like to see more developers get involved in 
contributing and help to determine the
direction of Pippy.   If you have been developing using Pippy, please 
tell us how your are using it and
what other capabilities you would like to see.  

Tim, thanks for your suggestions and explanation of other technologies.


Jeff Collins