[whislist] the Galleries might be unjared and deposit in a different Git repo

[jgmbenoit]

The Galleries might be unjared and managed in a separate and dedicated Git repository: 1] Lintian complains about jar balls that contain only data files (read without class files); 2] I think that these must be set inside a regular folder tree as for the GTK version of the GUI; 3] the Galleries might be put in a different Git repository to facilitate their maintenance, the involved file being data file rather code source files subject to and maintained by different kind of people and tools.

[porst17]

The galleries are basically PDF files plus meta data. The LaTeX source for the PDF files is located at https://github.com/IMAGINARY/SURFER-Galleries. I put each localized gallery into a separate .jar file. This is to facilitate the testing and deployment of new galleries:

• the translators usually have a bit of a background in writing LaTeX documents, but usually no idea about programming and related things
• SURFER automatically searches for added galleries in the class path. If a new localization is added (e.g. copied into the same folder as the other libs), it will be detected automatically by surfer without recompiling the program.
• being able as a translator to add last minute changes without having to contact the developer is essential in exhibitions (most of the things always happen last-minute there)

Note that there are more translations in https://github.com/IMAGINARY/SURFER-Galleries then there are translations in this repository. I stopped copying over the .jar files at some point, since I did all my deployment via https://github.com/IMAGINARY/SURFER1-installer/ and that's the place where the gallery jars need to be positioned. The current list of jars in this repo is mainly here for testing and bug fixing gallery related issues (see #2 and #3).

Maybe you can provide a guideline, what should be changed and how. This can serve as a basis for the JavaFX 8 based implementation of the UI.

[jgmbenoit]

Your first and third points can be merge with my third point. A Debian (Source) package dedicated to the Galleries must be envisaged: I will focus on this part of the story. Meanwhile, I am not so sure that it is the best idea to jar the Gallery data files: why not just put them in a regular folder tree (as for the GTK version). I would place the data in /usr/share/surfer-alggeo-java/data/gallery/ as is, that is to say, not jared. I would also add the possibility to put the data in different folder trees by the mean of a dedicated environment variable, the default folder trees being ${HOME}/surfer-alggeo-java/, /usr/local/share/surfer-alggeo-java/, /usr/share/surfer-alggeo-java/ .

[porst17]

It actually doesn't matter how the files of the gallery end up in the Java class path. You can add additional files, folders and jar files. If you prefer the files directly on disk for packaging and not inside a jar, that's fine. However, I will keep the jar based galleries as a second option (mainly for our translators).

[jgmbenoit]

Perfect: where is the material supposed to be ?

[porst17]

Currently, all the SurferLocalization_XX.jar files are located in the lib subfolder. And each jar file has to be added to the class path, be it separately or via wildcards. If the jar files are extracted, then the top folder has to be added to the class path. Java packages are represented in the directory structure of the file system (be it on disk or in the jar file) and hence, the a class foo.bar.Main is located in foo/bar/Main.class in the file system. The folder containing foo needs to be in the class path.

[jgmbenoit]

Can we think out of the Java box ? I have in mind to put the data in a regular folder as any regular data. Is it possible to encode a top folder (or top folders) inside the Java code itself ? to grab a list of top folders from an environment variable ?

[porst17]

Look at the main structure of SurferLocalization_en.jar:

de/mfo/jsurfer/fxgui/Impressum_en.png
de/mfo/jsurfer/fxgui/MessagesBundle_en.properties
de/mfo/jsurfer/gallery/fantasy_en.pdf
de/mfo/jsurfer/gallery/record_en.pdf
de/mfo/jsurfer/gallery/tutorial_en.pdf

These 5 files have to be present in all localizations (en has to be changed to the TLLC). You can just extract all jar files to the file system, say /usr/share/surfer-alggeo (or whatever), while preserving the subfolders and then just point the Java runtime to /usr/share/surfer-alggeo, i.e. add /usr/share/surfer-alggeo to the classpath. No need to hard cord anything in Java itself.

You can just set these folders in the scripts you use for starting SURFER in the Debian package (where you have to set the class path anyway!). It would also be possible to specify several locations, e.g. ~/.local/share (not sure if Java can interpret ~, but you get the point), such that the user can easily add localizations without the need for root privileges. The Java runtime will search the folders in the specified order. If the file it searches for is found, it stops. Hence, put the path in the users home in front of the system wide path to give the user the ability to overwrite system wide behavior.

[jgmbenoit]

I got the picture. To be sure: you prefer to add this feature through shell scripting rather than hard coded it.

[porst17]

The whole gallery loading is already implemented via class path setting. Hence, I don't need to change anything in my code to support file system based galleries. The additional paths just have to be added during packaging/deployment.

[jgmbenoit]

In the last package, the wrapper allows to add path (see /usr/share/doc/surfer-alggeo-java/README.Debian and /usr/bin/jsurfer-algeo for further information). Having said that, I think that: 1] the data contain in the MessagesBundle_.properties must be encoded inside the PDF files (see https://github.com/IMAGINARY/SURFER-Galleries/issues/27); 2] a more generic/friendly path than !de/mfo/jsurfer must be set as extra search path: !jsufer sounds as a good choice.