72b936d70b
To not increase the size of the main org.libreoffice.LibreOffice app further, the plan was to realize this as an org.libreoffice.LibreOffice.Help extension. Ideally, this would be a localized extension, so that, by default, only a relevant subset of the extension would be downloaded and installed. (But see below.) There are multiple technical problems, as discussed at <https://github.com/ flathub/org.libreoffice.LibreOffice/issues/35#issuecomment-447295308> "Add integrated LibreOffice Help offline": * LO can't pass a file URL with query part to xdg-open, so uses a temporary wrapper .html file that redirects to the target URL. But for the flatpak case this wrapper can't be in /tmp (which isn't visible from outside the flatpak sandbox), but is instead stored in a new temp dir under $XDG_CACHE_HOME (which is always set for flatpaks and /is/ visible form the outside) that is removed on LO exit. * The file URL stored in the temp file must be rewritten from the internal path (/app/libreoffice/help/...) to the path as seen outside the flatpak sandbox. While the path for the org.libreoffice.LibreOffice /app is stored in /.flatpak-info, the external path for the org.libreoffice.LibreOffice.Help extension is different and not stored there. So use a hack trying to construct that path from what information is available in /.flatpak-info. * But the help content consists of locale-specific and shared files, and those reference each other with relative links. But a localized flatpak extension cannot contain shared files, it can only contain per-language sub-dirs. And if the shared help files were kept out of the extension, as part of the app itself, the relative paths among these files inside the flatpak sandbox would differ from those outside of it, so would be broken when viewing the content in the external browser. A solution would either (a) need to somehow rewrite the content of all the help files being served from LO to the external browser, or (b) replicate the shared help files in all the extension's per- language sub-dirs (and if some localization uses en-US content as a fallback for only part of its translated content, e.g., in the case of media files, would need to also replicate that en-US content), or (c) use a non-localized extension that always contains the content for all localizations. For now, I chose the third approach. This makes the org.libreoffice.LibreOffice.Help extension relatively large (the current /app/libreoffice/help tree has a size of ca. 100MB), so that I decided to not have it downloaded and installed automatically ("no-autodownload": true in solenv/flatpak-manifest.in). (I checked with Flatpak 1.0.6 that if the extension should be changed to a localized one with the same name in the future, updating from an older version would work. If the old extension was not installed, just the relevant localizations of the new version will be downloaded and installed. If the old extension was installed, the full set of localizations of the new version will be downloaded and installed.) (As also mentioned at <https://github.com/flathub/org.libreoffice.LibreOffice/ issues/35#issuecomment-447295308>: "A second, minor, nuisance is that, for security reasons, an `xdg-open file:///...html` call from a flatpak leads to an intermediate popup dialog letting the user chose which application to use to open the URI, while e.g. an `xdg-open http:///...html` is allowed to go directly to the user's preferred browser. So accessing help content from LO flatpak would present that popup dialog first, forcing the user to select a browser to proceed.") Change-Id: I35f5a23947dd551dc1b9bff1dd2abd6710073b5f Reviewed-on: https://gerrit.libreoffice.org/65451 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> |
||
|---|---|---|
| .. | ||
| Jenkins | ||
| LibreOfficeAndroid.conf | ||
| LibreOfficeAndroidAarch64.conf | ||
| LibreOfficeAndroidX86.conf | ||
| LibreOfficeCoverity.conf | ||
| LibreOfficeFlatpak.conf | ||
| LibreOfficeHaiku.conf | ||
| LibreOfficeiOS.conf | ||
| LibreOfficeLinux.conf | ||
| LibreOfficeMacOSX.conf | ||
| LibreOfficeOpenBSD.conf | ||
| LibreOfficeOssFuzz.conf | ||
| LibreOfficeVanillaMacAppStore.conf | ||
| LibreOfficeWin32.conf | ||
| LibreOfficeWin64.conf | ||
| README | ||
Pre-canned distribution configurations These files are supposed to correspond to the options used when creating the Document Foundation (or other "canonical") builds of LibreOffice for various platforms. They are *not* supposed to represent the "most useful" options for developers in general. On the contrary, the intent is that just running ./autogen.sh without any options at all should produce a buildable configuration for developers with interest in working on the most commonly used parts of the code. See [[https://wiki.documentfoundation.org/Development/ReleaseBuilds]] for how TDF builds make use of these switches. (Especially, since --with-package-format now triggers whether or not installation sets are built, all the relevant *.conf files specify it, except for LibreOfficeLinux.conf, where the TDF build instructions pass an explicit --with-package-format="rpm deb" in addition to --with-distro=LibreOfficeLinux.) (Possibly the above is a misunderstanding, or maybe there never even has been any clear consensus what situations these files actually are intended for.) The files contain sets of configuration parameters, and can be passed on the autogen.sh command line thus: ./autogen.sh --with-distro=LibreOfficeFoo Contrary to the above, in the Android case the amount of parameters you just must use is so large, that for convenience it is always easiest to use the corresponding distro-configs file. This is a bug and needs to be fixed; also configuring for Android should ideally use sane (or the only possible) defaults and work fine without any parameters at all.