From: Craig T M. <cm...@ch...> - 2012-03-29 03:43:44
|
Bob, I wouldn't be so dismissive of the iPad/iPhone revolution. Clearly the latter looks to be dominating the smart phone market, despite it's higher price tag. It wasn't that long ago that experts were dismissive of Apple overall (or dismissive of mice and the GUI, for that matter). jmol risks being left behind if it is not adapted to a platform with a growing user base. I do appreciate that Apple's omitting Java support has made adapting jmol very challenging, but I would love someone to rise to this challenge - for my own and for jmol's sake. For those of you starting to use iPads in lecture, I do have some colleagues at UMass who have an acceptable kludge, wherein they mirror their laptops onto the iPad and then switch to that when they want to use jmol structures (they can do everything else on the iPad and it is significantly cheaper than the ThinkPads we used to use - not to mention a lot less buggy). If anyone is interested, I can point them to my colleagues. But of course this is not a general solution. I don't yet have an iPad personally, but it's on my list of things to buy next and I have a number of colleagues who are absolutely fanatical. Tomorrow we go to the Dean to pitch an idea that will involve the purchase of 200 iPads, for laboratory and evening exam use. The latter would benefit greatly from jmol adaptation. Anyone game to take this on? Bringing jmol out of Java and into HTML5/OpenGL? Craig Martin UMass Amherst Chemistry PS - my kid's elementary school is 100% Apple. The middle and high school are mixed about 50/50. PPS - conflict of interest statement here - I own Apple stock ;-) > Message: 1 > Date: Fri, 23 Mar 2012 16:42:10 -0500 > From: Robert Hanson <ha...@st...> > Subject: Re: [Jmol-users] "Jmol" for iPads? > To: jmo...@li... > Message-ID: > <CAF_YUvU75p_1P=e6QtvjGnn9h4Vsnd=nyj...@ma...> > Content-Type: text/plain; charset="iso-8859-1" > > Jmol is now portable to the iPad. In principle, at least. The Android port > shows that. But really, developing for the iPad is to develop something > very different in behavior to what you have now, and I think there are > different solutions, then, for that. You can't just take something like > Jmol and expect it to 'run' on the iPad. What you want is something with > the look and feel of an iPad. lots of gestures, no keyboard to speak of, > just the essentials. > > With all the other cheaper options out there, I'm sorry to see high > schools are jumping for another round of Apple-ware. Funny how all the > schools i've been in lately are filled with Windows machines even though a > few years ago it was all Mac. I wonder why..... > > Bob Craig Martin cm...@ch... |
From: Gutow, J. H <gu...@uw...> - 2012-03-29 14:09:05
|
My family has an Ipad we use extensively. However, I mostly agree with Bob. The Ipad/Tablet devices are good for consuming information created by others. Thus I do think they will make significant inroads in the book market. However, the fact that the Ipad makes it difficult to consume certain kinds of web-based content is likely to be a problem long term. Here's how I see it: 1) Why Apple has migrated to the IOS environment. The original MacOS was very tightly controlled (as is IOS) and was relatively easy for Apple to figure out how to provide a seamless and glitzy (for the time) user experience. Eventually, this closed system became a problem and Apple's market share began to decline. That is when OSX was released. Because OSX was based on an open BSD Unix users suddenly had access to all the richness of the more open markets. I believe this temporarily saved the Macintosh. However, the growing success of the open-source movement and the growing maturity of various flavors of LINUX Desktop environments is impacting the market for closed source desktop and server OSes. I think Apple and other companies that sell closed-source OSes are expecting to make less and less money on their desktop and server OSes. They are shifting towards the tablet market. Apple is entering the market in the same way it entered the PC market. Eventually, I suspect they will have to shift towards supporting a broader spectrum of technology and software if their competitors and open source options do, just as they did with the MacOS. 2) I see two initial options for Jmol usage: a) For fixed textbook like presentations, views can be packaged as .pngs or animated .gifs (to show spinning). In many cases Jmol content consists of views that change with the click of a button in a known way (this is not the case for servers that open different data files at user request...see (b)). I could envision modifying my Export-to-Web code so that it would generate a static .png and a spinning .gif of each view. Rather than putting Jmol in the page when the user clicks a button these images would be put in the page with a button to click to "make interactive". If the OS does not support JavaVMs the user would get a simple dialog message. b) On the fly data sets are a little more difficult, but I have already implemented something for the SageMath package. The latest version of JmolData.jar can be run headless on the server to generate image files. I still need to work out generating the animated .gifs. Ideally this would be something we could embed in JmolData.jar, but initially it could be output of image files and then use another package to make them into an animated .gif. 3) We could also investigate a javascript viewer version, that doesn't have capabilities to change a view, but could display it interactively. Like 2b above this puts a lot of potential load on the server and bandwidth. Some random ideas to start discussions.... Jonathan On Mar 29, 2012, at 7:41 AM, jmo...@li... wrote: > Message: 6 > Date: Thu, 29 Mar 2012 07:41:47 -0500 > From: Robert Hanson <ha...@st...> > Subject: Re: [Jmol-users] "Jmol" for iPads? > To: jmo...@li... > Message-ID: > <CAF...@ma...> > Content-Type: text/plain; charset="iso-8859-1" > > On Wed, Mar 28, 2012 at 9:19 PM, Craig T Martin <cm...@ch...>wrote: > >> Bob, >> >> I wouldn't be so dismissive of the iPad/iPhone revolution. Clearly the >> latter looks to be dominating the smart phone market, despite it's higher >> price tag. It wasn't that long ago that experts were dismissive of Apple >> overall (or dismissive of mice and the GUI, for that matter). jmol risks >> being left behind if it is not adapted to a platform with a growing user >> base. I do appreciate that Apple's omitting Java support has made adapting >> jmol very challenging, but I would love someone to rise to this challenge - >> for my own and for jmol's sake. >> >> > It's not that I'm dismissive. Apple appeals strongly to the early adopter > community -- I understand that. But before you jump for a new iPad, read > the reviews of the iPad 3 and do consider the Android tablet instead. My > son and I absolutely love our Samsung, and I can't IMAGINE trading it for > an iPad. It's just hands down a better environment. Apple's a game changer > company, but how much of that fanatical enthusiasm is warranted for that > particular platform when so many other tablet-based options are available > and so more flexible? What exactly is the appeal of a tablet that is so > restrictive when other alternatives are available that let you do what you > really want to do? > > Bob Dr. Jonathan H. Gutow Chemistry Department gu...@uw... UW-Oshkosh Office:920-424-1326 800 Algoma Boulevard FAX:920-424-2042 Oshkosh, WI 54901 http://www.uwosh.edu/facstaff/gutow/ |
From: Otis R. <osr...@ch...> - 2012-03-29 14:45:29
|
I'm saddened by the fact that for the foreseeable future this is dragging us back to the "see the pretty molecule spin" age. In the cases where this is useful (pretty molecules spinning), I agree with Jonathan that there are textbook like presentation options. I would add to Jonathan's suggestions a reminder that Jmol to Collada is now pretty easy via AccuTrans 3D. There is even a batch translation process which works at lightning speed. The Collada files open directly in Mac's Preview in manipulatable form. They also import into iBook Author producing a manipulatable model for iPad. This use of AccuTrans 3D is MUCH better than the more convoluted approach I posted previously. Otis -- Otis Rothenberger ot...@ch... http://chemagic.com > > > a) For fixed textbook like presentations, views can be packaged as .pngs or animated .gifs (to show spinning). In many cases Jmol content consists of views that change with the click of a button in a known way (this is not the case for servers that open different data files at user request...see (b)). I could envision modifying my Export-to-Web code so that it would generate a static .png and a spinning .gif of each view. Rather than putting Jmol in the page when the user clicks a button these images would be put in the page with a button to click to "make interactive". If the OS does not support JavaVMs the user would get a simple dialog message. > |
From: Rzepa, H. S <h....@im...> - 2012-03-29 14:59:38
|
Begin forwarded message: > From: Otis Rothenberger <osr...@ch...> > Subject: Re: [Jmol-users] "Jmol" for iPads? > Date: 29 March 2012 15:44:43 GMT+01:00 > To: <jmo...@li...> > Reply-To: <jmo...@li...> > > I'm saddened by the fact that for the foreseeable future this is dragging us back to the "see the pretty molecule spin" age. In the cases where this is useful (pretty molecules spinning), I agree with Jonathan that there are textbook like presentation options. I would add to Jonathan's suggestions a reminder that Jmol to Collada is now pretty easy via AccuTrans 3D. There is even a batch translation process which works at lightning speed. The Collada files open directly in Mac's Preview in manipulatable form. They also import into iBook Author producing a manipulatable model for iPad. > > This use of AccuTrans 3D is MUCH better than the more convoluted approach I posted previously. Where I think this is NOT going is the basis of Jmol, the underlying data. Its the data that is precious, not the pretty spining molecule, which only implies the presence of such data. Where Jmol almost totally wins out at the moment is the ability for the viewer to access/transform that data if they wish into functional, reusable form. If all there was is a pretty spinning molecule (which is where the text books might be heading) and no life after the spinning, then it would all be a great waste. Where I have not got my head around yet is that with signed Java applets, one can spring out of the sandbox, and re-use the data contents in what ever way one wants. In the Javascript/JSON model, it seems to be rather more difficult to get at that data (and only in ways the author allows) in a readily reusable form. I suspect few if any of the pretty text books will enable any of that aspect, and that would indeed be one step forward, but two back. They just want the user to be a couch potato. |
From: Charles H. S. <cshubert@MIT.EDU> - 2012-03-29 15:08:05
|
Hi Johathan, Could you say more about what "latest version" means, how to run JmolData.jar headless on the server, and how it works as an image generator? This might be a very nice way for me to get the iPad functionality I'm looking for. Thanks, --Chuck On Mar 29, 2012, at 10:08 AM, Gutow, Jonathan H wrote: > The latest version of JmolData.jar can be run headless on the server to generate image files. |
From: Robert H. <ha...@st...> - 2012-03-29 16:24:08
|
I'll let Jonathan explain JmolData. "latest version" means in this context 12.2.19 or 12.3.19, which I've scheduled for imminent release. We just recently realized that one could produce images within this headless mode, so that's why you need the latest version, whether it is 12.2 or 12.3. On Thu, Mar 29, 2012 at 10:07 AM, Charles Harrison Shubert <csh...@mi... > wrote: > Hi Johathan, > > Could you say more about what "latest version" means, how to run > JmolData.jar headless on the server, and how it works as an image > generator? This might be a very nice way for me to get the iPad > functionality I'm looking for. > > Thanks, > > --Chuck > > On Mar 29, 2012, at 10:08 AM, Gutow, Jonathan H wrote: > > > The latest version of JmolData.jar can be run headless on the server to > generate image files. > > > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > Jmol-users mailing list > Jmo...@li... > 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 |
From: Robert H. <ha...@st...> - 2012-04-03 21:49:32
|
Charles, I got headless image generation going. The current release of Jmol, specifically JmolData.jar does it for PNG creation. There was a minor snafu with JPG creation, so that will be in Jmol 12.2.20/12.3.20. I can send you the PHP file I used if you want. Bob -- 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 |
From: Gutow, J. H <gu...@uw...> - 2012-03-29 21:39:30
|
Chuck, As Bob said, latest version means literally the bleeding edge releases 12.2.19 and 12.3.19. I had been using the full-fledged Jmol on as server to generate images and realized that I could lose the server-side GUI if we could figure out how to generate images using a GUI free version of Jmol. JmolData.jar was set up that way for extracting data from molecule files. When I asked Bob about including image file generation he attacked the problem with his usual vigor. Now script commands like "write PNG 'filename.png'" passed to JmolData.jar will write a png file of the view specified by the script even if the server does not have a GUI running. Presently, I'm working on this for the python scripted server that supports the Web interface for the SageMath Package (www.sagemath.org). If you want to see a server running this experimental technology, visit my test server at http://141.233.196.149:8888 Login as: testJmol with a password of: test. This is a very wimpy old computer I keep running for test purposes. Don't expect very fast responses. Anyway, if you click on any of the pages/worksheets listed after you log in, you should see pages that use Jmol to display 3-D objects. The displays initially are static .png images generated by JmolData.jar running on the server. Jmol only becomes live when you click on the "make interactive" button. So the way to do this is generate system calls from your scripting engine like this: java -jar "path to JmolData.jar" -iox -s "path to script that loads molecule and sets view" -J "write 'filename.png'" Jonathan On Mar 29, 2012, at 10:07 AM, Charles Harrison Shubert wrote: > Hi Johathan, > > Could you say more about what "latest version" means, how to run JmolData.jar headless on the server, and how it works as an image generator? This might be a very nice way for me to get the iPad functionality I'm looking for. > > Thanks, > > --Chuck > > On Mar 29, 2012, at 10:08 AM, Gutow, Jonathan H wrote: > >> The latest version of JmolData.jar can be run headless on the server to generate image files. Dr. Jonathan H. Gutow Chemistry Department gu...@uw... UW-Oshkosh Office:920-424-1326 800 Algoma Boulevard FAX:920-424-2042 Oshkosh, WI 54901 http://www.uwosh.edu/facstaff/gutow/ |
From: Jonathan G. <gu...@uw...> - 2012-03-30 02:48:32
|
Uh..Oh...Now I'm embarrassed...this was working....I apologize to anybody who tried this. The server side generation of images seems to be broken again. I hope to have time to chase this over the weekend. However, this means one more problem has been found and can be rectified. I will post again, when there is something working for people to try... Jonathan On Mar 29, 2012, at 4:39 PM, jmo...@li... wrote: > Presently, I'm working on this for the python scripted server that supports the Web interface for the SageMath Package (www.sagemath.org). > > If you want to see a server running this experimental technology, visit my test server at > http://141.233.196.149:8888 > Login as: testJmol with a password of: test. > This is a very wimpy old computer I keep running for test purposes. Don't expect very fast responses. Anyway, if you click on any of the pages/worksheets listed after you log in, you should see pages that use Jmol to display 3-D objects. The displays initially are static .png images generated by JmolData.jar running on the server. Jmol only becomes live when you click on the "make interactive" button. > > So the way to do this is generate system calls from your scripting engine like this: > > java -jar "path to JmolData.jar" -iox -s "path to script that loads molecule and sets view" -J "write 'filename.png'" > > Jonathan Dr. Jonathan H. Gutow Chemistry Department gu...@uw... UW-Oshkosh Office: 920-424-1326 800 Algoma Boulevard FAX:920-424-2042 Oshkosh, WI 54901 http://www.uwosh.edu/facstaff/gutow |
From: Craig T M. <cm...@ch...> - 2012-03-30 13:01:18
|
Wow. I've stepped into (and probably added fuel to) a firestorm. I'd like to suggest that this is not the forum for arguing the merits of iOS vs Android. Some of us are a bit fanatical about iOS (OK, I'm one of them), and some fanatical about Android. But we're all unified in being fanatical about Jmol. I think we can all agree that Jmol should be accessible to as many people on as many platforms as possible. In the days of CHIME, one could write a WEB page that included glorious interactive content, but users who did not install the plug-in (or who were using newer cutting edge browsers, if I remember correctly) were met with an error message. Jmol's biggest advancement (among a huge list of advancements) was fixing that glaring problem. I can write a WEB page with embedded molecules and be assured that every user sees what I want. Alas, we're now revisiting history. One can argue that this is all Apple's fault for not supporting Java, but that won't change reality. We can't simply tell users the equivalent of "well, just stay with Netscape 4.x and everything will be fine." They will use what they use - and we want to reach them all. And as with CHIME, authors will be less inclined to use Jmol if they know that there are significant markets that cannot be reached. So yes, Jmol should run on Android, and yes, it should run on iOS, regardless of where one stands in the platform war... The challenge of open source is "who's going to fix this and how?" Perhaps our discussion should move in that direction? Thanks to everyone for their passions - that's what keeps Jmol dynamic!! Craig Martin cm...@ch... |
From: Robert H. <ha...@st...> - 2012-03-30 13:53:43
|
Absolutely. On Fri, Mar 30, 2012 at 8:01 AM, Craig T Martin <cm...@ch...>wrote: > The challenge of open source is "who's going to fix this and how?" Perhaps > our discussion should move in that direction? > > > -- 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 |
From: Charles H. S. <cshubert@MIT.EDU> - 2012-03-30 22:50:33
|
Maybe the first question is "what needs to be fixed?" Let's assume for the sake of discussion that there is a port of Jmol to iPads to address the need for image updating performance. Let's also assume that Jmol has been factored into UI, scripting, parsing raw source, image calculation, and image rendering components (or libraries) that can be worked on separately. What pieces of the existing Jmol code base would go into each of these iPad components? How would they need to be changed to run on an iPad? --Chuck On Mar 30, 2012, at 9:53 AM, Robert Hanson wrote: Absolutely. On Fri, Mar 30, 2012 at 8:01 AM, Craig T Martin <cm...@ch...<mailto:cm...@ch...>> wrote: The challenge of open source is "who's going to fix this and how?" Perhaps our discussion should move in that direction? -- 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 ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure_______________________________________________ Jmol-users mailing list Jmo...@li... https://lists.sourceforge.net/lists/listinfo/jmol-users |
From: Robert H. <ha...@st...> - 2012-04-01 13:15:21
|
Jmol has, in fact, been factored into all of these areas. That was the Android project. So all Jmol is entirely independent of platform except for calls to a specific "platform" class that inserts whatever platform-specific aspects are required, such as images, fonts, and graphics. So that's not the issue. Obviously we're not talking here about the applet -- the applet is out. Period. You won't be building web pages around Jmol and doing something with them on the iPad. We aren't talking about adding Jmol to a browser viewing Proteopedia, for example. We aren't talking about building links around the applet that script it. (That could be done in Android, but I think probably not on the iPad.) You won't be customizing Jmol to do some specific task -- unless of course you are an iPad developer yourself and are embedding all this in your specific app. So let's not go there. That's way more involved. What we are talking about is a Jmol App. Independent, isolated (like all iPad apps), stand-alone. The real question, in my mind, is this: What is it about a Jmol app that would justify the effort put into creating it? Questions for discussion: Q: If you had a Jmol app on the iPad, what would you do want to do with it? Q: How would you envision getting models into it? Q: What new features would you want implemented that incorporate into the app features of the iPad that are not available on the non-tablet platforms? For example, would you have gestures, and if so, what gestures? Would you use the gyro? (These features are already in Jmol, but are there other features of the iPad that are unique to it that you would want to utilize?) Q: What features of Jmol would you remove to fit the restricted input characteristics of the iPad? For example, What would you use to replace the pop-up menu? How would you activate and navigate that? How would you handle the much lower resolution of a "touch" than a mouse click? How would you handle the single action of "mouse down/up" rather than single/double-click/left/right/ctrl/alt options? I think these are the real issues. A Jmol app for the iPad is not simply a port to another system. It's a totally different interface that could incorporate android-like capabilities of the iPad (gestures, gyro, which are already in Jmol) and perhaps special features of the iPad not in android, if those exist, but also would have to be reduced to the strict limitations of the iPad input mechanisms and Apple app-isolation rules. Bob On Fri, Mar 30, 2012 at 5:50 PM, Charles Harrison Shubert <csh...@mi...>wrote: > Maybe the first question is "what needs to be fixed?" > > Let's assume for the sake of discussion that there is a port of Jmol to > iPads to address the need for image updating performance. Let's also > assume that Jmol has been factored into UI, scripting, parsing raw source, > image calculation, and image rendering components (or libraries) that can > be worked on separately. > > What pieces of the existing Jmol code base would go into each of these > iPad components? How would they need to be changed to run on an iPad? > > --Chuck > > On Mar 30, 2012, at 9:53 AM, Robert Hanson wrote: > > Absolutely. > > On Fri, Mar 30, 2012 at 8:01 AM, Craig T Martin <cm...@ch...>wrote: > >> The challenge of open source is "who's going to fix this and how?" >> Perhaps our discussion should move in that direction? >> >> >> > -- > 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 > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > > http://p.sf.net/sfu/sfd2d-msazure_______________________________________________ > Jmol-users mailing list > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmol-users > > > > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > Jmol-users mailing list > Jmo...@li... > 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 |
From: Craig T M. <cm...@ch...> - 2012-04-02 12:46:12
|
Looking at my comment below out of context, I feel a need to clarify. I am EXTREMELY thankful to the dedicated core who have put so much into the development of Jmol. I have benefitted greatly from the selfless efforts of others. I am also very aware that my request to move Jmol away from Java and to HTML5/OpenGL is not at all trivial. If no one wants to take this on, I will fully understand, and I regret that I do not have the skills to take this on myself. So please don't take this as a demand, but rather as a request/suggestion... As a user, I see this as the next big challenge for Jmol, but I appreciate that it is both big and a challenge. Craig Martin > Message: 2 > Date: Fri, 30 Mar 2012 08:53:35 -0500 > From: Robert Hanson <ha...@st...> > Subject: Re: [Jmol-users] "Jmol" for iPads? > > Absolutely. > > On Fri, Mar 30, 2012 at 8:01 AM, Craig T Martin <cm...@ch...>wrote: > >> The challenge of open source is "who's going to fix this and how?" Perhaps >> our discussion should move in that direction? >> > -- > Robert M. Hanson > Professor of Chemistry |
From: Robert H. <ha...@st...> - 2012-04-02 15:37:34
|
OK, there are really three threads here: 1) Jmol app for the iPad 2) Jmol export of iPad-ready model twiddles that can be embedded in iBooks 3) Jmol applet-equivalent for browsers running in Java-challenged platforms (1) was the discussion I was starting. But now I think that's off track. I guess I don't know if anyone really is interested in that. (2) is easy. Otis showed how that is possible, and we could make it simpler. A Collada exporter is somewhere on my TODO list. Craig, if I hear what you are saying, you're not so much interested in (1) or (2). You are interested in a browser-based scriptable applet, (3). ChemDoodle's experiment is ongoing, and so far it is proving to be marginally effective, as far as I can tell. It is a hybrid of (2) and (3) -- a relatively unscriptable twiddlable model for the browser (with interesting metainformation available from a server). Regarding (3), I'd need to see real-time molecular surface creation, calculation of MOs from wave functions, decent translucency, and effective graphical manipulation of large systems before I would endorse HTML5 as the way to go in general. So I'm hoping the ChemDoodle experiment will continue and we will hear more good stuff from them. The idea of porting 7 Mb of Java code to interpreted JavaScript source, however, is mind numbing. That's just asking for the impossible, I think, in terms of practical performance. (Of course, people said that about Jmol being written in Java, as well...) I'm very interested in hearing more about the practical limitations of HTML5. I don't know why ChemDoodle was crashing with simple rendering of large proteins last time I tried it (last summer, I think), but I will remind those reading this that there is a reason Jmol works so well, and it is mostly because we do NOT use standard graphical toolkits. Is that more to the point? -- 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 |
From: Kevin T. <ke...@ic...> - 2012-04-02 18:02:44
|
I think these are all good points. In order to create a Jmol app for iPads, one would need to completely port the project to Objective-C, no easy task. To publish in Apple's App Store also costs money (99$/year), is very, very complicated and requires constant attention. And regardless of whether such an app would exist, Jmol authors would still need to "recreate" their content to work in these apps; the applets on their websites would still not work. So we are focusing on HTML5/WebGL as the solution. Most of the performance issues with the ChemDoodle Web Components and large proteins have been addressed, and the toolkit should never crash when parsing any sized PDB file at this point. However, when using the backend services, a PDB file may take a while to parse, and our Apache server automatically terminates connections after 60 seconds, resulting in an error. This is due to the fact that our Java backend is based on the ChemDoodle desktop API, and therefore has overhead for working with the GUI and for creating 2D graphics. We are currently in the process of separating this logic out, so that really intensive functions become much more efficient. I should note that our graphics are not limited to just proteins, the ChemDoodle Web Components library handles small molecules, macromolecules, crystals, spectra, and 2D as well as 3D (MOL/PDB/CIF/JCAMP/XYZ). We are also working on surfaces (an experimental API is already included). Maybe this is a good time to really push for an integration of Jmol functionality on our backend though. We are still working on an efficient marching cubes algorithm in Javascript, and until that is complete, we could use Jmol instead. We would just need to know how to call it and export the necessary information. I think with your help, Bob, we could have this in a few days. So hopefully, as the project develops, it will become an easy procedure to substitute ChemDoodle for Jmol as the frontend on platforms that don't support Java. Certainly, we are doing our best to work towards that goal. As with all things, support matters, so if anyone is interested in seeing this project succeed, please help us by giving us suggestions and advice and by mentioning the open source ChemDoodle Web Components to your colleagues and students. On an aside, we are working with eTextbook vendors, so our technologies will be accessible to authors on a number of platforms. So working with us is a good way to get the functionality you want on the devices that you want. -Kevin On Apr 2, 2012, at 11:37 AM, Robert Hanson wrote: > OK, there are really three threads here: > > 1) Jmol app for the iPad > 2) Jmol export of iPad-ready model twiddles that can be embedded in iBooks > 3) Jmol applet-equivalent for browsers running in Java-challenged platforms > > (1) was the discussion I was starting. But now I think that's off track. I guess I don't know if anyone really is interested in that. > > (2) is easy. Otis showed how that is possible, and we could make it simpler. A Collada exporter is somewhere on my TODO list. > > Craig, if I hear what you are saying, you're not so much interested in (1) or (2). You are interested in a browser-based scriptable applet, (3). ChemDoodle's experiment is ongoing, and so far it is proving to be marginally effective, as far as I can tell. It is a hybrid of (2) and (3) -- a relatively unscriptable twiddlable model for the browser (with interesting metainformation available from a server). > > Regarding (3), I'd need to see real-time molecular surface creation, calculation of MOs from wave functions, decent translucency, and effective graphical manipulation of large systems before I would endorse HTML5 as the way to go in general. So I'm hoping the ChemDoodle experiment will continue and we will hear more good stuff from them. The idea of porting 7 Mb of Java code to interpreted JavaScript source, however, is mind numbing. That's just asking for the impossible, I think, in terms of practical performance. (Of course, people said that about Jmol being written in Java, as well...) I'm very interested in hearing more about the practical limitations of HTML5. I don't know why ChemDoodle was crashing with simple rendering of large proteins last time I tried it (last summer, I think), but I will remind those reading this that there is a reason Jmol works so well, and it is mostly because we do NOT use standard graphical toolkits. > > Is that more to the point? > > -- > Robert M. Hanson > Professor of Chemistry > St. Olaf College |
From: Robert H. <ha...@st...> - 2012-04-02 18:32:05
|
On Mon, Apr 2, 2012 at 12:35 PM, Kevin Theisen <ke...@ic...> wrote: > I think these are all good points. In order to create a Jmol app for > iPads, one would need to completely port the project to Objective-C, no > easy task. To publish in Apple's App Store also costs money (99$/year), is > very, very complicated and requires constant attention. And regardless of > whether such an app would exist, Jmol authors would still need to > "recreate" their content to work in these apps; the applets on their > websites would still not work. So we are focusing on HTML5/WebGL as the > solution. > > Most of the performance issues with the ChemDoodle Web Components and > large proteins have been addressed, and the toolkit should never crash when > parsing any sized PDB file at this point. However, when using the backend > services, a PDB file may take a while to parse, and our Apache server > automatically terminates connections after 60 seconds, resulting in an > error. This is due to the fact that our Java backend is based on the > ChemDoodle desktop API, and therefore has overhead for working with the GUI > and for creating 2D graphics. We are currently in the process of separating > this logic out, so that really intensive functions become much more > efficient. > > I should note that our graphics are not limited to just proteins, the > ChemDoodle Web Components library handles small molecules, macromolecules, > crystals, spectra, and 2D as well as 3D (MOL/PDB/CIF/JCAMP/XYZ). We are > also working on surfaces (an experimental API is already included). Maybe > this is a good time to really push for an integration of Jmol functionality > on our backend though. We are still working on an efficient marching cubes > algorithm in Javascript, and until that is complete, we could use Jmol > instead. We would just need to know how to call it and export the necessary > information. I think with your help, Bob, we could have this in a few days. > Marching cubes in JavaScript. Now there's a challenge! Kevin, I think if you want something like that, use JmolData.jar. That's headless and can run any script not involving image creation or font use. So creation of isosurfaces is fine. Jmol's marching cubes algorithm is highly efficient, now processing just about everything "progressively" meaning as a data stream, never actually creating a huge cube of data. It's possible exporting it as some other format would work. Kevin, could you tell us about some of your ideas for scriptability of ChemDoodle? I'm sure that's come a long way since I talked with you last. -- 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 |
From: Kevin T. <ke...@ic...> - 2012-04-02 20:20:35
|
> Marching cubes in JavaScript. Now there's a challenge! Kevin, I think if you want something like that, use JmolData.jar. That's headless and can run any script not involving image creation or font use. So creation of isosurfaces is fine. Jmol's marching cubes algorithm is highly efficient, now processing just about everything "progressively" meaning as a data stream, never actually creating a huge cube of data. It's possible exporting it as some other format would work. Exporting it to a format is not necessary. We just need to send Jmol atoms, and then extract the vertices, normals and mesh connectivity of the surface. That information will be ajaxed down as JSON, and immediately rendered. Is this possible? > > Kevin, could you tell us about some of your ideas for scriptability of ChemDoodle? I'm sure that's come a long way since I talked with you last. I'm sure we will butt heads again on this, but this is a fundamental difference between Jmol and ChemDoodle. Jmol's scripting system is necessary because authors cannot manipulate Java at runtime, and therefore would have no way to programmatically interact with Jmol. The ChemDoodle Web Components library is pure Javascript, and can be manipulated in any way, at any time, including runtime. So a script for the ChemDoodle Web Components is not necessary, but that does not mean an author can't achieve the same behavior in both environments. For instance, a Jmol script call would look like this: jmol.runScript('actionA actionB'); While a ChemDoodle script would look like this: component.actionA(); component.actionB(); It is actually more powerful in Javascript, because any aspect of the functionality may be tweaked this way (for instance, we can rename classes, create subclasses, add in our own functions), and does not require an explicit script language to be developed. Maybe the more pressing issue is the reuse of all the Jmol scripts. And maybe this is worth investigating, a Jmol script parser for ChemDoodle that will do the same actions. Does this make sense? -Kevin On Apr 2, 2012, at 2:31 PM, Robert Hanson wrote: > > > On Mon, Apr 2, 2012 at 12:35 PM, Kevin Theisen <ke...@ic...> wrote: > I think these are all good points. In order to create a Jmol app for iPads, one would need to completely port the project to Objective-C, no easy task. To publish in Apple's App Store also costs money (99$/year), is very, very complicated and requires constant attention. And regardless of whether such an app would exist, Jmol authors would still need to "recreate" their content to work in these apps; the applets on their websites would still not work. So we are focusing on HTML5/WebGL as the solution. > > Most of the performance issues with the ChemDoodle Web Components and large proteins have been addressed, and the toolkit should never crash when parsing any sized PDB file at this point. However, when using the backend services, a PDB file may take a while to parse, and our Apache server automatically terminates connections after 60 seconds, resulting in an error. This is due to the fact that our Java backend is based on the ChemDoodle desktop API, and therefore has overhead for working with the GUI and for creating 2D graphics. We are currently in the process of separating this logic out, so that really intensive functions become much more efficient. > > I should note that our graphics are not limited to just proteins, the ChemDoodle Web Components library handles small molecules, macromolecules, crystals, spectra, and 2D as well as 3D (MOL/PDB/CIF/JCAMP/XYZ). We are also working on surfaces (an experimental API is already included). Maybe this is a good time to really push for an integration of Jmol functionality on our backend though. We are still working on an efficient marching cubes algorithm in Javascript, and until that is complete, we could use Jmol instead. We would just need to know how to call it and export the necessary information. I think with your help, Bob, we could have this in a few days. > > Marching cubes in JavaScript. Now there's a challenge! Kevin, I think if you want something like that, use JmolData.jar. That's headless and can run any script not involving image creation or font use. So creation of isosurfaces is fine. Jmol's marching cubes algorithm is highly efficient, now processing just about everything "progressively" meaning as a data stream, never actually creating a huge cube of data. It's possible exporting it as some other format would work. > > Kevin, could you tell us about some of your ideas for scriptability of ChemDoodle? I'm sure that's come a long way since I talked with you last. > > -- > 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 > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure_______________________________________________ > Jmol-users mailing list > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmol-users |
From: Robert H. <ha...@st...> - 2012-04-02 23:59:43
|
On Mon, Apr 2, 2012 at 3:20 PM, Kevin Theisen <ke...@ic...> wrote: > Marching cubes in JavaScript. Now there's a challenge! Kevin, I think if > you want something like that, use JmolData.jar. That's headless and can run > any script not involving image creation or font use. So creation of > isosurfaces is fine. Jmol's marching cubes algorithm is highly efficient, > now processing just about everything "progressively" meaning as a data > stream, never actually creating a huge cube of data. It's possible > exporting it as some other format would work. > > > Exporting it to a format is not necessary. We just need to send Jmol > atoms, and then extract the vertices, normals and mesh connectivity of the > surface. That information will be ajaxed down as JSON, and immediately > rendered. Is this possible? > > I was thinking that some simple format like write xxx.vrml This is a very simple format that I would think would be easily parsed by your JavaScript. It includes vertices, normals, and faces. Transform{children Transform{translation .449 -.189 .065 children [ Shape { appearance DEF _0 Appearance{material Material{diffuseColor 1 .648 0 transparency 0}} geometry IndexedFaceSet { coord Coordinate { point [ 4.262 1.094 .447 4.262 1.068 .484 4.275 1.068 .447 4.262 1.2 .191 4.338 1.068 .191 ... -5.071 -1.439 .702 -5.087 -1.439 .447 -5.033 -1.439 .191 ] } coordIndex [ 2 0 1 -1 3 0 4 -1 4 0 2 -1 ... 3988 4019 3990 -1 3990 4019 3982 -1 ] solid FALSE normalPerVertex TRUE normal Normal { vector [ .836 .456 .305 .836 .539 .101 .889 .43 .154 ... 3150 3127 3125 -1 3125 3127 3127 -1 3127 3127 3119 -1 ] } } > > Kevin, could you tell us about some of your ideas for scriptability of > ChemDoodle? I'm sure that's come a long way since I talked with you last. > > > I'm sure we will butt heads again on this, but this is a fundamental > difference between Jmol and ChemDoodle. Jmol's scripting system is > necessary because authors cannot manipulate Java at runtime, and therefore > would have no way to programmatically interact with Jmol. The ChemDoodle > Web Components library is pure Javascript, and can be manipulated in any > way, at any time, including runtime. So a script for the ChemDoodle Web > Components is not necessary, but that does not mean an author can't achieve > the same behavior in both environments. > > Ah, well, actually web developers have full access to the Viewer class, so they can do anything with it they want, if they chose to. However, they would never choose to. > Does this make sense? No, sorry, it still doesn't! :) I think I just need a "for instance": I have a page with a ChemDoodle version of caffeine. What do I do in ChemDoodle that would be equivalent to this in Jmol: select {carbon}; color red or rotate x 30 or, I have a protein, let's say 1crn. What would I do in ChemDoodle to do this? select *; wireframe only select {helix}; cartoons only ? Those are pretty simple operations, of course. But I think they are representative of what I'm talking about. Are there any web pages out there using ChemDoodle that have simple scripting like this? Bob > -Kevin > > > On Apr 2, 2012, at 2:31 PM, Robert Hanson wrote: > > > > On Mon, Apr 2, 2012 at 12:35 PM, Kevin Theisen <ke...@ic...>wrote: > >> I think these are all good points. In order to create a Jmol app for >> iPads, one would need to completely port the project to Objective-C, no >> easy task. To publish in Apple's App Store also costs money (99$/year), is >> very, very complicated and requires constant attention. And regardless of >> whether such an app would exist, Jmol authors would still need to >> "recreate" their content to work in these apps; the applets on their >> websites would still not work. So we are focusing on HTML5/WebGL as the >> solution. >> >> Most of the performance issues with the ChemDoodle Web Components and >> large proteins have been addressed, and the toolkit should never crash when >> parsing any sized PDB file at this point. However, when using the backend >> services, a PDB file may take a while to parse, and our Apache server >> automatically terminates connections after 60 seconds, resulting in an >> error. This is due to the fact that our Java backend is based on the >> ChemDoodle desktop API, and therefore has overhead for working with the GUI >> and for creating 2D graphics. We are currently in the process of separating >> this logic out, so that really intensive functions become much more >> efficient. >> >> I should note that our graphics are not limited to just proteins, the >> ChemDoodle Web Components library handles small molecules, macromolecules, >> crystals, spectra, and 2D as well as 3D (MOL/PDB/CIF/JCAMP/XYZ). We are >> also working on surfaces (an experimental API is already included). Maybe >> this is a good time to really push for an integration of Jmol functionality >> on our backend though. We are still working on an efficient marching cubes >> algorithm in Javascript, and until that is complete, we could use Jmol >> instead. We would just need to know how to call it and export the necessary >> information. I think with your help, Bob, we could have this in a few days. >> > > Marching cubes in JavaScript. Now there's a challenge! Kevin, I think if > you want something like that, use JmolData.jar. That's headless and can run > any script not involving image creation or font use. So creation of > isosurfaces is fine. Jmol's marching cubes algorithm is highly efficient, > now processing just about everything "progressively" meaning as a data > stream, never actually creating a huge cube of data. It's possible > exporting it as some other format would work. > > Kevin, could you tell us about some of your ideas for scriptability of > ChemDoodle? I'm sure that's come a long way since I talked with you last. > > -- > 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 > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > > http://p.sf.net/sfu/sfd2d-msazure_______________________________________________ > Jmol-users mailing list > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmol-users > > > > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > Jmol-users mailing list > Jmo...@li... > 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 |
From: Kevin T. <ke...@ic...> - 2012-04-03 14:19:34
|
> > I was thinking that some simple format like > > write xxx.vrml Thanks, I'll look into the Java API later today. Basically, I would like to call it via Java rather than the script. I will definitely have some questions for you, I'll send them offline. > > ? Those are pretty simple operations, of course. But I think they are representative of what I'm talking about. Are there any web pages out there using ChemDoodle that have simple scripting like this? I think we are saying the same thing. We don't have as many convenience actions as Jmol has, but we will be able to improve upon that as development continues. See the following pages for more information on manipulating the ChemDoodle Web Components: http://web.chemdoodle.com/tutorial http://web.chemdoodle.com/tutorial/input-events http://web.chemdoodle.com/tutorial/animations http://web.chemdoodle.com/tutorial/advanced/visual-specifications http://web.chemdoodle.com/tutorial/advanced/working-with-pdb-files -Kevin On Apr 2, 2012, at 7:59 PM, Robert Hanson wrote: > > > On Mon, Apr 2, 2012 at 3:20 PM, Kevin Theisen <ke...@ic...> wrote: >> Marching cubes in JavaScript. Now there's a challenge! Kevin, I think if you want something like that, use JmolData.jar. That's headless and can run any script not involving image creation or font use. So creation of isosurfaces is fine. Jmol's marching cubes algorithm is highly efficient, now processing just about everything "progressively" meaning as a data stream, never actually creating a huge cube of data. It's possible exporting it as some other format would work. > > > Exporting it to a format is not necessary. We just need to send Jmol atoms, and then extract the vertices, normals and mesh connectivity of the surface. That information will be ajaxed down as JSON, and immediately rendered. Is this possible? > > > I was thinking that some simple format like > > write xxx.vrml > > This is a very simple format that I would think would be easily parsed by your JavaScript. It includes vertices, normals, and faces. > > Transform{children Transform{translation .449 -.189 .065 > children [ > Shape { > appearance DEF _0 Appearance{material Material{diffuseColor 1 .648 0 transparency 0}} geometry IndexedFaceSet { > coord Coordinate { > point [ > 4.262 1.094 .447 > 4.262 1.068 .484 > 4.275 1.068 .447 > 4.262 1.2 .191 > 4.338 1.068 .191 > ... > -5.071 -1.439 .702 > -5.087 -1.439 .447 > -5.033 -1.439 .191 > ] > } > coordIndex [ > 2 0 1 -1 > 3 0 4 -1 > 4 0 2 -1 > ... > 3988 4019 3990 -1 > 3990 4019 3982 -1 > ] > solid FALSE > normalPerVertex TRUE > normal Normal { > vector [ > .836 .456 .305 > .836 .539 .101 > .889 .43 .154 > ... > 3150 3127 3125 -1 > 3125 3127 3127 -1 > 3127 3127 3119 -1 > ] > } > } > > > > >> >> Kevin, could you tell us about some of your ideas for scriptability of ChemDoodle? I'm sure that's come a long way since I talked with you last. > > I'm sure we will butt heads again on this, but this is a fundamental difference between Jmol and ChemDoodle. Jmol's scripting system is necessary because authors cannot manipulate Java at runtime, and therefore would have no way to programmatically interact with Jmol. The ChemDoodle Web Components library is pure Javascript, and can be manipulated in any way, at any time, including runtime. So a script for the ChemDoodle Web Components is not necessary, but that does not mean an author can't achieve the same behavior in both environments. > > > Ah, well, actually web developers have full access to the Viewer class, so they can do anything with it they want, if they chose to. However, they would never choose to. > > > Does this make sense? > > No, sorry, it still doesn't! :) I think I just need a "for instance": > > I have a page with a ChemDoodle version of caffeine. > > What do I do in ChemDoodle that would be equivalent to this in Jmol: > > select {carbon}; color red > > or > > rotate x 30 > > or, I have a protein, let's say 1crn. What would I do in ChemDoodle to do this? > > select *; wireframe only > select {helix}; cartoons only > > ? Those are pretty simple operations, of course. But I think they are representative of what I'm talking about. Are there any web pages out there using ChemDoodle that have simple scripting like this? > > > Bob > > > -Kevin > > > On Apr 2, 2012, at 2:31 PM, Robert Hanson wrote: > >> >> >> On Mon, Apr 2, 2012 at 12:35 PM, Kevin Theisen <ke...@ic...> wrote: >> I think these are all good points. In order to create a Jmol app for iPads, one would need to completely port the project to Objective-C, no easy task. To publish in Apple's App Store also costs money (99$/year), is very, very complicated and requires constant attention. And regardless of whether such an app would exist, Jmol authors would still need to "recreate" their content to work in these apps; the applets on their websites would still not work. So we are focusing on HTML5/WebGL as the solution. >> >> Most of the performance issues with the ChemDoodle Web Components and large proteins have been addressed, and the toolkit should never crash when parsing any sized PDB file at this point. However, when using the backend services, a PDB file may take a while to parse, and our Apache server automatically terminates connections after 60 seconds, resulting in an error. This is due to the fact that our Java backend is based on the ChemDoodle desktop API, and therefore has overhead for working with the GUI and for creating 2D graphics. We are currently in the process of separating this logic out, so that really intensive functions become much more efficient. >> >> I should note that our graphics are not limited to just proteins, the ChemDoodle Web Components library handles small molecules, macromolecules, crystals, spectra, and 2D as well as 3D (MOL/PDB/CIF/JCAMP/XYZ). We are also working on surfaces (an experimental API is already included). Maybe this is a good time to really push for an integration of Jmol functionality on our backend though. We are still working on an efficient marching cubes algorithm in Javascript, and until that is complete, we could use Jmol instead. We would just need to know how to call it and export the necessary information. I think with your help, Bob, we could have this in a few days. >> >> Marching cubes in JavaScript. Now there's a challenge! Kevin, I think if you want something like that, use JmolData.jar. That's headless and can run any script not involving image creation or font use. So creation of isosurfaces is fine. Jmol's marching cubes algorithm is highly efficient, now processing just about everything "progressively" meaning as a data stream, never actually creating a huge cube of data. It's possible exporting it as some other format would work. >> >> Kevin, could you tell us about some of your ideas for scriptability of ChemDoodle? I'm sure that's come a long way since I talked with you last. >> >> -- >> 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 >> ------------------------------------------------------------------------------ >> This SF email is sponsosred by: >> Try Windows Azure free for 90 days Click Here >> http://p.sf.net/sfu/sfd2d-msazure_______________________________________________ >> Jmol-users mailing list >> Jmo...@li... >> https://lists.sourceforge.net/lists/listinfo/jmol-users > > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > Jmol-users mailing list > Jmo...@li... > 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 > ------------------------------------------------------------------------------ > Better than sec? Nothing is better than sec when it comes to > monitoring Big Data applications. Try Boundary one-second > resolution app monitoring today. Free. > http://p.sf.net/sfu/Boundary-dev2dev_______________________________________________ > Jmol-users mailing list > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmol-users |
From: Robert H. <ha...@st...> - 2012-04-03 19:46:56
|
I think this question got lost in the lower reaches of my response. It's fine if the answer is, "You can't do that, at least not yet." My point is that the power of Jmol isn't the twiddle factor; it's the scriptability (by people who are chemists, not JavaScript or Java experts). I don't see any reason why one couldn't add a higher-level scripting capability to ChemDoodle. Is the plan really to leave it at the JavaScript level I see on those ChemDoodle web components pages? Bob On Mon, Apr 2, 2012 at 6:59 PM, Robert Hanson <ha...@st...> wrote: > > > > Say I have a page with a ChemDoodle version of caffeine. > > What do I do in ChemDoodle that would be equivalent to this in Jmol: > > select {carbon}; color red > > or > > rotate x 30 > > or, I have a protein, let's say 1crn. What would I do in ChemDoodle to do > this? > > select *; wireframe only > select {helix}; cartoons only > > ? Those are pretty simple operations, of course. But I think they are > representative of what I'm talking about. Are there any web pages out there > using ChemDoodle that have simple scripting like this? > > > Bob -- 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 |
From: Jeff H. <jh...@de...> - 2012-04-03 20:31:29
|
I'm not with you Bob. I checked the ChemDoodle demos (quite nice really) and I see the same kind of functionality as I see on many Jmol sites, radio buttons and such to control the appearance or behavior of a molecule. Are you saying you think this is easier to create using Jmol scripting than it would be using Javascript? I'm not sure I would agree with that. It seems it is easier mostly because of the Jmol.js javascript library that hides much of the complexity. Something similar could be done for the ChemDoodle approach I'm sure. Or am I just missing something? *********************************************** Jeff Hansen Department of Chemistry and Biochemistry DePauw University 602 S. College Ave. Greencastle, IN 46135 jh...@de... *********************************************** On Apr 3, 2012, at 3:46 PM, Robert Hanson wrote: > I think this question got lost in the lower reaches of my response. It's fine if the answer is, "You can't do that, at least not yet." > > My point is that the power of Jmol isn't the twiddle factor; it's the scriptability (by people who are chemists, not JavaScript or Java experts). I don't see any reason why one couldn't add a higher-level scripting capability to ChemDoodle. Is the plan really to leave it at the JavaScript level I see on those ChemDoodle web components pages? > > Bob > > On Mon, Apr 2, 2012 at 6:59 PM, Robert Hanson <ha...@st...> wrote: > > > > Say I have a page with a ChemDoodle version of caffeine. > > What do I do in ChemDoodle that would be equivalent to this in Jmol: > > select {carbon}; color red > > or > > rotate x 30 > > or, I have a protein, let's say 1crn. What would I do in ChemDoodle to do this? > > select *; wireframe only > select {helix}; cartoons only > > ? Those are pretty simple operations, of course. But I think they are representative of what I'm talking about. Are there any web pages out there using ChemDoodle that have simple scripting like this? > > > > Bob > > > -- > 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 > ------------------------------------------------------------------------------ > Better than sec? Nothing is better than sec when it comes to > monitoring Big Data applications. Try Boundary one-second > resolution app monitoring today. Free. > http://p.sf.net/sfu/Boundary-dev2dev_______________________________________________ > Jmol-users mailing list > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmol-users |
From: Paul P. <pau...@ac...> - 2012-04-03 21:14:37
|
@Jeff, Jmol allows to control the display of specific parts of a model by an efficient query language inherited from Rasmol "Select hetero; do whatever; select protein; do whatever; ...". To my use in class, this is a real motivation for using this software compared to a "twiddling" application. In the web chemdoodle app specification, I came on this page : http://web.chemdoodle.com/tutorial/advanced/working-with-pdb-files At the bottom it explains how you can change the display of proteins from the default cartoon. It does not appear to be as easy as a select process. My understanding is that you can have access via javascript to core functionalities, but as Bob puts it, at the moment it involves a sensible amount of coding I have delved into the chemdoodle code for an hybrid Jmol/chemdoodle sketcher project. It gave me the impression of being very well written and thus quite easily hackable. From my perspective, the best solution given all the amount of webpages using Jmol (and still even Chime !) would be to be able to control the display on the 3D canvas through a scripting language allowing selections and more. Paul Le 3 avr. 2012 à 22:07, Jeff Hansen a écrit : > I'm not with you Bob. I checked the ChemDoodle demos (quite nice really) and I see the same kind of functionality as I see on many Jmol sites, radio buttons and such to control the appearance or behavior of a molecule. Are you saying you think this is easier to create using Jmol scripting than it would be using Javascript? I'm not sure I would agree with that. It seems it is easier mostly because of the Jmol.js javascript library that hides much of the complexity. Something similar could be done for the ChemDoodle approach I'm sure. Or am I just missing something? > > > *********************************************** > Jeff Hansen > Department of Chemistry and Biochemistry > DePauw University > 602 S. College Ave. > Greencastle, IN 46135 > jh...@de... > *********************************************** > > > On Apr 3, 2012, at 3:46 PM, Robert Hanson wrote: > >> I think this question got lost in the lower reaches of my response. It's fine if the answer is, "You can't do that, at least not yet." >> >> My point is that the power of Jmol isn't the twiddle factor; it's the scriptability (by people who are chemists, not JavaScript or Java experts). I don't see any reason why one couldn't add a higher-level scripting capability to ChemDoodle. Is the plan really to leave it at the JavaScript level I see on those ChemDoodle web components pages? >> >> Bob >> |
From: Robert H. <ha...@st...> - 2012-04-03 21:44:30
|
I wasn't necessarily trying to say anything. But I'm interested in what those controls can do. Is it limited to a few standard operations like changing overall rendering? I think maybe it's limited to just a few simple operations being simple to implement. At least now. For example, I haven't found a "select" command that lets me do something more interesting with a subset of the atoms. I could be missing it.... On Tue, Apr 3, 2012 at 3:07 PM, Jeff Hansen <jh...@de...> wrote: > I'm not with you Bob. I checked the ChemDoodle demos (quite nice really) > and I see the same kind of functionality as I see on many Jmol sites, radio > buttons and such to control the appearance or behavior of a molecule. Are > you saying you think this is easier to create using Jmol scripting than it > would be using Javascript? I'm not sure I would agree with that. It seems > it is easier mostly because of the Jmol.js javascript library that hides > much of the complexity. Something similar could be done for the ChemDoodle > approach I'm sure. Or am I just missing something? > > > *********************************************** > Jeff Hansen > Department of Chemistry and Biochemistry > DePauw University > 602 S. College Ave. > Greencastle, IN 46135 > jh...@de... > *********************************************** > > > On Apr 3, 2012, at 3:46 PM, Robert Hanson wrote: > > I think this question got lost in the lower reaches of my response. It's > fine if the answer is, "You can't do that, at least not yet." > > My point is that the power of Jmol isn't the twiddle factor; it's the > scriptability (by people who are chemists, not JavaScript or Java experts). > I don't see any reason why one couldn't add a higher-level scripting > capability to ChemDoodle. Is the plan really to leave it at the JavaScript > level I see on those ChemDoodle web components pages? > > Bob > > On Mon, Apr 2, 2012 at 6:59 PM, Robert Hanson <ha...@st...> wrote: > >> >> >> >> Say I have a page with a ChemDoodle version of caffeine. >> >> What do I do in ChemDoodle that would be equivalent to this in Jmol: >> >> select {carbon}; color red >> >> or >> >> rotate x 30 >> >> or, I have a protein, let's say 1crn. What would I do in ChemDoodle to do >> this? >> >> select *; wireframe only >> select {helix}; cartoons only >> >> ? Those are pretty simple operations, of course. But I think they are >> representative of what I'm talking about. Are there any web pages out there >> using ChemDoodle that have simple scripting like this? >> >> >> > Bob > > > -- > 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 > > ------------------------------------------------------------------------------ > Better than sec? Nothing is better than sec when it comes to > monitoring Big Data applications. Try Boundary one-second > resolution app monitoring today. Free. > > http://p.sf.net/sfu/Boundary-dev2dev_______________________________________________ > Jmol-users mailing list > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmol-users > > > > > ------------------------------------------------------------------------------ > Better than sec? Nothing is better than sec when it comes to > monitoring Big Data applications. Try Boundary one-second > resolution app monitoring today. Free. > http://p.sf.net/sfu/Boundary-dev2dev > _______________________________________________ > Jmol-users mailing list > Jmo...@li... > 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 |
From: Kevin T. <ke...@ic...> - 2012-04-03 22:55:01
|
@Paul We do not currently have a querying function, and this is a great idea to add. We have SMARTS support that we can pipe through, however, it will take some work before we can deal with proteins in such a way. The script is irrelevant to this functionality though, as the script in itself wouldn't generate this ability. @Bob Concerning the writing of a high level script on top of Javascript, I believe it is redundant and produces unnecessary overhead. Chemists are quite smart, and we have yet to encounter one that has been unable to use the ChemDoodle API. Our goal is to make the API very clear and easy for chemists to master. ChemDoodle components each have a VisualSpecifications object associated with them that controls the rendering of graphics. As I linked before, you can use this object to control how your graphics appear: http://web.chemdoodle.com/tutorial/advanced/visual-specifications "I think maybe it's limited to just a few simple operations being simple to implement." I'm not sure what you mean by this statement, are you trying to say we are not capable of doing anything more complex? I assure you we have the competence to do so, and the ChemDoodle API is adequately powerful. Regardless, I believe both ChemDoodle and Jmol have weaknesses, and by working together, we can help to achieve the functionality that everyone is requesting. That is my goal. We continue to focus on expanding the ChemDoodle Web Components, and I believe that the experience of the Jmol community will help us to continue in the right direction. What Paul said also reinforced what I stated before, there are many authors that use Jmol script, and I think it's a better idea to try to write a Jmol script parser for ChemDoodle rather than for us to go off and write our own. Personally, I would alway choose the core Javascript interaction over a high level interface, but certainly this type of parser would be very helpful for Jmol users. Bests, Kevin On Apr 3, 2012, at 5:44 PM, Robert Hanson wrote: > I wasn't necessarily trying to say anything. But I'm interested in what those controls can do. Is it limited to a few standard operations like changing overall rendering? I think maybe it's limited to just a few simple operations being simple to implement. At least now. For example, I haven't found a "select" command that lets me do something more interesting with a subset of the atoms. I could be missing it.... > > On Tue, Apr 3, 2012 at 3:07 PM, Jeff Hansen <jh...@de...> wrote: > I'm not with you Bob. I checked the ChemDoodle demos (quite nice really) and I see the same kind of functionality as I see on many Jmol sites, radio buttons and such to control the appearance or behavior of a molecule. Are you saying you think this is easier to create using Jmol scripting than it would be using Javascript? I'm not sure I would agree with that. It seems it is easier mostly because of the Jmol.js javascript library that hides much of the complexity. Something similar could be done for the ChemDoodle approach I'm sure. Or am I just missing something? > > > *********************************************** > Jeff Hansen > Department of Chemistry and Biochemistry > DePauw University > 602 S. College Ave. > Greencastle, IN 46135 > jh...@de... > *********************************************** > > > On Apr 3, 2012, at 3:46 PM, Robert Hanson wrote: > >> I think this question got lost in the lower reaches of my response. It's fine if the answer is, "You can't do that, at least not yet." >> >> My point is that the power of Jmol isn't the twiddle factor; it's the scriptability (by people who are chemists, not JavaScript or Java experts). I don't see any reason why one couldn't add a higher-level scripting capability to ChemDoodle. Is the plan really to leave it at the JavaScript level I see on those ChemDoodle web components pages? >> >> Bob >> >> On Mon, Apr 2, 2012 at 6:59 PM, Robert Hanson <ha...@st...> wrote: >> >> >> >> Say I have a page with a ChemDoodle version of caffeine. >> >> What do I do in ChemDoodle that would be equivalent to this in Jmol: >> >> select {carbon}; color red >> >> or >> >> rotate x 30 >> >> or, I have a protein, let's say 1crn. What would I do in ChemDoodle to do this? >> >> select *; wireframe only >> select {helix}; cartoons only >> >> ? Those are pretty simple operations, of course. But I think they are representative of what I'm talking about. Are there any web pages out there using ChemDoodle that have simple scripting like this? >> >> >> >> Bob >> >> >> -- >> 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 >> ------------------------------------------------------------------------------ >> Better than sec? Nothing is better than sec when it comes to >> monitoring Big Data applications. Try Boundary one-second >> resolution app monitoring today. Free. >> http://p.sf.net/sfu/Boundary-dev2dev_______________________________________________ >> Jmol-users mailing list >> Jmo...@li... >> https://lists.sourceforge.net/lists/listinfo/jmol-users > > > ------------------------------------------------------------------------------ > Better than sec? Nothing is better than sec when it comes to > monitoring Big Data applications. Try Boundary one-second > resolution app monitoring today. Free. > http://p.sf.net/sfu/Boundary-dev2dev > _______________________________________________ > Jmol-users mailing list > Jmo...@li... > 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 > ------------------------------------------------------------------------------ > Better than sec? Nothing is better than sec when it comes to > monitoring Big Data applications. Try Boundary one-second > resolution app monitoring today. Free. > http://p.sf.net/sfu/Boundary-dev2dev_______________________________________________ > Jmol-users mailing list > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmol-users |