/avmedia/

5.3-3.1'>distro/collabora/cd-5.3-3.1 LibreOffice 核心代码仓库文档基金会
summaryrefslogtreecommitdiff
path: root/config_host/config_vclplug.h.in
AgeCommit message (Collapse)Author
2023-10-18qt: Drop now obsolete workaround for Qt < 5.12Michael Weghorn
This workaround was only applied for Qt < 5.12 and is no longer needed now that support for Qt < 5.15 has been dropped in commit afb4c96d271958ced3175dfc2cf8bb9e8b0a9d3b Author: Michael Weghorn <m.weghorn@posteo.de> Date: Thu Aug 3 21:30:22 2023 +0200 qt: Drop code for Qt < 5.15 Commit originally adding the workaround: commit fe2baf9e84e0ca9aeaa683e37076f57fa3f38dca Author: Jan-Marek Glogowski <jan-marek.glogowski@extern.cib.de> Date: Tue Dec 3 08:32:58 2019 +0100 Qt5 fix missing XCB_ICCCM_WM_HINT_WINDOW_GROUP This is the application level equivalent of the Qt5 fix for bug QTBUG-46626 / commit 0de4b32 ("xcb: fix issue with dialogs hidden by other windows"), which was broken since Qt 5.4 and is just fixed since Qt 5.12. It is needed for some window managers, which don't know about the WM_CLIENT_LEADER property. Both settings are the same, but just the latter is set by older Qt5 releases. This probably isn't a real problem, as GNOME or XFCE would use the gtk VCL plugin, but since I already wrote the code when debugging tdf#129071, there is also no reason to drop it (except: more code, more bugs...). This fix is optional and needs development headers for xcb-icccm, which can actually be compiled into Qt5. If missing configure will just print a warning, since it's a runtime requirement and we explicitly drop the linked Qt version symbol, so the potential build Qt version won't matter. Change-Id: Ifc5a8f8a40ee13779a911efb53e8b8b868614d0b Reviewed-on: https://gerrit.libreoffice.org/84299 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de> Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de> Change-Id: I56b708449cf686f787f55256c76673be604d31e4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158102 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2023-06-22kf6: Add a kf6 VCL pluginMichael Weghorn
Add a "kf6" VCL plugin that uses the KF6 (KDE Frameworks 6) libraries to provide a native KDE/Plasma file chooser, just like the kf5 VCL plugin does for KF5. Building the plugin is disabled by default and can be enabled by autogen option '--enable-kf6'. Selecting the VCL plugin can be done by starting LO with environment variable 'SAL_USE_VCLPLUGIN=kf6' set. The kf6 VCL plugin reuses the kf5 VCL plugin code. (The kf6 headers and sources for now just `#include` the kf5 ones.) This was quickly tested on KDE Neon unstable, which provides a daily snapshot of Plasma 6 and the KF6 libraries. (Regarding a potential release date, [1] mentions: "Plasma 6 is built on top of Qt 6 and is tentatively planned to be released in late 2023 or early 2024.") [1] https://community.kde.org/Plasma/Plasma_6 Change-Id: I4c2b7e3be8e60f1d8cf60119f6f3f642b71349f5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153438 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2022-12-21initial Experimental System-Dependent PrimitiveRenderer for CairoCaolán McNamara
just some partial pieces export TEST_SYSTEM_PRIMITIVE_RENDERER=1 and the simple drawing shapes work Change-Id: I3e01501a1cb21ec86d6fe8f5637a23e7358ffc86 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144632 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-01-12gbuild: build static LO / link static executablesJan-Marek Glogowski
This allows to build a complete static LibreOffice on Linux, except for linked externals. Since LO's static build implies disabled dynamic loading, one must select one VCL backend to be compiled in. See the (large) comment in solenv/gbuild/static.mk trying to explain, why this implementation was chosen (spoiler: seems there is no other way) and what is actually implemented. This will collect all libraries, statics and externals of executables. If the executable uses components, it will get linked to all static components. While it works with any Executable, it just makes sense for soffice.bin, because the static component map sucks every dependency in, bloating most other binaries. In theory on could generate the dependencies based on the list of used components (see gb_CppunitTest_use_components), then generate a specific static constructor map, directly include it in the exe's cxx code and then link the minimal dependencies. The static LO should build on Linux with: --enable-customtarget-components --disable-dynamic-loading Tested VCL plugin config is: --disable-gtk3 --disable-gen --enable-qt5 The partial build support is split into a 2nd patch. Change-Id: Iafc95752fae9e88095f54a21f1e30a4f080815e2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126790 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2021-09-29qt6: Add a qt6 VCL pluginMichael Weghorn
This adds a new "qt6" VCL plugin based on Qt 6. Building the plugin is enabled by autogen option '--enable-qt6' (and optionally setting 'QT6DIR' as needed). Use the 'SAL_USE_VCLPLUGIN=qt6' environment variable before running LO to select this VCL plugin. Taking qt6 into account at all relevant places certainly still requires follow-up changes, but this builds and runs with a self-compiled qtbase from the 'dev' git branch as of commit 3ce0672143d2eb3c3809f82998a4d71c5800d77a. I didn't see anything obviously broken in a quick run, but didn't test much. This reuses and shares the qt5 VCL plugin code; the qt6 headers and sources for now just '#include' the qt5 ones. Version checks are used for the code places that need different handling to be built against Qt 6. The build system parts in this commit were mostly done by copying the qt5 equivalents, then adapting as needed. Some notes on things I came across while porting to qt6: 1) At least in my self-compiled Qt versions, 'moc' (the meta-object compiler) is located in the 'libexec' subdirectory in 'QT6DIR', while the Qt 5 equivalent is located in the "bin" subdirectory of 'QT5DIR', so the configure.ac check uses the former. 2) moc does not process classes from the included headers. Since the headers in 'vcl/inc/qt6' just '#include' the ones from 'vcl/inc/qt5', running moc on the qt6 headers doesn't work, so moc is currently run on the qt5 headers for qt6 as well (s. 'vcl/CustomTarget_qt6_moc.mk'). That will have to be adapted in case the qt6 VCL plugin uses "own" headers instead of just including the qt5 ones at some point. 3) QX11Extras has been removed from Qt 6. [1] says: > Changes to Qt X11 Extras > > The QX11Info class has been removed. > > Clients that still rely on the functionality can include the private > header <QtGui/private/qtx11extras_p.h> as a stopgap solution. To enable > private headers use QT += core-private with qmake, or add a project > dependency to Qt::CorePrivate with CMake. I didn't take any closer look, just dropped the use of QtX11Extras for qt6 for now. 4) XCB_ICCCM is no longer needed. It is only used in qt5 to workaround a Qt bug fixed in Qt 5.12, s. commit fe2baf9e84e0ca9aeaa683e37076f57fa3f38dca Author: Jan-Marek Glogowski <jan-marek.glogowski@extern.cib.de> Date: Tue Dec 3 08:32:58 2019 +0100 Qt5 fix missing XCB_ICCCM_WM_HINT_WINDOW_GROUP 5) X11-specific code is still used for key modifier handling. Therefore, still check for the XCB headers when 'USING_X11' is set in configure.ac, and use a 'QT6_USING_X11' define (as qt5 uses 'QT5_USING_X11'). 6) There's currently no Qt 6 video sink for GStreamer. As of today, qt-gstreamer is unmaintained and there is no Qt 6 version. The project's README [2] says: > 0. Maintenance Notice > --------------------- > > This code is unmaintained. You can use it at your own risk. > > If you want to integrate video display in your QML-based UI, > you should consider using 'qmlglsink', from gst-plugins-good. > This is a well supported video sink that uses the generic > gstreamer-gl stack and is in many ways superior to 'qtquick2videosink' > that is provided by qt-gstreamer. You can use this code as an example: > https://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/tests/examples/qt/qmlsink > > If you are not interested in using QML in your UI, then you > may use one of the other elements provided by this module > (see below). If you do that, it would be helpful to let us > know that this code is still useful to you. We may consider > adding these elements in one of the core gstreamer modules. > > If you are here for the Qt-style bindings, I'm sorry to disappoint you. > The alternative is to use the C API, or the GStreamermm C++ API. > Qt-style bindings are cool, but unfortunately they are very hard > to maintain because they are written by hand. If you are interested > in continuing this project, you are welcome to implement a > generator for them, probably based on GObject-Introspection. > I am happy to provide directions if you want to pursue such a thing. Therefore, the Qt video sink handling is qt5-only and the corresponding handling for GOBJECT (used for the GStreamer video sink handling) was not taken over for qt6. This presumably means that video playback in Impress presentations does not work when using qt6 with they Qt Wayland plugin, s. tdf#125219 for the corresponding bug for qt5/kf5. (I did not build the qtwayland module to actually test this, though. Video playback with the Qt xcb plugin in a Wayland session works.) [1] https://doc-snapshots.qt.io/qt6-dev/extras-changes-qt6.html [2] https://cgit.freedesktop.org/gstreamer/qt-gstreamer/tree/README Change-Id: Ib105ccfb2c3630ec5d5403793a3cd9ba31d85bdf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122808 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2021-06-01configure: Refactor platform defaultsJan-Marek Glogowski
The main idea was to move complexity from source (and Makefiles) into configure.ac, because otherwise these must replicate the "same" branching, often resulting in diversions. Better to keep the logic in one place (configure.ac) and set additional variables to be used directly by source code and Makefiles. Notably this introduce the "using_*" platform flags, which should be considered constants. There is USING_X11, which actually tells, if the build uses the platform's X11 (and I opted for the removal of HAVE_FEATURE_X11). I also consider variables constant, after they have been exported by AC_SUBST, which should never be conditional, or some AC_DEFINE set them for a config header. A large block of defaults depends on $using_x11, so we set them to the same value, but just if the platform doesn't set it. The other important flag is $using_freetype_fontconfig, if the platform uses freetype and fontconfig. The headless plugin uses cairo for its drawing operations and freetype+fontconfig for text, so $test_cairo = $using_freetype_fontconfig. This is independent from a the cairo canvas! The OpenGL X11 code now depends on USING_X11, but it doesn't yet reflect the filter in Library_vcl.mk protecting glx. I don't know how correct this glx filter is, seeing that the source code just checked for "UNX - some non-X11 targets". Change-Id: Id1ba1a967a5d8d10ee217458be879ed00459f7e6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116440 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-05-29vcl: Implement static vclplug usageJan-Marek Glogowski
.. and convert Android to it. Will also be used by WASM. It's also kind of a followup on commit f5af2104fc490b90510e36bbf1d2adec8017c594. Change-Id: I3a1b5bc2eae2692e706da10c6352534433c61e57 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116385 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2019-12-06Qt5 fix missing XCB_ICCCM_WM_HINT_WINDOW_GROUPJan-Marek Glogowski
This is the application level equivalent of the Qt5 fix for bug QTBUG-46626 / commit 0de4b32 ("xcb: fix issue with dialogs hidden by other windows"), which was broken since Qt 5.4 and is just fixed since Qt 5.12. It is needed for some window managers, which don't know about the WM_CLIENT_LEADER property. Both settings are the same, but just the latter is set by older Qt5 releases. This probably isn't a real problem, as GNOME or XFCE would use the gtk VCL plugin, but since I already wrote the code when debugging tdf#129071, there is also no reason to drop it (except: more code, more bugs...). This fix is optional and needs development headers for xcb-icccm, which can actually be compiled into Qt5. If missing configure will just print a warning, since it's a runtime requirement and we explicitly drop the linked Qt version symbol, so the potential build Qt version won't matter. Change-Id: Ifc5a8f8a40ee13779a911efb53e8b8b868614d0b Reviewed-on: https://gerrit.libreoffice.org/84299 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de> Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2019-09-30drop gtk2 supportCaolán McNamara
Change-Id: Ie838cabfecfef7e3225c1555536d5c9cf3b43f15 Reviewed-on: https://gerrit.libreoffice.org/77405 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-07-21tdf#125922 rename kde5 to kf5 + plasma5Jan-Marek Glogowski
Just as the gtk3 plugin isn't named GNOME, rename kde5 to kf5, as it is based on the KDE frameworks 5 libraries. This also includes: * a convenience alias to load the kf5 VCL plugin in case someone requests the kde5 plugin. * keep convenience kde5 configure switch, but warn about it * rename detected desktop from kde5 to plasma5 Change-Id: I6764a05b81a5edbf284484c234fee2649aacf735 Reviewed-on: https://gerrit.libreoffice.org/75313 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2019-06-14KDE5 move screensafer inhibiting code into Qt5Jan-Marek Glogowski
There will presumably be more X11 specific code later to implement some "fix" for tdf#119202. Moving the screensafer inhibitor is rather uncontroversial in comparion, so start with it and use it to carry the matching configure.ac changes. A little "nightmare" are all the clashing X11 / Qt type undefs, but I couldn't find a better solution while the inhibitor continues to include the X11 headers in it's header. Change-Id: I55c89c76726d30a890178488484e954207267e89 Reviewed-on: https://gerrit.libreoffice.org/74015 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2019-06-13Don't link avmediagst with gtk3 and qt5Jan-Marek Glogowski
While the VCL plugins are dynamically loaded and therefore just load their depending toolkit libraries, the GStreamer avmedia backend now links against Qt and GTK+. The GStreamer API itself is toolkit agnostic and the toolkit setup just uses a single GStreamer symbol to create the specific video sink. So the toolkit binding can simply be moved into the VCL plugin. At the point of the GStreamer toolkit setup call the GStreamer library is loaded by avmediagst, so the dlsym lookup should never fail. I also dropped the special GtkWidget handling. Using g_object_get will increase the refcount of the widget. A g_object_unref after adding it to the container seems to destroy it correctly. Change-Id: I693947e441bceb4b09bc38920e308e39142d0a35 Reviewed-on: https://gerrit.libreoffice.org/73849 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2019-06-03Have all VCL plugin related defines in config_vclplug.hMichael Weghorn
Add the 'ENABLE_GTK3' and 'ENABLE_QT5' there to allow using sth like #include <config_vclplug.h> #if ENABLE_GTK3 // your code here #endif for these as well. Remove 'config_gtk3_kde5.h{,.in}', 'config_kde5.h{,.in}' and 'config_qt5.h{,.in}'; they aren't included anywhere. ('QT5_HAVE_GLIB' is only used in Makefiles, so there's no need to have it in a config header and 'KDE5_HAVE_GLIB' is not used anywhere at all.) Change-Id: Iea7906880f57dde782c50f2520e8d9b358f6bc82 Reviewed-on: https://gerrit.libreoffice.org/73204 Tested-by: Jenkins Reviewed-by: Katarina Behrens <Katarina.Behrens@cib.de>