Some good ideas.
On Jul 7, 2010, at 4:54 PM, Robert Hanson wrote:
> A few more, while we are at it...
>
> id="AnimContrl"
>
> not showing suffix 0,1,2,etc.
Have to check this. We should be keeping track of which is which, thanks.
>
>
>
> JmolColorPickerBox(scriptStr, [0,0,0], 'backbox1', '1')
>
> is the only one that puts ' ' around the number. Probably should remove
> those.
I'll look into it, but I was having a problem with numbers...don't remember
why...
>
> OK, I think for sure looking at the HTML code this produces, that we DO want
> appletID for all those because really they are _jmol-type functions, not
> something to suggest users implement. There's too much necessary stuff around
> them. Perhaps a user function could be created that writes all of this:
None of the formatting below is necessary for the colorpicker box. It is just
necessary for the formatting of the pop-in page.
>
>
> <div><table><tbody><tr><td style="min-width:70px;">background color:</td><td
> style="min-width:70px;"><script type = 'text/javascript'>var scriptStr =
> 'color background $COLOR$;';JmolColorPickerBox(scriptStr, [0,0,0],
> 'backbox0', '0');</script></td></tr></tbody></table></div>
The formatting just makes sure that the table width is OK for the widgets.
This is formatting the user would have to decide on when they set up their
page. And I see we did screw up the capitalization on
JmolColorPickerBox...will fix...
>
> And then that might allow for the appletID to be gotten from jmolSetTarget()
> or the most recent applet written.
We could set it up to accept appletID from jmolSetTarget() if the one provided
is undefined.
>
> By the way, why are we creating the global variable "scriptStr" here instead
> of just executing JmolColorPickerBox with that parameter? I'm trying to get
> us in the mode of not generating unnecessary global variables that might
> interfere with other JavaScript. You know that's a huge pain when that
> happens, especially if it is code created by another application, like this
> is.
I'm confused. I think I'm getting mixed up with java and javascript. Does
using the "var" in front of a variable make it local or global?
>
> I guess I'd suggest the following in Widgets.java:
>
> return "<table><tbody><tr><td style=\"min-width:70px;\">"
> + GT._("background color:")
> + "</td><td style=\"min-width:70px;\"><script type =
> 'text/javascript'>"
> + "var scriptStr = 'color background $COLOR$;';"
> + "JmolColorPickerBox(scriptStr, ["
> + (int)ptRGB.x + "," + (int)ptRGB.y + "," + (int)ptRGB.z
> + "], 'backbox"
> + appletID + "', '" + appletID + "');"
> + "</script></td></tr></tbody></table>";
>
> look like this:
>
> return "<script type =
> 'text/javascript'>jmolBackgroundColorPickerBox();</script>";
>
>
> Simple as that. And then have jmolBackgroundColorPickerBox() create all the
> HTML stuff necessary. (Maybe a default there.)
>
> That to me would be more readable in the HTML and also more similar to what I
> see in Jmol -- a bit of code for each checkbox that I create.
We could define some particular colorpickerboxes. I hadn't thought of that. I
was trying to make something more general.
>
> I think the idea I'm promoting is to have the Jmol application just send the
> essentials -- "we need a box here of this sort" -- to the page and let the
> JavaScript there do all the details. This makes sense to me because it then
> allows more flexibility by the user (who can change the function or
> parameters of jmolBackgroundColorPickerBox if desired at the JavaScript
> level) and by developers (who then don't need to go into the Java to fix the
> JavaScript).
>
> I'll also suggest that there be one JmolWidgets.js that has all the necessary
> code in it for all the widgets. The tiny snippets of code in JmolSpin.js, for
> example, is just getting too fine-grained. As long as the files are small,
> why not just get them all in Widgets.js. I probably suggested this breaking
> them out, but....
I think the idea was that we could put up the separate widgets in the Wiki. If
we are going to include them as a package like Jmol.js, I think you are correct
that it should be one file. I'm inclined to keep them in separate files until
everything is settled and then we can make a combined file that should be
distributed just like Jmol.js.
>
> Finally, I'd like to see these functions allowing the same sort of
> flexibility that the jmolButton() and jmolRadio() functions have -- in that
> they return code instead of writing it if jmolSetDocument(0) has been issued.
I need to look at the code again. I didn't realize this behavior existed.
Sounds useful.
>
> Consider all this just my 2 cents. Really I defer to Jonathan and Angel on
> this.
As usual a worthwhile 2 cents...
Jonathan
Dr. Jonathan H. Gutow
Chemistry Department gu...@uwosh.edu
UW-Oshkosh Office: 920-424-1326
800 Algoma Boulevard FAX:920-424-2042
Oshkosh, WI 54901
http://www.uwosh.edu/facstaff/gutow
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Jmol-developers mailing list
Jmol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-developers
