bibleget-i-o / bibleget-openoffice Goto Github PK

so here's what we've got so far for a Linux build:

• the JCEF linux x64 build was built with JDK 11, so trying to use JDK 8 (1.8) will not work, the build will not succeed. Using JDK 11 works but introduces new problems: in order to dynamically load the JCEF native libraries at runtime we can use a reflection hack to reset the System user path and make sure that the path to the JCEF native libraries are in the user path and reset the java.library.path with this new path. However this hack only works with JDK 8, not with JDK 11. For JDK >= 9 there is however another approach using Lookup and MethodHandles (see https://stackoverflow.com/questions/15409223/adding-new-paths-for-native-libraries-at-runtime-in-java). This seems to be working, however the JCEF component is not being initialized...

• studying the sample application provided by the JCEF build for Linux x64 I can see that the LD_LIBRARY_PATH environment variable also needs to be set with the path to the JCEF native libraries. The plugin code is dynamically downloading the JCEF build from a github release and saving it to this folder: System user path + '/.BibleGetPluginOpenOffice/JCEF' . So this path is needed in the LD_LIBRARY_PATH environment variable. Perhaps this is all that is needed to get the JCEF component to work? So how do we set this environment variable? Can we reset it at runtime?

• For testing purposes I tried exporting the LD_LIBRARY_PATH variable in my Ubuntu 20.04 instance (I'm using WSL2 on Windows 10, and using X11 forwarding in order to be able to launch graphical interfaces = Netbeans, Apache OpenOffice...), and I added a System.out.println() in the code to see the value of the LD_LIBRARY_PATH variable. This shows me that the variable now contains paths that weren't in the variable before on the terminal, but it does not contain the path to the JCEF native libraries. So I'm guessing the Ant script in Netbeans is maybe overwriting this variable during the build? So next step to test a solution is perhaps to figure out how to set this variable in the Ant script? Or find a way to overwrite it again at runtime? I tried using the same method used to reset the java.library.path, to try and reset the LD_LIBRARY_PATH variable, but didn't succeed, it seems to generate an exception. And I don't believe it's a recommended approach, environment variables really should be set in the environment before launching a Java runtime and the JDK releases after JDK 8 have been discouraging overwriting these variables at runtime, they started showing warnings to discourage people from using this approach...

Issue #18 can almost be closed. However there is this one issue that needs to be dealt with first. There seems to be some trouble in synchronizing threads when issuing bash commands using ProcessBuilder and ExecutorService. The output of the bash command never completes in the StreamGobbler thread, which is unable to operate on the BibleGetIO.sysPkgsNeeded ArrayList in the main thread. How to deal with this? (more details of who, when, where and what coming soon)

Building on my home laptop has succeeded since I started writing the plugin. Since until now I was the only one involved, I hadn't worried too much about recreating the build environment. However this is useful not only for community collaboration, but also in case the laptop breaks down and I need to recreate the build environment. So I started writing a Wiki page on the repo to document the process.

However, I am actually having trouble not so much getting the build to complete, as I am getting the plugin to run correctly once it's built, on my work PC, when following the steps I'm documenting in the wiki page. This will need to be addressed, the issue needs to be pinned down, before effectively being able to open to any kind of community collaboration!

This is the weirdest thing. The JFrame contains:

• a JPanel with form fields (among which are some JTextFields)
• and a JInternalFrame that contains the JCEF component

The JCEF component only fully initializes when the JFrame becomes visible.
And the JTextFields are then uneditable, unless the JFrame loses and regains focus (click outside of the JFrame and then inside again, or close and open seeing that I don't fully dispose them, they keep their state when I close them).

So we need to find a way to make sure the JTextFields are editable when opening a frame with a JCEF component for the first time. Maybe a callback on JCEF initialized that makes the JFrame lose and regain focus automatically?

I opened a stackoverflow post here: https://stackoverflow.com/q/64622736/394921

when checking the system for installed dependencies, sometimes more than one line is returned for each package, one line contains "installed" and one doesn't, resulting in a number of "not installed" "installed" consecutive strings.
In my current tests, the "installed" string is returned first, which means that the package would already have been removed from the array. So we can check against the array, if the package exists or not...

In order to make for a cleaner and reproducible build environment, it would be desirable to use some dependency management workflow such as Maven or Gradle, in order to be sure that all dependencies are met correctly for each release.

Once the build environment is recreated in a clean and sure manner (see #3 ), we will have to look into implementing a similar toolkit.

I have created a branch to deal with this change.

A number of new UI components and message strings have been added for the upcoming 2.9 release. They need to be localized.

Probably wouldn't be a bad idea to disable the context menu on the JCEF component. No need to "print" or "view source" in these scenarios. Actually we want to avoid direct access to the source to help protect copyright etc...

when installing on linux where LibreOffice is already installed, OpenOffice might not be able to overwrite the soffice soft link in /usr/bin/soffice. In that case, perhaps we should give user feedback and give the choice of redirecting the soft link to openoffice (which is necessary in face for the BibleGet plugin for OpenOffice to work, since we create our own symlink to a launch script...

Now that the functionality for JCEF is created and tested and pretty much complete, we have to move to the next phase of figuring out how to package and distribute the JCEF native libraries and make them available to the java.library.path.

ever since the new "search for verses by keyword" menu item was added, the "about this plugin" menu item is showing in the wrong place. I'm not sure why that is, because I didn't move it in the source code, I simply added the new "search" menu item where it should go... this needs to be looked into

Currently, the Preferences window of the plugin for OpenOffice uses a JTextEditor with HTMLEditorKit provided by swing in order to provide a real time preview of the text formatting of the Bible quotes in HTML+CSS, based on the options selected in the preferences window.

This works kind of ok, but it has a lot of drawbacks. HTMLEditorKit is old technology now. It only supports HTML version 3.2 and CSS2, and it doesn't seem to be getting any new updates any time soon, looking at it's history.
Currently, the preview area is not capable of previewing line-height . It doesn't support either CSS3 or HTML5.

In the meantime I have updated the Google Docs plugin and the Microsoft Word plugin adding an HTML5 canvas element to the preview area which draws out a simulation of the document ruler, in order to preview the right and left indent tabs. This is a nice touch to the preview area. However it is impossible to implement with HTMLEditorKit, which has no support for HTML5.

I'm thinking that maybe the Jave Chrome Embedded Framework could solve this issue. If JCEF can be used in place of HTMLEditorKit, then all of the best web technologies should be available through the components it provides.

Now, OpenOffice on Windows is only 32 bit, so at least for this we would need to use JCEF 32 bit I believe. Which means the OpenOffice plugin builds should probably be differentiated once JCEF is implemented, seeing that JCEF is also platform dependent (different builds for different platforms). So we would have:

1. BibleGet for OpenOffice Win-32, built with JDK 1.8 x86 and JCEF Win32
2. BibleGet for OpenOffice Linux-32, built with JDK 1.8 x86 and JCEF Linux32
3. BibleGet for OpenOffice Linux-64, built with JDK 1.8 x64 and JCEF Linux64
4. BibleGet for OpenOffice MacOS-64, built with JDK 1.8 x64 and JCEF MacOS64

I initially created a JCEF branch in order to test development on this, which has been merged into the master and development branches in the meantime. Development continues on the development branch.

ready made builds of JCEF

https://github.com/jcefbuild/jcefbuild

How to load custom html using a data URI

https://magpcss.org/ceforum/viewtopic.php?f=17&t=14956

Other than regular dashes, any other kind of dash should be accepted so as to avoid unexpected errors (for example when someone copy/pastes a reference query that has an emdash in it).

This has been done already for the Microsoft Word add-on: 055a6e70c6f14d96ba7ffcf9d72b5152edcd2c0a.

And in the API endpoint engine: b658fa93a1f662d7dc61e538395d253504e0580f.

Since OpenOffice on Windows is only 32bit, until now I have only built a 32bit version of the plugin, using 32bit Java.
But I wonder, would it perhaps be useful to build a 64bit version for Linux and MacOS, if users on these platforms are using the 64bit version of OpenOffice? That way we don't oblige them to install a 32bit JRE, they can stick with a 64bit JRE.

Especially if we start implementing JCEF, which not only has 32bit and 64bit versions, but also different builds for different platforms. Instead of releasing a single build, maybe we'll have to start building for different architectures and different platforms, and release multiple builds...

In my latest tests, PNG image files with transparency are supported in the latest Open Office (currently 4.1.7). I wouldn't know how long this has been the case, but we can certainly do away with the BMPs now which use that terrible hack of magenta keying. This should reduce the size of the plugin and avoid artifacting on the menu icons.