Bug 1647233 - VCL gtk3-kde5 is available with 6.1 and should be enabled with --enable-gtk3-kde5
Summary: VCL gtk3-kde5 is available with 6.1 and should be enabled with --enable-gtk3-...
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: libreoffice
Version: rawhide
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Caolan McNamara
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-11-06 22:48 UTC by Mike Goodwin
Modified: 2018-11-15 21:07 UTC (History)
6 users (show)

Fixed In Version: libreoffice-6.1.2.1-6.fc30
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-11-15 21:07:15 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Mike Goodwin 2018-11-06 22:48:56 UTC
Description of problem:

https://www.phoronix.com/scan.php?page=news_item&px=LibreOffice-KDE5-Backend

According to the above Phoronix article, --enable-gtk3-kde5 is available in Libreoffice 6.1 and enhances the integration with KDE 5 by providing native dialogs and maintains the use of the stable GTK3 toolkit. Enabling this is a benefit for Fedora KDE users that presently lack any Libreoffice integration in Fedora KDE. 

This is also a good holdover until 6.2 is released with native KF5/Qt5 integration earlier next year.

Version-Release number of selected component (if applicable):

libreoffice-6.1.2.1-2.fc29.x86_64

Comment 1 Caolan McNamara 2018-11-07 09:50:10 UTC
I wonder if dropping the moribund kde4 in favour of that gtk3-kde5 approach would be welcomed or pitchfork territory ?

Comment 2 Rex Dieter 2018-11-07 12:26:59 UTC
dropping the older largely unsupported qt4/kde4 stuff probably needs to happen sooner or later, so may as well be sooner.  My $0.02.

Comment 3 Rex Dieter 2018-11-07 16:01:11 UTC
Actually, I'll take this issue to kde-sig to discuss formally, and I will let you know how that goes.  That way it will be on the kde-sig to take any possible criticisms/pitchforking.

Comment 4 Caolan McNamara 2018-11-07 16:17:32 UTC
sounds good

Comment 6 Kevin Kofler 2018-11-08 02:50:44 UTC
(In reply to Caolan McNamara from comment #1)
> I wonder if dropping the moribund kde4 in favour of that gtk3-kde5 approach
> would be welcomed or pitchfork territory ?

Deep pitchfork territory!
https://lists.fedoraproject.org/archives/list/kde@lists.fedoraproject.org/message/RM6ACA6QOCRNE4Z5HJN7KK5X5CGIRWTI/

Comment 7 Rex Dieter 2018-11-13 16:55:18 UTC
kde-sig met today, our recommendation and what we'd like to see:

If you're open to incremental changes, please enable gtk3-kde5 now, and keep 
-kde4 around for now.

Otherwise, when 6.2 lands with better/full Qt5 support, 
https://wiki.documentfoundation.org/ReleaseNotes/6.2#KDE_5,
enable that, and drop/replace -kde4 (and gtk3-kde5) then.

Does that sound agreeable?

Comment 8 Mike Goodwin 2018-11-13 17:14:52 UTC
KDE-SIG's suggestions are perfectly in line with what I originally had in mind. 

I see gtk3-kde5 as a transition forward to full Qt5 support, and might offer a good fallback position should the official Qt5 support during Q1 2019 be too buggy at first to offer in current releases. (but I hold the opinion that Qt5 support in 6.2 should be enabled for rawhide regardless) 

Thanks for helping to clarify this issue :)

Comment 9 Caolan McNamara 2018-11-14 09:46:30 UTC
I'm pretty crushed under bug reports, but I have no objection if someone wants to supply a patch to enable and package the gtk3-kde5 subpackage.

Comment 10 Rex Dieter 2018-11-15 14:48:42 UTC
OK, I can help work on that with a pull request.

Do you have a preference for gtk3-kde5 as the subpackage name?  As there is nothing called "KDE 5" strictly, I'd prefer calling this kf5 to refer to it using "KDE Frameworks 5"

Comment 11 Kevin Kofler 2018-11-15 14:58:13 UTC
gtk3-kf5 then. Keep in mind that there is a native "kde5" (kf5) NWF under development.

Comment 12 Rex Dieter 2018-11-15 15:01:15 UTC
Second reason I was advocating for "kf5" name:
* this is a transition/temporary solution until the fully native one lands, which will be replaced eventually... as you mentioned...  We could just keep the same name for upgrade path, instead of transitioning between 2 differently named subpackages (avoids one set of Obsoletes).


Note You need to log in before you can comment on or make changes to this bug.