On Sat, 1 Mar 2003, Miguel wrote:

> >> > 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?

I am not completely familar with the current architecture of Jmol so I may
just be out of date. I want to be able to receive events such as:
- AtomSelectedEvent
- AtomClickedEvent
- MoleculeTransformedEvent, etc.

and for my application to be able to use these. If they are already there,
please excuse me - I was responding with a general shopping list.

>
> 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.
>
My shopping list did not necessarily imply I thought the functionality was
missing - I simply wanted to list those things I wanted. :-)

> 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 :(

I don't like that one either! It would trun Jmol into an editor and that
is a lot of extra work

>  - 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.

I should probably revist the rasmol syntax and see what functionality is
present
>
>
> >> > You must be brave to ask for a shopping list!
> >>brave? ... or stupid! :)
> >    HTH
> Don't know what HTH means ... please translate :)

HopeThisHelps

P.

>
>
> 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

Reply via email to