OK, that sounds like what I remember. Thanks. Right, you have a long molecule, you aren't concerned about people changing the applet size, so you make a long window to fit, and zoom 100 fits that long profile. I've got that.
Angel wrote: >I hope I can summarize my viewpoint in favour of large being the >default: >If the webpage author decides for a non-square applet, it's because >(s)he has a long molecule. Fitting by default to the shorter >dimension sounds reasonable in general terms, but is a waste of >applet space in rectangular applets. > >Of course, whatever the default is, there's always the option of >forcing "zoomLarge true". So, any decision is not a major problem. > >The resizable window puts forward that such option may not be the >best, but in this case it's the user who will choose **any** >resizement, so that he can see the molecule. > There are two "users" -- the web page designer, and the brower end-user. I was focusing on the end-user; I can see that the reasoning for this change was based on the web page designer who has specifically chosen an applet size based on some characteristic of the application at hand. What happens now -- the reason I noticed this -- is that without changing zoomLarge=false, the end-user experience (in my opinion) is diminished when they are allowed to resize the applet. Say, for example, that the applet is resizable, because it is set proportional to the browser window. As that size changes, the applet size changes, and the molecule has to resize as well. That resize is based on applet dimensions -- one or the other, larger or smaller. If based on the larger, then half of the resizes result in the molecule going off-screen. Automatically. Guaranteed. This was immediately obvious to me when I got that resizing going. And it was totally annoying. I kept losing half my molecule. In my mind it was a bug. Any user will expect that resizing the applet will be like resizing any HTML -- the text/object/whatever-- resizes to stay "in bounds". It's this "smaller dimension" aspect of HTML, I think, that is coming through in my expectations. The "zoomLarge=true" default doesn't deliver this. >I don't object having >small as default, but see no much difference. Regarding the coding, I >really don't appreciate why one option gives more trouble than the >other; > The reason it gives trouble is that the resized popup applet has to get its full state from the originating applet. Now that applet itself only finds out what its size is from the system, after it is in place or after it is resized. The state of the clone MUST be identical to the state of the originating applet -- my hack is not really acceptable. One has to pick a setting for the original applet and apply it to the resizable applet as well, or we have to hack the state script, as I was doing. One simple possibility is that we make it ultra clear to all page developers that if they want to allow for resizing or popups, then they are well advised to make SURE that they set zoomlarge = false for that applet even if that applet itself is not the one that is likely to be resized. That would probably do just fine. Another possibility is that we add "resizable" to the parameters that are automatically given to the applet, based on the width or height having been specified as percents. Then the default zoomLarge could be false if the applet is resizable and true if it is not. This then would not break any old applets, and it would do what I want for resizable ones. The ONE CATCH is when a page applet that is NOT resizable is cloned to one that is -- then the state will be reset to zoomLarge = true when the state is read. > if it's complicating things, then go ahead (I suppose that the >current value of zoomLarge cannot be read and duplicated). >Naive question: if zoomLarge is the default, why has it got to be >removed from the state --I mean, why include it in the state for a >start? > > > zoomLarge must be part of the state because, well, it's a critical part of the state. All defaults are now part of the state, partially so that well-meaning jokers like myself who change a default don't mess up peoples saved states. EVERY tunable variable is now described in the state. That's why the list is so long now. By the way, you can learn a lot about Jmol just reading down that list of settings in any "show state". I suspect the solution is to allow the applet specifically to be indicated by the developer as resizable, either by indicating fractional or percent width or height or by some explicit setting, like: jmolSetResizable() this would become an applet parameter, turn off zoomLarge, at least as a default, and make it possible for, down the road, to even have a menu item that allows a popup window. For that matter, we might even implement creating the popup as an optional menu item, because if Jmol.js knows that the applet could be a popup, then we could just say that those developers who what that option should include JmolPopup.htm in the directory containing their web page. What do you think? Bob > > > >I hope I can summarize my viewpoint in favour of large being the >default: >If the webpage author decides for a non-square applet, it's because >(s)he has a long molecule. Fitting by default to the shorter >dimension sounds reasonable in general terms, but is a waste of >applet space in rectangular applets. Of course, whatever the default is, there's always the option of forcing "zoomLarge true". So, any decision is not a major problem. The resizable window puts forward that such option may not be the best, but in this case it's the user who will choose **any** resizement, so that he can see the molecule. ---------- What happens with the I don't object having small as default, but see no much difference. Regarding the coding, I really don't appreciate why one option gives more trouble than the other; if it's complicating things, then go ahead (I suppose that the current value of zoomLarge cannot be read and duplicated). Naive question: if zoomLarge is the default, why has it got to be removed from the state --I mean, why include it in the state for a start? Miguel wrote: >Bob wrote: > > > > >Angel wrote: > > > >>If the webpage author decides for a non-square applet, it's because >>(s)he has a long molecule. Fitting by default to the shorter >>dimension sounds reasonable in general terms, but is a waste of >>applet space in rectangular applets. >> >> > > >I think that Angel did a good job of summarizing the justification that >was made at the time of the change. > > * If you are using square applets then it doesn't matter. > > * The primary reason for using a rectangular applet is to display a >rectangular molecule. > > * For a rectangular molecule the changed behavior works better. > > >Miguel > > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Jmol-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jmol-developers
