Python Browser Applets
Terry Hancock
Well, I've researched this further, and for those who are interested,
I think I found a much better (read "easier") solution:
First, AnyGUI is probably a better standard GUI to provide for
the Applet/Plugin. As an attempt at a common standard, it's
a much smaller API than Tkinter or PyGTK (though it provides
backends for them). It is still somewhat incomplete, though.
One of the backends "planned" for AnyGUI is "PyUI" which I
looked up:
and it is a GUI implemented against a "renderer" which is a
very small class that has to be implemented for each class
which simply handles the basic drawing actions. The PyGame
2D renderer bundled with it has less than 250 lines of Python
code, which define methods like drawText() and drawRect().
So the simplest approach is simply to write an AWT renderer for
PyUI which can then run in Jython. At that point, the Java-only
restriction is lifted, because PyUI can also run on PyOpenGL or
PyGame/SDL renderers (as well as several other choices), so the
applet would run in C Python as well.
At this point, I have 2 choices:
1) Run on Java-1.0-enabled browsers (which is pretty much
all the commercial browsers, but not the free ones until you
install a plugin). (Requires developing AWT renderer, possibly
contributing to AnyGUI & PyUI projects to fill out any missing
features).
2) Run as an independent Python application. For convenience,
this can be configured as a "Helper App" in the browser so it will
pop up when needed (Renderer already written -- actually a
choice of them, may require AnyGUI/PyUI contribs).
If I want to get more ambitious, it is possible to get the Netscape/
Mozilla Plugin SDK (and the Python Embedding manual) and
write a Plugin to embed the Python interpreter to run Python Applets
natively. I have found evidence that someone *once* did this,
but all traces of the original implementation seem to have vanished
from the web, and I'm not sure if it would've been easy to update
a Python 1.5.2 plugin to Python 2.1+ (though it might). Possible
starting places include:
Mozilla Plugins Page: http://www.mozilla.org/projects/plugins/
Alice: http://www.alice.org
WPY: http://www.python.org/ftp/python/wpy/
Reading the Plugin API docs, though, I have to admit to being
somewhat lost -- I haven't figured out how a Plugin actually can
draw itself into the browser window space allocated for it. It seems
like this would have to mean that the "Netscape Methods" would
include drawing primitives or a canvas object that can be drawn
to, but I haven't found it yet (Or maybe I'm misunderstanding
how it works, and the plugin has to talk to the underlying window
library -- but that seems bizarre and awkward).
In any case, I figure it means writing a "Netscape Plugin Renderer"
for PyUI. This would give me option
3) Run Applet on Python Plugin (Requires embedded python
plugin -- big project?, Netscape Plugin Renderer for PyUI -- small,
contribs to AnyGUI and PyUI if needed).
The plugin route is kind of the "high road" though -- very nice result,
but it clearly requires the most work.
Lastly, there are the Free Java implementations -- meaning the
JVMs, the class libraries, and the "Open Java Interface" plugins. If
one or more of these work, we have option
4) Run Applet on *Free* Java browser platform (need the AWT
renderer, contribs to AnyGUI, PyUI, and Free Java OJI of your
choice -- maybe KaffeOJI, which does exist).
Kaffe OJI: http://www.kaffe.org/ftp/pub/packages/kaffe-mozilla-oji/
I have summarized these options in a diagram at:
http://www.anansispaceworks.com/NaryaInfo/client_html
As well as an idea for Zope-integration, but don't worry
about that part -- it's just a way to make deploying the applets
easier on the server side. The "Version 2" Zapplet is a pretty
terrifying diagram, although I think it makes it look worse than it
is -- it's just using a trick I got from a Java Applet/Plugin paper to
make the process a lot more automatic for the user. The PreLoader
and Loader, for example, can be fairly small programs, and I
believe I have some sample code to start from. Version 2 is
basically meaningless without the Python Applet Plugin (option #3).
It's clear to me that I'm going to implement the AWT renderer and
possibly contribute the the PyUI and AnyGUI projects to bring any
missing widgets up to the level needed to implement my client
applets. That's 100% python code, BTW, no extension modules in
Java or C.
I'm wondering if anyway has an interest in pursuing the plugin
route. It does look do-able, but maybe a lot of work. Wouldn't be
so bad if it were broken up among a few interested parties. It would
probably be a snap for me to implement the "Plugin Renderer" for
PyUI along with the AWT one (that is, if I can ever figure out how
plugins draw themselves). Basically, I'm asking if anyone would be
motivated to embed the Python browser into a plugin?
Wanted to pass along my progress, and see if anyone's
interested in the plugin part. If not, I'll probably just focus
on writing
* Jython backend for PyUI
* Zapplet ("Version 1") for Zope
* Docbook applet
* Drawing applet
which is the 20% of the effort that does 80% of the job ;-D.
Cheers,
Terry
--
Terry Hancock ( hancock at anansispaceworks.com )
Anansi Spaceworks http://www.anansispaceworks.com
Chris Liechti
news:mailman.1036618569...@python.org:
> 2) Run as an independent Python application. For convenience,
> this can be configured as a "Helper App" in the browser so it will
> pop up when needed (Renderer already written -- actually a
> choice of them, may require AnyGUI/PyUI contribs).
thats probably a good solution. even sun decided to go this way with Java
Webstart. the "helper app" caches downloaded apps and verifies certificates
etc. but it basicaly just registered a new mime-type in the browser that is
started when a config file is downloaded. such a config is an XML with a
download location for the real app.
so in that case you don't need to write any software that interoperates
with the browser direcly. it's only started by the browser. it has its own
configurator where you can setup the HTTP proxy etc. the only problem is
how to register the mime type. but that's probably much easier to handle
that writing a plugin.
so for a start we could begin with a simple helper app that parses a config
file (passed by the browser) and uses urllib to fetch the application and
then start it.
later there are extending possibilities like certificates, upgradable
library, config tools...
chris
--
Chris <clie...@gmx.net>
Neil Hodgson
> It seems like this would have to mean that the
> "Netscape Methods" would include drawing primitives
> or a canvas object that can be drawn to,
That would be a good way for it to work! But it doesn't :-(
> but I haven't found it yet (Or maybe I'm misunderstanding
> how it works, and the plugin has to talk to the underlying window
> library -- but that seems bizarre and awkward).
The plugin creates a native window and uses platform specific drawing
functions.
> In any case, I figure it means writing a "Netscape Plugin Renderer"
> for PyUI. This would give me option
>
> 3) Run Applet on Python Plugin (Requires embedded python
> plugin -- big project?, Netscape Plugin Renderer for PyUI -- small,
> contribs to AnyGUI and PyUI if needed).
>
> The plugin route is kind of the "high road" though -- very nice result,
> but it clearly requires the most work.
Yes, writing a cross platform plugin is lots of work, especially if you
want it to integrate well into the browser, such as cooperating in sizing
and in event routing including command keys. It is simpler if your plugin
area is a fixed size area that is isolated from the browser.
Neil
Terry Hancock
> > It seems like this would have to mean that the
> > "Netscape Methods" would include drawing primitives
> > or a canvas object that can be drawn to,
>
> That would be a good way for it to work! But it doesn't :-(
Grumble. :-(
> > but I haven't found it yet (Or maybe I'm misunderstanding
> > how it works, and the plugin has to talk to the underlying window
> > library -- but that seems bizarre and awkward).
>
> The plugin creates a native window and uses platform specific drawing
> functions.
Ah well, I guess SDL+PyGame+PyUI can come to the rescue here. At
least the SDL+PyGame renderer is already written. So it's now just a
question of handing that native window to SDL.
Thanks for clearing that up -- now I'm not chasing a wild goose
in the API, anyway.
> Yes, writing a cross platform plugin is lots of work, especially if you
> want it to integrate well into the browser, such as cooperating in sizing
> and in event routing including command keys. It is simpler if your plugin
> area is a fixed size area that is isolated from the browser.
Still interesting, though. I'll probably come back to it after I get the
Jython solution working, which I'm going to tinker with over the weekend.
(Looks like only ~200 lines of python need to be written for that, but I'll
know for sure when I try it). The stand-alone application model shouldn't
require any work at all, except documentation.
Richie Hindle
> Yes, writing a cross platform plugin is lots of work, especially if you
> want it to integrate well into the browser, such as cooperating in sizing
> and in event routing including command keys. It is simpler if your plugin
> area is a fixed size area that is isolated from the browser.
Do you know whether anyone has succeeded in doing this for Scintilla? I'm
working on a web-based Python debugger, and I'd love to allow remote editing
of source code within the browser using Scintilla. A quick Google didn't
turn anything up.
--
Richie Hindle
ric...@entrian.com
Neil Hodgson
> Do you know whether anyone has succeeded
> in doing this for Scintilla? I'm working on a
> web-based Python debugger, and I'd love to
> allow remote editing of source code within the
> browser using Scintilla. A quick Google didn't
> turn anything up.
ActiveState use Scintilla wrapped by a Mozilla plugin in their Komodo
IDE. The plugin works on Win32 and Linux/X. It is not open source. I was one
of the developers and it was not as simple as I expected although some of
that may have been due to the immaturity of Mozilla.
If you have a recent Java installed there is a technology demonstration
of a code editor component written in Java at
http://www.users.bigpond.net.au/nhodgson/SwedeDemo.html
There was a C# version of the code as well but that stopped working with
.NET service pack 1 which increased security.
Neil
Richie Hindle
> ActiveState use Scintilla wrapped by a Mozilla plugin in their Komodo
> IDE. The plugin works on Win32 and Linux/X. It is not open source. I was one
> of the developers and it was not as simple as I expected although some of
> that may have been due to the immaturity of Mozilla.
That's a shame. An open source Scintilla plug-in would be fantastic.
> If you have a recent Java installed there is a technology demonstration
> of a code editor component written in Java at
> http://www.users.bigpond.net.au/nhodgson/SwedeDemo.html
Impressive! (It crashed my browser on the first attempt, but I'm happy
to blame Sun for that 8-)
The SinkWorld website is somewhat vague about licensing - any chance of
this editor being open source?
--
Richie Hindle
ric...@entrian.com
Neil Hodgson
> The SinkWorld website is somewhat vague about licensing - any chance of
> this editor being open source?
It is unlikely that I'll want to put the effort into building and
maintaining the platform layer for Java unless a customer is prepared to pay
for the work. Or if I think (and I don't, currently) that there is enough of
a market to sell the Java version. GUI code requires lots of tedious
platform bug fixing. Reading the jEdit development list shows how hard it is
for a team to support Swing. I do want to release the core data structure
layer of SinkWorld on Java as open source. Once that is done, other people
may decide to write a platform layer just as others have written platform
layers for Scintilla on wxWindows, Fox, and Qt.
Neil