Build with QT5 KF5 VCL Backend

Hi I made a similar merge request using the kde runtime, which should be less work to maintain https://github.com/flathub/org.libreoffice.LibreOffice/pull/232

flathubbot commented 1 year ago

Build 44966 successful To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/27585/org.libreoffice.LibreOffice.flatpakref

flathubbot commented 1 year ago

Started test build 45060

flathubbot commented 1 year ago

Build 45060 failed

flathubbot commented 1 year ago

Started test build 45071

EliasOfWaffle commented 1 year ago

Hi I made a similar merge request using the kde runtime, which should be less work to maintain #232

Sorry carl, but your commit is not building, and is not good to change the platform, the best idea for libreoffice is to be platform agnostic, i think using kde runtime can break a good gnome detection in VCL backend. Instead of this is better to build qt5 and qt-wayland, this not modify the platform. think with me, i am a gnome user and i not have nothing about kde platform installed, use kde platform will force the user to download a other runtime and kde specific components. And in this case kde runtime/sdk and gnome runtime/sdk leaves more time to update after a release. This pull tries to maintain more agnostic possible, and to not break things

flathubbot commented 1 year ago

Build 45071 successful To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/27690/org.libreoffice.LibreOffice.flatpakref

stbergmann commented 1 year ago

What is the motivation for this PR? Are you intending to propose it for merging, or is it just meant as a throwaway testing ground? (As were apparently the recent PR 230 and PR 231, but which were clearly labeled as that.)

flathubbot commented 1 year ago

Started test build 45279

flathubbot commented 1 year ago

Build 45279 failed

EliasOfWaffle commented 1 year ago

What is the motivation for this PR? Are you intending to propose it for merging, or is it just meant as a throwaway testing ground? (As were apparently the recent PR 230 and PR 231, but which were clearly labeled as that.)

LibreOffice for Red Hat have removed, have some possibilities to Fedora or Other distros not maintain more, i think the OpenSuse can work in the same way, because maintain LibreOffice depends amount of Dependencies package, can be good to be a merge request if in the future the LibreOffice from Flathub can be a good alternative for a future distros that have removed LibreOffice, in this case for users That user LibreOffice can be a Good Integration using a specific platform VCL Backend, in this case the QT5 five is working, some of users that use a QT based DE (LXQT and etc) can be a best integration. The new work of more commits is for Supporting KF5 VCL Backend for a best integration in plasma. For now is just a minimal trying, because need's more test and work for this can be usable for daily usage

flathubbot commented 1 year ago

Started test build 45538

flathubbot commented 1 year ago

Build 45538 failed

flathubbot commented 1 year ago

Started test build 45553

flathubbot commented 1 year ago

Build 45553 failed

flathubbot commented 1 year ago

Started test build 45559

flathubbot commented 1 year ago

Build 45559 failed

flathubbot commented 1 year ago

Started test build 45571

flathubbot commented 1 year ago

Build 45571 failed

stbergmann commented 1 year ago

For now is just a minimal trying, because need's more test and work for this can be usable for daily usage

Just two notes so far:

There is little excitement here about bundling more modules than the existing gvfs and krb5 ones: For each module, if there are any relevant (security) issues, we need to notice that and take appropriate action in a timely manner.
Even when built with --enable-qt5 --enable-kf5, I would assume that the flatpak will still always use the GTK backend by default (but correct me if I'm wrong). Is your approach here that users will override that via the SAL_USE_VCLPLUGIN environment variable?

flathubbot commented 1 year ago

Started test build 45695

EliasOfWaffle commented 1 year ago

For now is just a minimal trying, because need's more test and work for this can be usable for daily usage

Just two notes so far:

There is little excitement here about bundling more modules than the existing gvfs and krb5 ones: For each module, if there are any relevant (security) issues, we need to notice that and take appropriate action in a timely manner.

Even when built with --enable-qt5 --enable-kf5, I would assume that the flatpak will still always use the GTK backend by default (but correct me if I'm wrong). Is your approach here that users will override that via the SAL_USE_VCLPLUGIN environment variable?

Yes the CVEs can be noticed in updates changelog yet? And the mainly ideia is for have a script thats define this variable, but in my test with KDE QT5 is not detected automatically, but if be necessary the user can define this variable if can be necessary

stbergmann commented 1 year ago

Yes the CVEs can be noticed in updates changelog yet?

(Which would require that somebody would actively watch change logs for those additional modules.)

CarlSchwan commented 1 year ago

Yes the CVEs can be noticed in updates changelog yet?

(Which would require that somebody would actively watch change logs for those additional modules.)

Yeah, this is why I believe the best way is to import the KDE runtime, which inherits from the freedesktop runtime since the kde runtime is maintained and regularly updated. We don't want and need to duplicate this work inside the LibreOffice flatpak packaging.

Now I just need to figure out why #232 doesn't compile :( While I would consider myself quite familiar with Qt, I have no idea about the autotools toolchain.

flathubbot commented 1 year ago

Build 45695 failed

flathubbot commented 1 year ago

Started test build 45708

EliasOfWaffle commented 1 year ago

Yes the CVEs can be noticed in updates changelog yet?

(Which would require that somebody would actively watch change logs for those additional modules.)

Yeah, this is why I believe the best way is to import the KDE runtime, which inherits from the freedesktop runtime since the kde runtime is maintained and regularly updated. We don't want and need to duplicate this work inside the LibreOffice flatpak packaging.

Now I just need to figure out why #232 doesn't compile :( While I would consider myself quite familiar with Qt, I have no idea about the autotools toolchain.

But in this case, the gtk3 default backend can be builded in the same way? and the future with new GTK4 backend (WIP) how this can be maintained? this break gtk3 and just build qt and kf5 (i think). Can be better to maintain multiples Backends if be possible to use Fedora Runtime, but this is not supported by flatpak yet?

stbergmann commented 1 year ago

Yes the CVEs can be noticed in updates changelog yet?

(Which would require that somebody would actively watch change logs for those additional modules.)

...or at least make use of https://github.com/flathub/flatpak-external-data-checker, which I just learned about, and intend to make use of for LibreOffice (see https://github.com/flathub/org.libreoffice.LibreOffice/pull/236 "Add metadata for flatpak-external-data-checker".)

stbergmann commented 1 year ago

Yeah, this is why I believe the best way is to import the KDE runtime, which inherits from the freedesktop runtime since the kde runtime is maintained and regularly updated. We don't want and need to duplicate this work inside the LibreOffice flatpak packaging.

Now I just need to figure out why #232 doesn't compile :( While I would consider myself quite familiar with Qt, I have no idea about the autotools toolchain.

But switching from org.freedesktop.Platform to org.kde.Platform is obviously a no-go to begin with.

flathubbot commented 1 year ago

Build 45708 failed

flathubbot commented 1 year ago

Started test build 45721

Erick555 commented 1 year ago

But in this case, the gtk3 default backend can be builded in the same way? and the future with new GTK4 backend (WIP) how this can be maintained? this break gtk3 and just build qt and kf5 (i think).

KDE runtime is superset of freedesktop - the former contains everything from the latter so for gtk backends it's irrelevant which runtime LO uses.

I think using qt /kf5 backend without KDE runtime would mean there is no theme integration with host system.

flathubbot commented 1 year ago

Build 45721 failed

flathub / org.libreoffice.LibreOffice

Build with QT5 KF5 VCL Backend #233