but I think that applet in the Jmol is one of the many possible
way to implement the Jmol functionality and create GUI element that support rendering of 3d atomic engines
just like Jmol application
and for me it is valuable only as tutorial, example how thing can be used or put together
basically I don't care what kind of API jmol applet itself has
or application
the probability that I will use applet api is almost 0
I definitely learned a lot from looking at the jmol applet/appl code
and from that point of view they are better than any documentation
and I'm so glad that there are zillions examples of jmol based applets
so I can see what kind of parameters they use and understand better
how I can use things
unfortunately applet's parameter are set (in most cases) via script
so usually I look at the code for every script command I'm interesting
and figure out what is done in Viwer, FileManager, TransformManger and similar
and almost always I can not use Viewer's appropriate methods because they are not accessible
of course I can use reflection, but that's unsafe, because interfaces can be changed and compiler
won't be able to catch those changes (if I use reflection)
Miguel asked me once why not to use script?
and what's wrong with the script?
nothing is wrong with the script
to me using the script in ANY situation is like
to use USPS in the case when all I want that to let to know about something important to my neighbor
yes I can send letter to him, but it would be much better to walk the
few meters to his door and say it in person and having a pleasure to talk
to him :-)
one of the first example when I was literally shocked
that was inability to call findNearestAtomIndex function by myself:
I need to know if user DIDN'T clicked on the any atom
what is wrong with that function?
why it could be harmful to call that function by any user?
it doesn't change any property it's purely informational method (or it should be)
and it's one of many many examples
I asked about that function before but didn't get any satisfactory answer
JmolStatusListener is an only way to know about clicking on the atom
but JmolStatusListener listener is useless in my situation because if user clicked somewhere (but not on the atom)
JmolStatusListener won't call my callback so I used reflection for that:
(in mouselistener added to the component that used in the allocateViewer method as the first parameter )
try{
Method m = null;
Class clazz = jMolViewer.getClass();
while(clazz != null){
m = clazz.getDeclaredMethod("findNearestAtomIndex",new Class[]{int.class,int.class});
if(m != null) break;
clazz = clazz.getSuperclass();
}
if(m != null){
m.setAccessible(true);
return ((Integer)m.invoke(jMolViewer,new Integer[]{new Integer(evt.getX()),new Integer(evt.getY())})).intValue();
}
}catch(Throwable t){
}
(it's possible to do something even more ugly: to set up timer every time user clicked on the component
and wait for some short amount of time: if status listener responded ok, user clicked on the atom
if timer fired event then no user didn't click on the atom)
but that(reflection) is ugly way to accomplish very essential for every 3d model picking functionality
jmol offers one implementation for that via JmolStatusListener (I agree that in most cases it would be ebough)
but that's definitely not enough
(at least in its current state and at least for me)
my bottom line is that it's impossible to forecast all of possible usage of such a great
and complex API as jmol and closing almost everything IMHO is not what I'd expect
from complex API.
one of the possible reason to close API is a worry that in the
multi developers environment it's almost impossible to control all changes
so author (Miguel) wants to be sure that any of his API isn't broken
it's understandable from author's point of view
but completely unacceptable from the developer stand point who need to use that API
I believe that any responsible developer/contributor never will change the code (and especially the API)
without consulting with the author(s) before publishing changes in CVS system
also CVS allows to roll back any changes so it's should not be a big problem
it's inconvenient I agree but not catastrophic,
thanks
On Feb 24, 2005, at 5:55 AM, Bob Hanson wrote:
Dmitry Markman wrote:
our applications are not applets and never will be as far as I know
My point is that I really like your idea of making more of these routines "public" so that when the code is configured as an applet I can use it, too. I don't know if in the application the scripts run asyncronously, but I'm guessing they do. I'm pretty sure the applet/nonapplet issue is one of packaging mostly. (Right, Miguel?) There are quite a few functions already that the applet exposes, but most of these are not valuable to people like me who would like to do some of the things you wish you could do, but specifically in the context of a web page. I think I listed some of those get/set wishes in some previous posting.
Bob Hanson
--
Robert M. Hanson, [EMAIL PROTECTED], 507-646-3107
Professor of Chemistry, St. Olaf College 1520 St. Olaf Ave., Northfield, MN 55057
mailto:[EMAIL PROTECTED] http://www.stolaf.edu/people/hansonr
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Jmol-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jmol-developers
Dmitry Markman
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Jmol-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jmol-developers
