Re: [Aquaterm-developer] Re: Python interface for AquaTerm?

[Per P. <per...@ma...>]

On m=E5ndag, januari 28, 2002, at 05:55 , Bob Savage wrote:

> on 1/28/02 6:38 AM, Per Persson wrote:
>
>> Hi Bob,
>>
>> I recently got a mail from Jeff Whitaker who is the maintainer of
>> several scientific packages over at Fink with a question about using
>> AquaTerm from Python. I have never used Python, but from a quick =
Google
>> search I found out three things:
>>
>> 1) Python looks really cool
>
> Yes. Emphatically yes.
>
>> 2) It should be possible to write a nice adapter for Python
>
> I believe this is correct, although I do not understand the exact =
scope=20
> of
> "adapter".

 =46rom my point of view, an adapter (adaptor?) is an object that is=20
familiar with two (or more) environments and mediates between them. The=20=

name is take from (again) "design patterns" by Gamma et. al.
So in the case of gnuplot the adapter (aquaterm.trm) takes procedural=20
calls (plain C) and translates them into the Obj-C mesaages that=20
AquaTerm understands (defined by AQTProtocol). This mean that all the=20
messy translation  is localized to a specific object. In the case of=20
Python (which is a lot more general case than gnuplot) an adapter would=20=

provide a new interface representing a python mind-set so that the=20
python programmer wanting to display graphics can do so using the python=20=

way. The hard task is of course to decide what that python interface   =20=

would look like (small, efficient and very, very python!).

>
>> 3) You seem to be the man to ask for details!
>
> Uh, I have a fair amount of experience with Python, and will be happy =
to
> work on this. But in all honesty, there would have to be at least a=20
> half a
> dozen people that would better serve as "the man".
>
>> Maybe this is something that should go onto the ToDo-list?
>
> I say yes.
>
>> What do you
>> think of the idea, difficulty, general usefulness etc of such an=20
>> adapter?
>
> Before answering any of this, I would need to understand better what =
was
> meant here by "adapter". Python is very different from GnuPlot, in the=20=

> sense
> that GnuPlot is a program and Python is really a language.
>
> Also, GnuPlot has a well defined output stream that needs to be=20
> displayed,
> whereas Python needs are impossible to determine at the outset (they =
are
> whatever an individual needs them to be). In this sense we might say=20=

> that
> AQT would be a way for Python programs to have access to Cocoa GUI=20
> elements.

Yes, or rather to access the subset of GUI elements that AquaTerm=20
provides.

> This seems rather ambitious, but certainly not impossible. In this=20
> scenario,
> there would be a Python module that a Python program would import =
(call=20
> it
> aquaterm.py), and then people would use objects in aquaterm.py that=20
> enable
> them to create and manipulate and communicate with Appkit widgets.

I think that is taking it to far. It is definitely possible, but for=20
starters I think we need to restrict AquaTerm to be an app that render=20=

and view/save/print graphics.

>
> Another angle could be hosting a Python Interpreter inside of AQT, but =
I
> doubt that would be useful. More likely someone would want to be able =
to
> embed the Python Interpreter in their app, which they probably could =
do=20
> from
> Python itself, using AQT only to display it.
>
> I guess to think about difficulty, the real issue is how much of =
Appkit=20
> do
> we need to wrap up?
>
> As to usefulness, it sounds great to me, although I should mention=20
> another
> project that would be overlapping a bit:
> <http://sourceforge.net/projects/pyobjc/>
I tried it but I couldn't get it to work. Probably some versioning=20
problem.

>
> The reason that an AQT module for Python would still be useful is that=20=

> the
> pyobjc project is much more ambitious -- they are trying to bridge the
> entire Objective-C language (!) and therefore give access to all of=20
> Cocoa
> from Python. Well, a subset that focuses on building GUIs could be =
both
> easier to develop, and easier to use for the intended purpose.

I agree completely, simplicity is important here. AFAIK, a lot of people=20=

use python for computations and if a simple module like aquaterm.py=20
existed then they could easily bring up a graph of the results and save=20=

it as a pdf.

>
> So what are the essential elements that would need to be included to=20=

> make
> this useful?
>
> Create a window.
>     Title it.
> Create a view.
>     Position it.
>     Draw into it with bezier routines.
>     Place text on the view.
>         Adjust the font properties.
>
> All of this looks pretty easy to wrap up, yes?
>
Yes. Come to think of it, we need a way to tell what (connecting) app=20
owns what model since it is possible to have more than one app writing=20=

to the same model at present.

> Additional stuff that would not be too difficult to add:
>
> Create and place text entry widgets.
>     Get back entered information.

This shouldn't be too complicated, no high priority at the moment

> Create and place buttons.
>     Connect to a callback for execution.

Definitely possible, it would need some thought so it gets done=20
properly. Future project.

>
> I looked at the other example application that came with AQT, and I=20
> remember
> this being there, so I'm guessing that this would be almost trivial to=20=

> add
> once we got the basic technique for creating the module worked out.
>
> I'm still trying to find the time to put that color inspector =
together,=20
> but
> let me know what you think about how much we would need to include to=20=

> make
> it useful, and I will take a look at how one compiles a Python module=20=

> from C
> (which I have not done before).
>
I think defining a set of python "primitives" like moveTo(x,y),=20
circle(x,y,radius) and then implement them in the module using the=20
methods defined in AQTProtocol. To be really useful the set of=20
primitives must be small and fit the python paradigm.

/Per


> Bob
>
>
>
> _______________________________________________
> Aquaterm-developer mailing list
> Aqu...@li...
> https://lists.sourceforge.net/lists/listinfo/aquaterm-developer
>