> No, no, no: Not in the context of a web page at all. This is for > real, live, one-on-one tutoring, or, alternatively, for group > teaching / group discussion over the Net.
OK > Currently I am just displaying the JmolApplet in a Window that > is managed by my distributed presentation system. This is because > I already have an "applet loader" that can (basically) load *any* > applet (including the JmolApplet) in a distributed fashion - that is, if > it is loaded from the file system of one participant, my distributed > presentation system sees to it that it gets loaded *locally* from > the machines of *all* other participants as well. (Applet parameters are > taken from a simple Java properties file, so I do not even > have to *parse* anything at all...) Sounds very useful ... and very cool! > Jmol would be a "verrry nice to have" add-on to my existing > distributed presentation system. Even just synchronizing the > *loading* of the *same* molecular model, without further > synchronizing its state upon interactive modification by the > participants, is already a good thing to have - though proper > synchronization of the whole state of that model, over the > whole duration my presentation, would be even better - > so much better in fact that I can *hardly* resist the temptation > to get it: hence my questions... That's fine. I think we can get what you want. >> Have you played with Jmol source code and built the example .java >> viewer application? > > No, not yet. I am somewhat shy about getting too close > to "someone else's" source code ;-) In particular, I *much* > prefer to stick to a solution that does *not* involve (incompatible) > changes to existing code. I also prefer *not* to make use of > knowledge that is not part of an official interface if I can help > it. I suppose I misspoke when I said "Jmol source code". There is a sample Java application that you can compile which loads Jmol into a simple window. It is called examples/Integration.java *If* you get to the point that you want/need to use your own Java application (or your own applet), then you can start building your app from there ... without touching the Jmol source code. > (Such sins will likely come back to haunt me, my experience > tells me.) We have all had such nightmares :-) > But I will now have a closer look at the Jmol source code. > I just felt that someone who already knows Jmol well, as > you certainly do, could stop me *early* from starting to > run in a wrong or unusually difficult direction... > >> Are the distributed copies all displaying the exact image? > > Yes, that's the idea. We are discussing some chemistry problem, > and, in that context, are looking at a molecular model - and > perhaps manipulating it. It's like a virtual classroom, you see > (but no video please! - we cannot afford the network bandwith: > we want most of that for our *audio* links). If we don't see all the > *exact* same presentation, we will find it very difficult to > communicate clearly and succinctly... > >> If so, then the easiest thing will be to blit the entire image around >> ... that may not be what you are looking for ... because it would turn >> this into a rather trivial project :-) > > There is something to that. > ... > However: (1) application sharing is limited to Windows- > Windows cooperation, which is already A Bad Thing in itself. Actually, I was thinking along slightly different lines. Start with Integration.java capture the rgb images as they get rendered. We will call this your 'image server' Then, write a small Java applet/application that runs on the client machines. And broadcast images to them from your 'image server'. > (2) As to the blitting approach more generally: some of my pupils > are connected to the Net via relatively slow dialup-lines. > Since we also want good audio-links, blitting too many raster > images too often does not seem such a wonderful thing to do. Agreed. Moving images in appropriate across a WAN with dial-up users. > If, instead of blitting many images, I just distribute the essentials > of new viewing information (like scale, view direction, translation, > etc. which amounts to a few doubles at worst) after one of > the participants has finished(!) resizing, rotating, or moving a > shared 3D model, and if I "interpolate" between the recipient's > current model state and the new (stable) state received over the > Net, modifying the local 3D model in "slow motion" from current > state to new state, I can get away with *orders*of*magnitude* > fewer bytes transmitted in the process - and still have very nice, > intuitive behavior of the model: (almost) no transmission or image > update delays, no image stuttering, no bad image quality: but the > "real thing" for each and every participant... Correct. > I am well aware that the "market" for my admittedly more difficult > approach to synchronizing the display of molecular models may > go away in the near future: namely, as soon as transfer speed over the > Net improves by at least an order of magnitude for *all* of my pupils. > But I want to do a first-rate tutoring job right *now*: so here is my > problem, and hence my need for your educated guess > as regards the difficulty of what I am hoping to achieve with Jmol > (whether semi-independent Jmol applet, or completely embedded > Jmol "plugin" for my scripted presentation documents). I don't think it will be too hard to do. I can provide you with calls which give you the state of the display. Through a combination of JmolStatusListener enhancements and additional methods to inquire about the state of the transformations. (A note regarding rotations and zooms. I think that it would be very difficult to calculate and send 'deltas' to the current x, y, and z rotations. Instead, we will send the entire rotation matrix every time.) The more I think about this the more I am beginning to think that we should consider embedding this functionality into the base JmolApplet. I don't think it would add too much overhead, and it would allow others to use your distributed teaching method. Let's keep talking. Miguel ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ Jmol-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jmol-users
