Description: I have been using the material-decoration theme in Plasma for a long time (https://github.com/Zren/material-decoration ). This theme gives Locally Integrated Menu (LIM - a way to move main menu into the window title) Up to LO 7.3.3 whit kf5 LIM worked as expected. With updating to 7.3.3, LIM has disappeared from title. LO works some strange If start libreoffice (it opens start window) - LIM is in title bar If start libreoffice --writer | --calc | etc. - LIM disappears If start libreoffice and create any document - LIM is on start window and disappears in document window. I found two workarounds on it: 1st, migrate on VLC = gtk3, but it isn't convenient because I lost my well configured kf5 file open dialog 2nd, copy libvclplug_qt5lo.so, libkf5be1lo.so, libvclplug_kf5lo.so from LO 7.3.2 (latest working version) to LO 7.3.4 (my current version) Steps to Reproduce: For Arch or Manjara 1. Install material-kwin-decoration-git 2. Select "material" for window decoration 3. Run libreoffice --writer (e.g.) Actual Results: No main menu is in title bar Expected Results: main menu is in title bar Reproducible: Always User Profile Reset: Yes Additional Info: Version: 7.3.4.2 / LibreOffice Community Build ID: 30(Build:2) CPU threads: 12; OS: Linux 5.15; UI render: default; VCL: kf5 (cairo+xcb) Locale: ru-RU (ru_RU.UTF8); UI: ru-RU Gentoo official package Calc: threaded
Created attachment 180960 [details] LO Writer 7.3.2 with LIM: main menu is in title
Created attachment 180961 [details] LO Writer 7.3.3 with LIM: no main menu is in title
Created attachment 180962 [details] LO 7.3.3 start window with LIM: main menu is in title LO 7.3.3: if run in terminal "libreoffice" then main menu is in title bar but after click to create new document LIM disappears
Created attachment 180981 [details] Screenshot with master daily build on Debian testing
If I understand this correctly, it works OK here, s. screenshot attachment 180981 [details], created in a Debian testing VM with a daily build of LibreOffice and self-compiled material-decoration of its master branch (as of commit 973949761f609f9c676c5b2b7c6d9560661d34c3), following the instructions in the https://github.com/Zren/material-decoration README, in particular > Make sure you add the AppMenu button in System Settings > Application Style > Window Decorations > Buttons Tab. Can you confirm that the attached screenshot shows correct behavior? If so, can you please check whether it works for you with a daily build as well? Those are available here: https://dev-builds.libreoffice.org/daily/master/current.html Instructions to install in parallel: https://wiki.documentfoundation.org/Installing_in_parallel/Linux Version: 7.5.0.0.alpha0+ / LibreOffice Community Build ID: 415dc3bb1c03dbdbc3cbca274bc435ac7557ba2d CPU threads: 2; OS: Linux 5.18; UI render: default; VCL: kf5 (cairo+xcb) Locale: en-US (C.UTF-8); UI: en-US Calc: threaded
Created attachment 181004 [details] Master daily build looks different in appimg against pure deb installation At first of all I created AppImg with wiki instruction. Next I ran Master daily AppImg in Manjaro. It gave me no LIM in title bar, but a lot of error warnings about vlc in terminal. Next I ran the AppImg in my primary Gentoo. AppImg got gtk3 as vcl. Setting SAL_USE_VLC PLUGINS=kf5 in user environment or in terminal SAL_USE_VLC PLUGINS=kf5 ./LibreOffice Dev-7.5.0.0.alpha 0_2022-06-27-x86_64.AppImage gave no luck to me I have kubuntu 20.04 for testing Running the AppImg in Kubuntu gives me the same result as in Manjaro - no LIMIT I installed community compiled deb packages (make_appimg script used them as source for the AppImg) I run libreofficedev7.5 --writer ... and we got LIM. So, it works, but if LO installed from community compiled deb packages in main system environment, not AppImg
[Automated Action] NeedInfo-To-Unconfirmed
(In reply to Max from comment #6) > So, it works, but if LO installed from community compiled deb packages in > main system environment, not AppImg That's interesting... If it works with deb packages but not the AppImg, I tend to suggest to close this bug here as WORKSFORME and open a GitHub issue for the script that generates the AppImg instead: https://github.com/antoniofaccioli/libreoffice-appimage What do you think?
Created attachment 181082 [details] Console output of Master Daily AppImg IMO, the issue is not a case of appimg script. It also affects on self compiled binaries such in Gentoo, not only AppImg created from debs. Is affects Manjaro too. As I wrote above during appimg runtime there was a lot warnings about vcl (see an attachment). But I've tested Master Daily rpm in OpenSuse tumbleweed VM - it works fine.
(In reply to Max from comment #9) > IMO, the issue is not a case of appimg script. > > It also affects on self compiled binaries such in Gentoo, not only AppImg > created from debs. > > Is affects Manjaro too. > > (...) > > But I've tested Master Daily rpm in OpenSuse tumbleweed VM - it works fine. OK, let's leave this bug open for now then. It surprises me that it works with the same version for the non-AppImg case, but not if it's an AppImg, since my (maybe naive) expectation would be that it should just behave the same way, given the same files from the LO build are used. But then, I don't know much about AppImg. Is any sandboxing,... involved there? (I know that is the case for Flatpak and Snap, but thought that it isn't for AppImg in general.) Some typical "suspects" that come to my mind that may usually play a role when things behave differently on different systems for the kf5 VCL plugin: * Qt library versions * KF5 library /Plasma version * other system libs * X11 vs Wayland * user profile/settings (for either LO or KDE Plasma) This *might* be relevant for different behavior across distros, but I don't see how it would explain the AppImg vs. non-AppImg difference, unless the generated AppImg file includes different libraries than the system ones. (I don't know much about AppImg, though.) Without any clear steps to reliably reproduce this in a development setup, I fear it's unlikely that this will get fixed soon. If you can identify what's the relevant part that makes it work on one system, but not another, that might be of much help. What you could also try is to identify from which commit on this no longer works, by doing a bibisect using the 7.3 bibisect repo (in case the problem is reproducible with this repo). More details here: https://wiki.documentfoundation.org/QA/Bibisect > Created attachment 181082 [details] > Console output of Master Daily AppImg > > (...) > As I wrote above during appimg runtime there was a lot warnings about vcl > (see an attachment). Those shouldn't be related to the issue discussed here. The java warning should go away if you install a JRE (and maybe have to select it in the LO settings).
This looks like a related bug in the LO flatpak repo: https://github.com/flathub/org.libreoffice.LibreOffice/issues/63 As I understand it: - appmenu doesn't work with Gtk apps under KDE+Wayland¹ in general - using the kf5 VCL backend could work around the issue (but this backend seems absent from/broken in the flatpak distribution) - (at least on my machine) the Gtk VCL backend doesn't ensure that the menu bar is displayed in-app under KDE+Wayland, which is unlike every other Gtk apps (AFAICT) Perhaps this last point could be improved upon, if LO could detect that it's running under wayland, and make sure that an in-app menu is shown in this case? ¹: https://bugs.kde.org/show_bug.cgi?id=424485
*** Bug 152362 has been marked as a duplicate of this bug. ***
Confirmed via duplicate bug Bug 152362.
(In reply to rom1dep from comment #12) > This looks like a related bug in the LO flatpak repo: > https://github.com/flathub/org.libreoffice.LibreOffice/issues/63 Thanks for putting me on the right track! There is a separate report about this Wayland + flatpak issue: bug 156387 I've closed it as "not our bug" as it looks like the solution will be done on the flatpak packaging side, but feel free to add your thought there.