>> > I would also want an interactive (event) GUI.
>>Do you mean that you want drive the gui with program-generated events?
> That would be great. No, I meant that the GUI should trap human mouse
> clicks, etc and send them to the calling program
We are getting closer, but I still don't understand exactly what you
mean.
I think Jmol is *already* an interactive "event driven" GUI.
So, what I missing? Or, more correctly, what is Jmol missing in this area?
Maybe I'm reading too much into your question, but do you just want an
event recorder/playback mechanism?
> We need a language and agree on the primitives. The language must
> emulate much (?all) of what a human user does by clicking. The
> scripts could also be machine-generated (?XML) so that programs could
> drive a display. Also the script could log user events and replay
> them.
OK, so you want a new syntax/language. And you want an event recorder.
I am going to take an extreme position to try to uncover the crux of
your issue.
- With the exception of the event recorder, you can do
what you want in Jmol *today*
- The RasMol scripting implementation *today* is a near superset of
the functionality that is available from the GUI
- The only reason it isn't a proper superset is because there is
functionality in Jmol which doesn't exist in Jmol ... I did not
want to introduce new scripting commands without some feedback
from somebody who has more problem space expertise than I do.
For example, there are no script commands for the following Jmol
functionality because the functionality does not exist in RasMol:
* wireframe rotation
* perspective view
* atom styles quickdraw & wireframe
* bond style quickdraw
* playing an animation/vibration
* exporting povray/pdf
* saving files
* turning on/off display of force vectors
* deleting atoms (and I don't like this one anyway :(
- as far as I can think of, *all* other GUI functionality is available
in the scripting language.
Let me try to state it another way .. we could easily substitute almost
all the menu entries so that each menu entry was tied to an underlying
script:
- performance would be fine
- architecturally it would be very clean
- it would draw a clear distinction between the UI and the underlying
functionality
The context in which to do this is the implementation of the event
recorder. Menu events generate "scriptlets" which get recorded as they get
executed.
I know that you don't like the RasMol syntax (or the semantics); I
don't like it either. But the fact is:
- as far as I can tell, more people know it than any other
molecular visualization scripting language
- it is there *today* in Jmol and it *works*
- true, there is no event recorder, but that can be built rather easily
So, all that is left is:
- another syntax for the scripting language
- functionality which does not exist in Jmol today
As I said, I know I have taken an extreme position here. So react and
tell me what you think.
>>I need some specific examples of things that Chime can do that are
>> missing from Jmol.
>>
>>You don't need to send me a long list. Just send me one or two
>> pointers
>> that I can follow.
>
> 2D diagrams (cf JChemPaint). I know that CHIME does spectra. I am NOT
> adding this to your list at present :-)
OK. I know that Egon wants 2D diagrams too.
I did not know that Chime could do 2D diagrams. I will look into it.
> I don't know. I suspect that RasMOL cannot animate dynamics
> calculations as Jmol does
I think you are correct. Therefore, that functionality that is
currently *not* available from the Jmol scripting language.
So we have two options:
1. somebody tells me what syntax they want within the context of
the RasMol *grammer* (and I use that term quite loosely).
In this case it is implemented in a couple of hours followed by
a couple of hours of testing. The infrastructure for the script
compiler/interpreter already exists and adding new commands is
trivial.
2. somebody gives me a whole new "scripting language" to implement,
with a whole new structure. I would be very interested in doing
this, I honestly would.
Unfortunately, I don't think I can contribute very much to the
generation of the language specification, much less drive the
spec generation process. I don't have a good enough understanding
of the problem space.
But I'll be glad to give you plenty of *open/honest/direct*
feedback on the specification.
>> > You must be brave to ask for a shopping list!
>>brave? ... or stupid! :)
> HTH
Don't know what HTH means ... please translate :)
Miguel
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Jmol-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jmol-developers
