From: Robert H. <ha...@st...> - 2008-10-07 22:38:16
|
For the record, here's how we resolved the issues that we were having with 11.6.RC18: -- translation en_GB -- commented out in GT.java -- will be back in as soon as we can get those translations spun off out of one large JAR file. I'm hoping Nico can tackle that. -- load "/xxx" --unsigned local applet, signed applet, and app: should work as before (reading from the local drive root directory). --signed web-based applet: will work like the application -- assumes local hard drive is intended. --unsigned web-based applet: should work as for 11.4 (reading from the web drive, because you can't generally use the unsigned web-based applet for reading from the root web directory anyway). This is a compromise. Let's see how it goes. -- problem changing file names in file dialog --should be all set for Mac OS-X users --still a Linux problem? I will check into that tonight; for now a bug, it appears. -- GIF colors --Last night I worked out an algorithm that seems to do a fairly decent job of reducing colors to 256. Do try it. I might experiment some more with that. Animated GIFs should be no problem, if anyone is interested. Bob -- Robert M. Hanson Professor of Chemistry St. Olaf College 1520 St. Olaf Ave. Northfield, MN 55057 http://www.stolaf.edu/people/hansonr phone: 507-786-3107 If nature does not answer first what we want, it is better to take what answer we get. -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900 |
From: Nicolas V. <nve...@gm...> - 2008-10-08 18:53:20
|
On Wed, Oct 8, 2008 at 12:17 AM, Robert Hanson <ha...@st...> wrote: > -- translation en_GB > > -- commented out in GT.java > -- will be back in as soon as we can get those translations spun off out > of one large JAR file. I'm hoping Nico can tackle that. > Hi Bob, What are the conditions for the .jar indexing to work ? If we have a .jar for each language (JmolApplet_i18n_XX.jar), does the indexing work if all the languages classes are in the same namespace ? or do we need to put them in different namespaces ? Nico |
From: Robert H. <ha...@st...> - 2008-10-08 21:19:30
|
They have to be in separate packages. Once one class of a package is accessed, all classes of that package must be loaded. So each has to be in its own package. It's own name space. BUT I have another idea. We don't necessarily have to use the gettext routines for creating classes this way. We could just have have flat property files and load them directly. Like we can do with menus. In essence, read the .po files directly. The class for Catalonian, for example, is 46K uncompressed, 22K compressed. The simple flat list of msgid/msgstr for that is 28K uncompressed. I don't see what the big deal is in creating a class to handle these. It's just a property table, really. Who needs a whole class? For example, we might consider just making the property files and then using a PropertyResourceBundle instead. ( http://java.sun.com/j2se/1.4.2/docs/api/java/util/PropertyResourceBundle.html ). I guess I don't see why it couldn't be simply a file on the host that is read when a language is accessed. If the file isn't there, it just isn't there. No translation. In fact, the signed applet or application could even just load these from sourceforge on the fly if we wanted that. No need to install ever. Bob On Wed, Oct 8, 2008 at 1:40 PM, Nicolas Vervelle <nve...@gm...>wrote: > > > On Wed, Oct 8, 2008 at 12:17 AM, Robert Hanson <ha...@st...> wrote: > >> -- translation en_GB >> >> -- commented out in GT.java >> -- will be back in as soon as we can get those translations spun off out >> of one large JAR file. I'm hoping Nico can tackle that. >> > > Hi Bob, > > What are the conditions for the .jar indexing to work ? > If we have a .jar for each language (JmolApplet_i18n_XX.jar), does the > indexing work if all the languages classes are in the same namespace ? or do > we need to put them in different namespaces ? > > Nico > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Jmol-developers mailing list > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmol-developers > > -- Robert M. Hanson Professor of Chemistry St. Olaf College 1520 St. Olaf Ave. Northfield, MN 55057 http://www.stolaf.edu/people/hansonr phone: 507-786-3107 If nature does not answer first what we want, it is better to take what answer we get. -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900 |
From: Rzepa, H. <h....@im...> - 2008-10-09 08:19:51
|
Egon has just posted download statistics for Jmol to the users list. I suspect Jmol has been embedded in 100s, if not 1000s (or even 10Ks worth) of journal pages. I also suspect that there must be a very wide spread of versions in that embedding, possibly going back to Jmol 10 and even earlier. My experience is that Jmol has excellent backward compatibility, and that there is a high probability that the most recent Jmol is likely to work with many of these "legacy" sites. However, all the journals where Jmol is embedded have no sensible mechanism of any kind to "update" the Jmol on their servers, if they should wish to do so. The advantages would be that even old pages (ie 5+ years old?) would gain new features (we assume nothing breaks, perhaps a dangerous assumption?). I am having difficulty envisaging any sensible update mechanism which could be implemented, but at very least, I wonder whether Jmol could have some sort of alerting mechanism indicating what the version being used is vs what the latest released version might be? I agree such an alert is not so much for the benefit of the reader, but of the administrator who manages the relevant page. Much modern software does this, and some even highly automates the process of updating itself (armed of course with suitable authentication). I dont think those mechanisms could be applied to eg Web servers, but perhaps someone might know of any developments in this area? Has anyone actively maintained any sort of list which details what features might have been once supported, but no longer work at all? -- Henry Rzepa. +44 (020) 7594 5774 (Voice); http://www.ch.ic.ac.uk/rzepa/rzepa.xrdf (FOAF) http://www.ch.ic.ac.uk/rzepa/ Dept. Chemistry, Imperial College London, SW7 2AZ, UK. (Voracious anti-spam filter in operation for received email. If expected reply not received, please phone/fax). |
From: Rolf H. <rh...@fl...> - 2008-10-09 11:03:29
|
Rzepa, Henry wrote: > Egon has just posted download statistics for Jmol to the users list. > > I suspect Jmol has been embedded in 100s, if not 1000s (or even 10Ks worth) of journal pages. I also suspect that there must be a very wide spread of versions in that embedding, possibly going back to Jmol 10 and even earlier. My experience is that Jmol has excellent backward compatibility, and that there is a high probability that the most recent Jmol is likely to work with many of these "legacy" sites. > > However, all the journals where Jmol is embedded have no sensible mechanism of any kind to "update" the Jmol on their servers, if they should wish to do so. The advantages would be that even old pages (ie 5+ years old?) would gain new features (we assume nothing breaks, perhaps a dangerous assumption?). I am having difficulty envisaging any sensible update mechanism which could be implemented, but at very least, I wonder whether Jmol could have some sort of alerting mechanism indicating what the version being used is vs what the latest released version might be? I agree such an alert is not so much for the benefit of the reader, but of the administrator who manages the relevant page. Much modern software does this, and some even highly automates the process of updating itself (armed of course with suitable authentication). I dont think those mechanisms could be applied to eg Web servers, but perhaps someone might know of any developments in this area? > I don't think that an automated updating mechanism would be a good thing. I am working now since more than 20 years intensively with computers. And one thing I learned from that is that most of the time there are at least some things worse than before (e.g. important features removed or unfortunately changed). And there are also almost always introduced new bugs. So the first thing I switch off after installing a new software is the automatic update function. And normally also the update notification. (An exception from this are security relevant bug-fixes.) And with Jmol these notifications would only be annoying for the users because they couldn't do anything about it anyway, only the site administrators. Although I must admit that Jmol is one of the good examples in this respect there were a lot of changes within Jmol during the past 3 years that broke our Jmol site for some or all PDB entries. Some of these issues were fixed on the Jmol side, others on our side. And not all of them were detected before the new Jmol version was installed in the publicly available version of our Jmol interface. Essentially this means: it is a lot of work for the administrator of a Jmol site to ensure that everything is still working with a newer Jmol version (depending of course on the complexity of the site). So I rather stick to a system administrator guideline I learned: "Never change a running system!" (if it is not absolutely necessary). > Has anyone actively maintained any sort of list which details what features might have been once supported, but no longer work at all? I don't have a list, but there are some changes I remember. The output of "show orientation" and "show boundbox" was changed severely at some point. This would break sites that parse these information. Other things that might be problematic are changes in default settings. One of the more prominent changes was "set perspectivedepth 11". As a result the effect of zoom factors drastically changed. So this might affect predefined views severely. Regards, Rolf |
From: A. H. <ang...@ua...> - 2008-10-09 11:10:20
|
A few comments/ideas raised by Henry's post: > I also suspect that there must be a very wide spread of versions in that embedding, possibly going back to Jmol 10 and even earlier. My experience is that Jmol has excellent backward compatibility, and that there is a high probability that the most recent Jmol is likely to work with many of these "legacy" sites. There was at least a couple of breaking changes between 10.00 and 11.0. Right now, I remember two: hydrogen bonds (which now require a prior "calculate" command) and "set zoomLarge". These broke my pages when I did the update, so a general, blind update of Jmol version is something I would not recommend. > However, all the journals where Jmol is embedded have no sensible mechanism of any kind to "update" the Jmol on their servers, if they should wish to do so. The advantages would be that even old pages (ie 5+ years old?) would gain new features (we assume nothing breaks, perhaps a dangerous assumption?). (See above). Another point is that some simple pages benefit from a smaller applet and a MUCH simpler popup menu, while not needing the new features. In other cases, I agree it would be good to gain new features, among them the localization (e.g. 10.00 had no Spanish interface). > I am having difficulty envisaging any sensible update mechanism which could be implemented, but at very least, I wonder whether Jmol could have some sort of alerting mechanism indicating what the version being used is vs what the latest released version might be? I agree such an alert is not so much for the benefit of the reader, but of the administrator who manages the relevant page. A possible way for that would be the pop-up menu. Some programs put their "there is an update available" in the About menu entry. I'm not sure though about whether this is technically feasible --and it would certainly not affect the existing base of old versions-- and whether it would really be much useful in practice. > Much modern software does this, and some even highly automates the process of updating itself (armed of course with suitable authentication). I dont think those mechanisms could be applied to eg Web servers I don't think so either. And see the cavet above, really any version update needs human supervision so that scripts are not broken. > Has anyone actively maintained any sort of list which details what features might have been once supported, but no longer work at all? Not really. We could try and build it communally on the Wiki. (When you remember or find one issue, you go and write it down there). I'll open a section... There it is: Wiki home page > Documentation box > Backward compatibility http://wiki.jmol.org/index.php/Backward_compatibility |
From: Nicolas V. <nve...@gm...> - 2008-10-09 12:30:21
|
Hi, On Wed, Oct 8, 2008 at 11:19 PM, Robert Hanson <ha...@st...> wrote: > They have to be in separate packages. Once one class of a package is > accessed, all classes of that package must be loaded. So each has to be in > its own package. It's own name space. > Ok, it's easy to do by putting each translation in a sub package using the language name. I did it yesterday evening in a few minutes, the only thing that I still need to do is to modify build.xml to create JmolApplet_i18n_xx.jar files instead of JmolApplet_i18n.jar. > BUT > > I have another idea. > > We don't necessarily have to use the gettext routines for creating classes > this way. We could just have have flat property files and load them > directly. Like we can do with menus. In essence, read the .po files > directly. > > The class for Catalonian, for example, is 46K uncompressed, 22K compressed. > The simple flat list of msgid/msgstr for that is 28K uncompressed. I don't > see what the big deal is in creating a class to handle these. It's just a > property table, really. Who needs a whole class? > > For example, we might consider just making the property files and then > using a PropertyResourceBundle instead. ( > http://java.sun.com/j2se/1.4.2/docs/api/java/util/PropertyResourceBundle.html > ). > > I guess I don't see why it couldn't be simply a file on the host that is > read when a language is accessed. If the file isn't there, it just isn't > there. No translation. > > In fact, the signed applet or application could even just load these from > sourceforge on the fly if we wanted that. No need to install ever. > > Bob > I think it requires more work to do this and a few problems to solve : * parsing all the specific situations of a .po file : fuzzy, java-format, translations on several lines, ... * writing a correct .properties file when msgid contains special characters (like '=') * PropertyResourceBundle are not so nice, they tend to send a lot of requests to the webserver I'd like to try the multiple JmolApplet_i18n_xxx.jar files before going on with more development. Nico |
From: Robert H. <ha...@st...> - 2008-10-09 13:28:48
|
Henry, I think there has to be a balance between allowing new features and preserving the integrity of the initial publication. The nightmare of some upgrade breaking a published work is disturbing. An author has published what they published. I'm not sure it would be appropriate to automatically add new functionality to that. However, the new Jmol.js allows for "customized" upgrades. That is, if a developer/publisher/author uses the newer Jmol.js, then any (knowledgeable) user can substitute in any signed Jmol jar file using the ?JMOLJAR=..... option and bring the original work up to the latest capabilities. This of course is a compromise, as it requires some knowledge on the user's part or some additional work on the publisher's part, but it does make for an interesting option. Bob On Thu, Oct 9, 2008 at 3:14 AM, Rzepa, Henry <h....@im...> wrote: > Egon has just posted download statistics for Jmol to the users list. > > I suspect Jmol has been embedded in 100s, if not 1000s (or even 10Ks > worth) of journal pages. I also suspect that there must be a very wide > spread of versions in that embedding, possibly going back to Jmol 10 and > even earlier. My experience is that Jmol has excellent backward > compatibility, and that there is a high probability that the most recent > Jmol is likely to work with many of these "legacy" sites. > > However, all the journals where Jmol is embedded have no sensible > mechanism of any kind to "update" the Jmol on their servers, if they should > wish to do so. The advantages would be that even old pages (ie 5+ years > old?) would gain new features (we assume nothing breaks, perhaps a dangerous > assumption?). I am having difficulty envisaging any sensible update > mechanism which could be implemented, but at very least, I wonder whether > Jmol could have some sort of alerting mechanism indicating what the version > being used is vs what the latest released version might be? I agree such > an alert is not so much for the benefit of the reader, but of the > administrator who manages the relevant page. Much modern software does this, > and some even highly automates the process of updating itself (armed of > course with suitable authentication). I dont think those mechanisms could > be applied to eg Web servers, but perhaps someone might know of any > developments in this area? > > Has anyone actively maintained any sort of list which details what > features might have been once supported, but no longer work at all? > -- > > Henry Rzepa. > +44 (020) 7594 5774 (Voice); http://www.ch.ic.ac.uk/rzepa/rzepa.xrdf(FOAF) > http://www.ch.ic.ac.uk/rzepa/ Dept. Chemistry, Imperial College London, > SW7 2AZ, UK. > > (Voracious anti-spam filter in operation for received email. > If expected reply not received, please phone/fax). > > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Jmol-developers mailing list > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmol-developers > -- Robert M. Hanson Professor of Chemistry St. Olaf College 1520 St. Olaf Ave. Northfield, MN 55057 http://www.stolaf.edu/people/hansonr phone: 507-786-3107 If nature does not answer first what we want, it is better to take what answer we get. -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900 |
From: Robert H. <ha...@st...> - 2008-10-09 13:40:33
|
OK, that sounds fine. We'll go with multiple JAR files. As I recall, we need to: 1) just include all subdirectory business in Jmol.jar and JmolApplet.jar (no changes there?) 2) JmolApplet0.jar and JmolAppletSigned0.jar -- We need to check to see if we need separate manifests for each translation. I'm not sure. Maybe not. The main thing is to get <indexjars> set up for both signed and unsigned jars. 3) make sure each jar gets signed. Let's do this with a list. Should have been done already with all the other JAR files, but I didn't get around to it. I can easily enough test this on my machine to see if the proper jar files are being loaded from the server. Bob On Thu, Oct 9, 2008 at 7:00 AM, Nicolas Vervelle <nve...@gm...>wrote: > Hi, > > On Wed, Oct 8, 2008 at 11:19 PM, Robert Hanson <ha...@st...> wrote: > >> They have to be in separate packages. Once one class of a package is >> accessed, all classes of that package must be loaded. So each has to be in >> its own package. It's own name space. >> > > Ok, it's easy to do by putting each translation in a sub package using the > language name. > I did it yesterday evening in a few minutes, the only thing that I still > need to do is to modify build.xml to create JmolApplet_i18n_xx.jar files > instead of JmolApplet_i18n.jar. > > > >> BUT >> >> I have another idea. >> >> We don't necessarily have to use the gettext routines for creating classes >> this way. We could just have have flat property files and load them >> directly. Like we can do with menus. In essence, read the .po files >> directly. >> >> The class for Catalonian, for example, is 46K uncompressed, 22K >> compressed. The simple flat list of msgid/msgstr for that is 28K >> uncompressed. I don't see what the big deal is in creating a class to handle >> these. It's just a property table, really. Who needs a whole class? >> >> For example, we might consider just making the property files and then >> using a PropertyResourceBundle instead. ( >> http://java.sun.com/j2se/1.4.2/docs/api/java/util/PropertyResourceBundle.html >> ). >> >> I guess I don't see why it couldn't be simply a file on the host that is >> read when a language is accessed. If the file isn't there, it just isn't >> there. No translation. >> >> In fact, the signed applet or application could even just load these from >> sourceforge on the fly if we wanted that. No need to install ever. >> >> Bob >> > > I think it requires more work to do this and a few problems to solve : > * parsing all the specific situations of a .po file : fuzzy, java-format, > translations on several lines, ... > * writing a correct .properties file when msgid contains special characters > (like '=') > * PropertyResourceBundle are not so nice, they tend to send a lot of > requests to the webserver > > I'd like to try the multiple JmolApplet_i18n_xxx.jar files before going on > with more development. > > Nico > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Jmol-developers mailing list > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmol-developers > > -- Robert M. Hanson Professor of Chemistry St. Olaf College 1520 St. Olaf Ave. Northfield, MN 55057 http://www.stolaf.edu/people/hansonr phone: 507-786-3107 If nature does not answer first what we want, it is better to take what answer we get. -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900 |
From: Nicolas V. <nve...@gm...> - 2008-10-09 13:49:41
|
Ok, I will commit some modifications this evening. With the modifications I have made (GT.java and build-i18n.xml), Jmol.jar is working correctly and probably JmolApplet.jar also. I have to modify the build process for the splitted applet jars. I have planned to use a <for> loop for the jars (like in build-i18n.xml) Nico On Thu, Oct 9, 2008 at 3:40 PM, Robert Hanson <ha...@st...> wrote: > OK, that sounds fine. We'll go with multiple JAR files. As I recall, we > need to: > > 1) just include all subdirectory business in Jmol.jar and JmolApplet.jar > (no changes there?) > > 2) JmolApplet0.jar and JmolAppletSigned0.jar -- We need to check to see if > we need separate manifests for each translation. I'm not sure. Maybe not. > The main thing is to get <indexjars> set up for both signed and unsigned > jars. > > 3) make sure each jar gets signed. Let's do this with a list. Should have > been done already with all the other JAR files, but I didn't get around to > it. > > I can easily enough test this on my machine to see if the proper jar files > are being loaded from the server. > > Bob > > > > On Thu, Oct 9, 2008 at 7:00 AM, Nicolas Vervelle <nve...@gm...>wrote: > >> Hi, >> >> On Wed, Oct 8, 2008 at 11:19 PM, Robert Hanson <ha...@st...>wrote: >> >>> They have to be in separate packages. Once one class of a package is >>> accessed, all classes of that package must be loaded. So each has to be in >>> its own package. It's own name space. >>> >> >> Ok, it's easy to do by putting each translation in a sub package using the >> language name. >> I did it yesterday evening in a few minutes, the only thing that I still >> need to do is to modify build.xml to create JmolApplet_i18n_xx.jar files >> instead of JmolApplet_i18n.jar. >> >> >> >>> BUT >>> >>> I have another idea. >>> >>> We don't necessarily have to use the gettext routines for creating >>> classes this way. We could just have have flat property files and load them >>> directly. Like we can do with menus. In essence, read the .po files >>> directly. >>> >>> The class for Catalonian, for example, is 46K uncompressed, 22K >>> compressed. The simple flat list of msgid/msgstr for that is 28K >>> uncompressed. I don't see what the big deal is in creating a class to handle >>> these. It's just a property table, really. Who needs a whole class? >>> >>> For example, we might consider just making the property files and then >>> using a PropertyResourceBundle instead. ( >>> http://java.sun.com/j2se/1.4.2/docs/api/java/util/PropertyResourceBundle.html >>> ). >>> >>> I guess I don't see why it couldn't be simply a file on the host that is >>> read when a language is accessed. If the file isn't there, it just isn't >>> there. No translation. >>> >>> In fact, the signed applet or application could even just load these from >>> sourceforge on the fly if we wanted that. No need to install ever. >>> >>> Bob >>> >> >> I think it requires more work to do this and a few problems to solve : >> * parsing all the specific situations of a .po file : fuzzy, java-format, >> translations on several lines, ... >> * writing a correct .properties file when msgid contains special >> characters (like '=') >> * PropertyResourceBundle are not so nice, they tend to send a lot of >> requests to the webserver >> >> I'd like to try the multiple JmolApplet_i18n_xxx.jar files before going on >> with more development. >> >> Nico >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's >> challenge >> Build the coolest Linux based applications with Moblin SDK & win great >> prizes >> Grand prize is a trip for two to an Open Source event anywhere in the >> world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> Jmol-developers mailing list >> Jmo...@li... >> https://lists.sourceforge.net/lists/listinfo/jmol-developers >> >> > > > -- > Robert M. Hanson > Professor of Chemistry > St. Olaf College > 1520 St. Olaf Ave. > Northfield, MN 55057 > http://www.stolaf.edu/people/hansonr > phone: 507-786-3107 > > > If nature does not answer first what we want, > it is better to take what answer we get. > > -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900 > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Jmol-developers mailing list > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmol-developers > > |
From: Nicolas V. <nve...@gm...> - 2008-10-09 19:38:02
|
Modifications done, it really needs some testing (I haven't tested the applet) Nico On Thu, Oct 9, 2008 at 3:47 PM, Nicolas Vervelle <nve...@gm...>wrote: > Ok, I will commit some modifications this evening. > > With the modifications I have made (GT.java and build-i18n.xml), Jmol.jar > is working correctly and probably JmolApplet.jar also. I have to modify the > build process for the splitted applet jars. > I have planned to use a <for> loop for the jars (like in build-i18n.xml) > Nico > On Thu, Oct 9, 2008 at 3:40 PM, Robert Hanson <ha...@st...> wrote: > >> OK, that sounds fine. We'll go with multiple JAR files. As I recall, we >> need to: >> >> 1) just include all subdirectory business in Jmol.jar and JmolApplet.jar >> (no changes there?) >> >> 2) JmolApplet0.jar and JmolAppletSigned0.jar -- We need to check to see >> if we need separate manifests for each translation. I'm not sure. Maybe not. >> The main thing is to get <indexjars> set up for both signed and unsigned >> jars. >> >> 3) make sure each jar gets signed. Let's do this with a list. Should have >> been done already with all the other JAR files, but I didn't get around to >> it. >> >> I can easily enough test this on my machine to see if the proper jar files >> are being loaded from the server. >> >> Bob >> >> >> >> On Thu, Oct 9, 2008 at 7:00 AM, Nicolas Vervelle <nve...@gm...>wrote: >> >>> Hi, >>> >>> On Wed, Oct 8, 2008 at 11:19 PM, Robert Hanson <ha...@st...>wrote: >>> >>>> They have to be in separate packages. Once one class of a package is >>>> accessed, all classes of that package must be loaded. So each has to be in >>>> its own package. It's own name space. >>>> >>> >>> Ok, it's easy to do by putting each translation in a sub package using >>> the language name. >>> I did it yesterday evening in a few minutes, the only thing that I still >>> need to do is to modify build.xml to create JmolApplet_i18n_xx.jar files >>> instead of JmolApplet_i18n.jar. >>> >>> >>> >>>> BUT >>>> >>>> I have another idea. >>>> >>>> We don't necessarily have to use the gettext routines for creating >>>> classes this way. We could just have have flat property files and load them >>>> directly. Like we can do with menus. In essence, read the .po files >>>> directly. >>>> >>>> The class for Catalonian, for example, is 46K uncompressed, 22K >>>> compressed. The simple flat list of msgid/msgstr for that is 28K >>>> uncompressed. I don't see what the big deal is in creating a class to handle >>>> these. It's just a property table, really. Who needs a whole class? >>>> >>>> For example, we might consider just making the property files and then >>>> using a PropertyResourceBundle instead. ( >>>> http://java.sun.com/j2se/1.4.2/docs/api/java/util/PropertyResourceBundle.html >>>> ). >>>> >>>> I guess I don't see why it couldn't be simply a file on the host that is >>>> read when a language is accessed. If the file isn't there, it just isn't >>>> there. No translation. >>>> >>>> In fact, the signed applet or application could even just load these >>>> from sourceforge on the fly if we wanted that. No need to install ever. >>>> >>>> Bob >>>> >>> >>> I think it requires more work to do this and a few problems to solve : >>> * parsing all the specific situations of a .po file : fuzzy, java-format, >>> translations on several lines, ... >>> * writing a correct .properties file when msgid contains special >>> characters (like '=') >>> * PropertyResourceBundle are not so nice, they tend to send a lot of >>> requests to the webserver >>> >>> I'd like to try the multiple JmolApplet_i18n_xxx.jar files before going >>> on with more development. >>> >>> Nico >>> >>> ------------------------------------------------------------------------- >>> This SF.Net email is sponsored by the Moblin Your Move Developer's >>> challenge >>> Build the coolest Linux based applications with Moblin SDK & win great >>> prizes >>> Grand prize is a trip for two to an Open Source event anywhere in the >>> world >>> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >>> _______________________________________________ >>> Jmol-developers mailing list >>> Jmo...@li... >>> https://lists.sourceforge.net/lists/listinfo/jmol-developers >>> >>> >> >> >> -- >> Robert M. Hanson >> Professor of Chemistry >> St. Olaf College >> 1520 St. Olaf Ave. >> Northfield, MN 55057 >> http://www.stolaf.edu/people/hansonr >> phone: 507-786-3107 >> >> >> If nature does not answer first what we want, >> it is better to take what answer we get. >> >> -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900 >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's >> challenge >> Build the coolest Linux based applications with Moblin SDK & win great >> prizes >> Grand prize is a trip for two to an Open Source event anywhere in the >> world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> Jmol-developers mailing list >> Jmo...@li... >> https://lists.sourceforge.net/lists/listinfo/jmol-developers >> >> > |
From: A. H. <ang...@ua...> - 2008-10-09 20:17:08
|
I've done a local build from revision 10030 and the unsigned applet seems to work OK; opens in Spanish, changes languages from the popup menu withou a hitch (I'd even say that quicker than before). I tried English, French, Portuguese, back to Spanish. However, the app gets hung at the "Initializing recent files..." step in the preload. I don't trust my builds though, so please do not pay much attention to this. On 9 Oct 2008 at 21:37, Nicolas Vervelle wrote: > > Modifications done, it really needs some testing (I haven't tested the applet) |
From: Robert H. <ha...@st...> - 2008-10-09 23:00:55
|
all OK for me. Except I'm having that same problem I've had before with Eclipse not properly indicating which options I've selected for the ant build. I was able nonetheless to get both applets made as well as the application, and everything works as advertised. Each language jar file is read off the server only as needed. However, if a file is missing, then the server is going to send a "no file found" message that is going to cause a Jmol crash. Exception in thread "QueueThread1" java.lang.ClassFormatError: Incompatible magic value 1919250805 in class file org/jmol/translation/JmolApplet/tr/Messages_tr at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(Unknown Source) at java.security.SecureClassLoader.defineClass(Unknown Source) at sun.plugin2.applet.Applet2ClassLoader.findClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClassInternal(Unknown Source) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Unknown Source) at org.jmol.i18n.GT.addBundle(Unknown Source) at org.jmol.i18n.GT.addBundles(Unknown Source) at org.jmol.i18n.GT.getTranslation(Unknown Source) at org.jmol.i18n.GT.<init>(Unknown Source) at org.jmol.applet.Jmol$MyStatusListener.setCallbackFunction(Unknown Source) at org.jmol.viewer.StatusManager.setCallbackFunction(Unknown Source) at org.jmol.viewer.Viewer.setStringProperty(Unknown Source) at org.jmol.viewer.Eval.setStringProperty(Unknown Source) at org.jmol.viewer.Eval.set(Unknown Source) at org.jmol.viewer.Eval.instructionDispatchLoop(Unknown Source) at org.jmol.viewer.Eval.runEval(Unknown Source) at org.jmol.viewer.Viewer.evalStringWaitStatus(Unknown Source) at org.jmol.viewer.ScriptManager$ScriptQueueRunnable.runScript(Unknown Source) at org.jmol.viewer.ScriptManager$ScriptQueueRunnable.runNextScript(Unknown Source) at org.jmol.viewer.ScriptManager$ScriptQueueRunnable.run(Unknown Source) at java.lang.Thread.run(Unknown Source) (Might want to go back to debug=true for Jmol 11.7) That's a real problem, because that code is: try { bundleClass = Class.forName(name_lang); } catch (Exception e) { Logger.error("GT could not find the class " + name_lang); } so why is this error not just being trapped? Is there something about Class.forName() that doesn't allow proper exception handling? Can we use ClassLoader directly to try to check for a class? Could be a problem if the jar files aren't on the server. You'll only know that if someone tries setting a language. Bob On Thu, Oct 9, 2008 at 3:28 PM, Angel Herráez <ang...@ua...> wrote: > I've done a local build from revision 10030 > and the unsigned applet seems to work OK; opens in Spanish, changes > languages from the > popup menu withou a hitch (I'd even say that quicker than before). I tried > English, French, > Portuguese, back to Spanish. > > However, the app gets hung at the "Initializing recent files..." step in > the preload. I don't trust > my builds though, so please do not pay much attention to this. > > > On 9 Oct 2008 at 21:37, Nicolas Vervelle wrote: > > > > > Modifications done, it really needs some testing (I haven't tested the > applet) > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Jmol-developers mailing list > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmol-developers > -- Robert M. Hanson Professor of Chemistry St. Olaf College 1520 St. Olaf Ave. Northfield, MN 55057 http://www.stolaf.edu/people/hansonr phone: 507-786-3107 If nature does not answer first what we want, it is better to take what answer we get. -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900 |
From: Nicolas V. <nve...@gm...> - 2008-10-10 04:52:53
|
On Fri, Oct 10, 2008 at 1:00 AM, Robert Hanson <ha...@st...> wrote: > However, if a file is missing, then the server is going to send a "no file > found" message that is going to cause a Jmol crash. > Not good. Since we have the list of languages in GT, we could try to get the file only if we know the language. That will remove some unecessary calls to the server. > That's a real problem, because that code is: > > try { > bundleClass = Class.forName(name_lang); > } catch (Exception e) { > Logger.error("GT could not find the class " + name_lang); > } > > > so why is this error not just being trapped? Is there something about > Class.forName() that doesn't allow proper exception handling? Can we use > ClassLoader directly to try to check for a class? > ClassFormatError is not an Exception, but an Error. We should catch Throwable instead of Exception, that would do the trick. Nico |
From: Robert H. <ha...@st...> - 2008-10-10 13:25:41
|
Ah, missed this message. Maybe that's all there is to it. OK. We do check to see that we are only loading languages that are on the list. So maybe this is all we need. On Thu, Oct 9, 2008 at 11:52 PM, Nicolas Vervelle <nve...@gm...>wrote: > > > On Fri, Oct 10, 2008 at 1:00 AM, Robert Hanson <ha...@st...> wrote: > >> However, if a file is missing, then the server is going to send a "no file >> found" message that is going to cause a Jmol crash. >> > > Not good. > Since we have the list of languages in GT, we could try to get the file > only if we know the language. > That will remove some unecessary calls to the server. > > > >> That's a real problem, because that code is: >> >> try { >> bundleClass = Class.forName(name_lang); >> } catch (Exception e) { >> Logger.error("GT could not find the class " + name_lang); >> } >> >> >> so why is this error not just being trapped? Is there something about >> Class.forName() that doesn't allow proper exception handling? Can we use >> ClassLoader directly to try to check for a class? >> > > ClassFormatError is not an Exception, but an Error. We should catch > Throwable instead of Exception, that would do the trick. > > Nico > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Jmol-developers mailing list > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmol-developers > > -- Robert M. Hanson Professor of Chemistry St. Olaf College 1520 St. Olaf Ave. Northfield, MN 55057 http://www.stolaf.edu/people/hansonr phone: 507-786-3107 If nature does not answer first what we want, it is better to take what answer we get. -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900 |