Since a while, LibreOffice publishes Flatpaks for download, to allow users an easy upgrade path on distributions shipping out-dated versions. However, when I start JabRef and click {Tools > OpenOffice/LibreOffice connection > Connect} as [described in the manual][LINK IN NEXT POST, SINCE NEW USERS ARE RESTRICTED TO ONLY TWO LINKS PER POST], JabRef cannot find the running LibreOffice. It would be great if JabRef would have a way to also detect an installation using Flatpak.
It should be possible to get the path to the installation using flatpak info org.libreoffice.LibreOffice. Actually making it work might require working together with the LibreOffice community, since they currently do not ship the JARs in the Flatpak (or I could not find them – JabRef mentions only that it could not find the JARs, but never mentioned which ones it searched for).
Hi,
Thank you very much for reporting this and looking into this and filing a bug report at LO.
I think at the moment this is more a problem of Libre Office than of JabRef, (the missing jars), but we will also look into this and see if we can add a check for LO flatpak.
When external (C++ or Java) programs want to communicate with LO via the UNO Remote Protocol (URP), those programs need access to certain libraries (C++ dynamic libraries or Java jars, resp.) and helper data and code files (e.g., even in the case of Java jars, these reference native code that is implemented in helper native dynamic libraries; see https://wiki.openoffice.org/wiki/Documentation/DevGuide/OpenOffice.org_Developers_Guide for details on all this).
LO includes all these files, so one way of obtaining access to those files is to ask the LO installation that the external program wants to target about the location of those files. This is done with the unoinfo helper executable (see desktop/README.md for details). However, in the case of flatpak, something like flatpak run --command=/app/libreoffice/program/unoinfo org.libreoffice.LibreOffice java isn’t useful to a program outside the LO flatpak sandbox, as the reported paths don’t exist outside that flatpak. So, to make that work, some way of accessing a flatpak’s arbitrary data and code files from outside the flatpak would be necessary, and some mechanism by which the paths that unoinfo reports can be mapped from flatpak-internal to flatpak-external paths.
However, URP and the software artefacts necessary to speak it are evolved compatibly, so it generally works to make an external program use such files that don’t come from the targeted LO installation, but rather from a different source. There has been such a standalone UNO Runtime Environment (URE) in the past, but it has been abandoned for lack of maintenance support (though its traces and concepts are still there in the code, and e.g. some Linux distros still maintain it as a separate LO sub-package). Such a URE running outside the flatpak (and potentially bundled with the external program) would be an alternative approach to solve this issue.