[Pythonmac-SIG] FAQ item

[Glenn Andreas]

At 9:41 PM +0200 7/29/03, Jack Jansen wrote:
>On dinsdag, jul 29, 2003, at 19:18 Europe/Amsterdam, Glenn Andreas wrote:
>>PyOXIDE does syntax coloring (and the next version should work 
>>correcty with 2.3), but it doesn't have the debugger that PythonIDE 
>>does (yet - it will soon though).  It is, however, making extremely 
>>good progress (last night I added a simple module 
>>help/documentation window that uses pydoc) - it is really amazing 
>>how powerful Python + PyObjC + Cocoa really is.
>
>Glenn,
>there were some questions here about your binary-only release of PyOXIDE, and
>I don't recall seeing an answer from you yet on the subject of 
>PyOXIDE licensing.

The current plan is freeware but the source to the Objective C 
portion is not available (but all the python portion is).  The 
problem is that the editor is actually part of my Palm development 
IDE and so it still pretty well entangled (I plan to clean this up, 
but partially by bring _more_ of the IDE over, with things such as 
"projects").  All in all, the source editor is still quite a ways off 
from being a simple, stand-alone, drop-in, everything works, sort of 
thing (for example, right now it assumes that every document belongs 
to a project which keeps track of things such as break-points, as 
well as additional symbols to color, completion dictionaries, "find 
definition" double-click pop-ups, headers, etc... only some of which 
are relevant right now to PyOXIDE).

>About the debugger: this is a part that is probably pulled over from 
>the existing
>IDE relatively easy. There's also bits and pieces of a class/object 
>browser already
>that we could use.

It should, I just haven't looked in much detail into it yet.  The 
object browser is basically the demo from PyObjC, and the 
interactive handler (see below) is very similar to the Interactive 
object in the existing IDE.

>And in general: I would really like the IDE to be structured as a 
>set of widgets
>(text I/O widget, editor widget, object browser widget, etc) that would then
>be used in an extensible set of windows (editor window and browser 
>window, clearly,
>but the debugger window would probably contain an editor widget and 
>two browser widgets
>too, if it were structured like the current IDE debugger window).

Currently (as of last night), the PyOXIDE architecture basically has 
an Objective-C subclass of an NSDocument for both the documents and 
the interactive windows, both of which are associated with a python 
"handler" object (sort of like a delegate, but with more 
responsibility).  The Objective-C portion is actually a delegate for 
the text edit window (which includes a special subclass of NSText to 
handle the coloring, a subclass of NSScroller for the split panes, 
etc...), and it provides a bridge between AppKit and the handler 
object.

These handler objects actually do nearly all the python stuff (for 
example, the various menu commands such as "Run" or "Run Selection" 
are now just another command that the NSDocument subclass forwards on 
to it's handler), so it is very extensible.


>I would also like the IDE to be extensible. One of the things I want
>is the possibility to add tools for specific target areas. For 
>example, something
>like a CGI developer would be really nice: it runs your script as if it is
>a CGI script, once you're happy with that you can actually run it as 
>a real CGI
>script and finally you can deploy it.

This is absolutely one of the things that I'm hoping for.  That is 
part of the idea behind adding "projects" - you could make a project 
that has a special "run mode" for emulating a CGI-script, and that 
all of the following python source files are part of it, and when it 
works, press a couple of buttons and out pops everything all nicely 
and neatly packaged up (obviously being all neatly packaged up is 
more useful for a stand-alone app)

> Something I want even more (and which is
>even more work) is a dead simple dialog/window creation tool, similar to
>what RealBasic (or, long ago, Hypercard) gives you. It should create perfectly
>normal nib files, and perfectly normal PyObjC code, so that it gives an easy
>learning curve from beginner to advanced.

The biggest problem I see right there is that there is no documented 
way to create nib files except to use IB.

Glenn Andreas                      gandreas at delver.com
Author of Macintosh games: Theldrow 2.3, Blobbo 1.0.2, Cythera 1.0.2
Be good, and you will be lonesome