Dear Prof. Robert,

Thank you very much for that.

I have something maybe interesting for you. I read from Rich's
blog(http://depth-first.com/articles/2008/07/15/javascript-for-cheminformatics)
that you're interested in AJAX technology used in chemistry.
So I'm thinking, if molecule editor is able
to be written in javascript, no plugin will be required at client
side. We have PubChem server side editor already, but most of the work
is done at server side, client side javascript is just handling simple
tasks such as image downloading and mouse point capturing. If JChemPaint was
ported into javascript, more interactive function such as toggling the
visibility of H atoms can be implemented, rather than displaying a
static image file only. More internet users can enjoy the magic of
chemoinformatics easily, and more websites are willing to add safe
javascript future rather the "thought to be dangerous" Applet.

If your last exposure to JavaScript was in the 1990s, a lot has
changed for the better. Although we can never expect a performance
like Java, it has improved a lot. Large JavaScript applications such
as Gmail and Google Map work very smooth even on five-year-old
computers. With the help of canvas technology, 2D drawing for
JavaScript is also available now. (A demo here
http://ponderer.org/download/canvas_demo/)

I think there's no technical obstacles there, but CDK behinds
JChemPaint is a large
library. Can we make the porting process less painful? GWT in Action,
the book I translated this year seems to be an answer. GWT(Google Web
Toolkit) is a revolutionary toolkit for AJAX development. It allows
source code to be written in Java language but executed as javascript
in a web browser with no plugin needed. A special compiler can compile
Java source code into JavaScript rather than JVM byte code. And JSNI,
an JNI liked native interface, can also fill the gap between GWT Java
code and hand written JavaScript.

Well, if it's just as simple as what I said, there's no need to write
this mail to you, or I should attach "JChemPaint in JavaScript" in this mail.
But the problem is, GWT compiler is not a standard Java compiler. As
JavaScript is set to be the target language, GWT Java code can do
nothing beyond JavaScript's ability, such as local file reading. As
Java code rather than JVM byte code is the source language, no byte
code JAR is allowed in compiler input. A lot of tasks need to be done.

How do you think about it?

Best Regards,

Duan Lian

On Tue, Dec 9, 2008 at 11:50 PM, Robert Hanson <[EMAIL PROTECTED]> wrote:
> Duan Lian,
>
> Your request for a better way to pass an image to an output stream
> gave me an idea. I have now checked in two new methods for Jmol that
> can be accessed by an embedding application or a browser using the
> signed applet:
>
>     Object nullOrBytesOrStringOrErrorMsg =
> jmolViewer.getImageAs(type, quality, width, height, fileName,
> outputStream);
>     String errMsg = jmolViewer.clipImage(textOrNull);
>
> These make it possible for any application -- or for that matter the
> signed applet -- to:
>
>   write text directly to the system clipboard,
>   write the current image directly to the system clipboard,
>   save the image in a file,
>   get the image as a set of bytes or a Base64 JPG string, or
>   send image bytes to an open OutputStream
>
> The key to success is to use viewer.scriptWait(), not viewer.script(),
> prior to calling one of these methods.
> Duan Lian, this should be what you need, and the bonus is that anyone
> can use it and you are not restricted to the PNG file type.
>
> command examples:
>
>     jmol.viewer.scriptWait("load =1crn;cartoons on;set antialiasdisplay");
>     Object nullOrErrorMsg = jmol.viewer.getImageAs("JPG", 75, 300,
> 300, "t75.jpg", null);
>     Object nullOrErrorMsg = jmol.viewer.getImageAs("JPG", 75, 300,
> 300, null, os);
>     Object bytesOrError = jmol.viewer.getImageAs("JPG", 75, 300, 300,
> null, null);
>     Object stringOrError = jmol.viewer.getImageAs("JPG64", 75, 300,
> 500, null, null);
>
>
> version=11.7.18_dev
>
> # new feature: (embedded application method of JmolViewer):
> #
> # public Object viewer.getImageAs(String type,
> #                                 int quality,
> #                                                                 int width,
> #                                                                 int height,
> #                                 String filename,
> #                                 OutputStream outputStream);
> #
> #   allows creation of an image of a given type ("JPG", "JPEG",
> "JPG64", "PNG", "GIF", "PPM")
> #   of a specific quality (-1 indicates default)
> #     0 to 100 for JPG (-1 = default of 75)
> #     0-9 for PNG (-1 = default of 2)
> #   and specific width and height
> #   and returned as byte[] (when fileName = null, os = null)
> #   or sent to an output stream (os != null)
> #   or set to a file (os == null, fileName != null)
> #
> #   return can be String if there is an error.
> #
> #   command sequence, for example:
> #
> #     jmol.viewer.scriptWait("load =1crn;cartoons on;set antialiasdisplay");
> #     Object nullOrErrorMsg = jmol.viewer.getImageAs("JPG", 75, 300,
> 300, "t75.jpg", null);
> #     Object nullOrErrorMsg = jmol.viewer.getImageAs("JPG", 75, 300,
> 300, null, os);
> #     Object bytesOrError = jmol.viewer.getImageAs("JPG", 75, 300,
> 300, null, null);
> #     Object stringOrError = jmol.viewer.getImageAs("JPG64", 75, 300,
> 300, null, null);
> #
> #   this method, like WRITE IMAGE uses the antialiasImage settings
> #
> #   primarily, this is for writing to an OutputStream directly, but
> #   the rest seemed simple to implement along with that.
> #
>
>
> # new feature: (embedded application method of JmolViewer):
> #
> # public String clipImage(String text);
> #
> #   sends image (null parameter) or text to clipboard
> #
>
>
> # new feature: #exitJmol does that.
> # new feature: application -d --debug sets loglevel to 5
> # new feature: application -J --jmolscript1 Jmol script BEFORE -s
> # new feature: application -j --jmolscript2 Jmol script AFTER -s not
> accepting values
>
> #
> # 
> -----------------------------------------------------------------------------
> Bob
>
>
> src
>
> On Sun, Dec 7, 2008 at 2:47 AM, Duan Lian <[EMAIL PROTECTED]> wrote:
>> Robert,
>>
>> Actually I don't know jmol script can write PNG file directly, but
>> it's still not what I want.  What I'm writing is a servlet that takes
>> PDB file content as POST param, and return the binary content of PNG
>> image as response stream. "write image"  script writes directly into a
>> local file. It's possible to use the script to write PNG as a temp
>> file on local disk, and then read it into response stream of HTTP
>> response. But the script is also executed in a unblocked way, so it's
>> still a problem to determine when to read the image file from my local
>> disk.
>>
>> Best Regards,
>> Duan Lian
>>
>>>From: Robert Hanson <[EMAIL PROTECTED]> -  2008-12-06 23:16
>>>Duan Lian,
>>>
>>>Please tell us a bit more about your PDB2PNG renderer. Specifically,
>>>why not just use the capability of Jmol to write PNG files?
>>>You can even do this in command-line mode without ever calling up a
>>>display. Is there something special that you are trying to do, or is
>>>t possible that you didn't realize that Jmol does this already.
>>>
>>>For example:
>>>
>>>load =1crn
>>>cartoons on;color group
>>>write image 500 500 PNG "myfile.png"
>>
>> ------------------------------------------------------------------------------
>> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
>> The future of the web can't happen without you.  Join us at MIX09 to help
>> pave the way to the Next Web now. Learn more and register at
>> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
>> _______________________________________________
>> Jmol-users mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/jmol-users
>>
>
>
>
> --
> Robert M. Hanson
> Professor of Chemistry
> St. Olaf College
> 1520 St. Olaf Ave.
> Northfield, MN 55057
> http://www.stolaf.edu/people/hansonr
> phone: 507-786-3107
>
>
> If nature does not answer first what we want,
> it is better to take what answer we get.
>
> -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
>
> ------------------------------------------------------------------------------
> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
> The future of the web can't happen without you.  Join us at MIX09 to help
> pave the way to the Next Web now. Learn more and register at
> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
> _______________________________________________
> Jmol-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/jmol-users
>

------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
Jmol-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jmol-users

Reply via email to