KDE with gtk3_kde5 vcl plugin enabled. If i use a mice's context menu to copy paste anything i have to copy twice before pasting. The very first time you open a program and copy paste it works with 1 copy and the rest needs copying twice. If i use Ctr+C Ctr+V or Edit menu everything works as expected. P.S. I remember the exact same problem happened before, could please fix it for good?
I can neither reproduce with the LibreOffice version currently provided by Debian testing nor with a quite current build of LibreOffice master (exact versions: s. below). Can you possibly give more exact steps on how to reproduce the issue? What I tried: 1) create a new document in Writer (called "document 1" from now on) 2) type "hello" 3) select the text "hello" 4) right click on the selection -> "Copy" 5) create a second new Writer document (called "document 2" from now on) 6) right click -> "Paste" 7) result: "hello" is pasted (as expected) 8) switch back to document 1 9) select "he" (the first two letters of "hello") 10) right click on selection -> "Copy" 11) switch to document 2 12) right click -> "Paste" 13) result: "he" is pasted (as expected) 14) switch back to document 1 15) select "llo" (the last 3 letters of "hello" 16) right click on selection -> "Copy" 17) switch to document 2 18) right click -> "Paste" 19) result: "llo" is pasted (as expected) Versions used for testing (running on KDE Plasma, Debian testing): packaged in Debian testing: Version: 6.1.2.1 Build ID: 1:6.1.2-1 CPU threads: 4; OS: Linux 4.18; UI render: default; VCL: gtk3_kde5; Locale: en-GB (en_GB.UTF-8); Calc: group threaded own build of LibreOffice master: Version: 6.2.0.0.alpha0+ Build ID: ba6723431afa843232fadf44e12ddab44e85c9f0 CPU threads: 4; OS: Linux 4.18; UI render: default; VCL: gtk3_kde5; Locale: en-GB (en_GB.UTF-8); Calc: threaded
Hi, as mentioned, my version is 6.1.1.1 Maybe its already fixed. I can't test the newer version before it appears in the "Manjaro x32" repos because compiling somethiing like libreoffice will take too much time for me. Also there is no need to create different document, i can copy paste in the same one to see the results. I'll try some other distro with fresher version.
Let's put it to RESOLVED WORKSFORME until the reporter can test it with a newer version... Put it back to UNCONFIRMED if the issue is still reproducible in 6.1.2.1 or later
Hi, still reproducable with 6.1.3 Its extremely annoying if you write scripts(bug is reproducable everywhere throughout libreoffice with gtk3 or gtk3_kde5, can't we have native Qt bindings like you do with GTK?) and i've also uncovered another regression that i will post in another bug report. I'm using X11.
(In reply to sunweb from comment #4) > Hi, still reproducable with 6.1.3 > Its extremely annoying if you write scripts(bug is reproducable everywhere > throughout libreoffice with gtk3 or gtk3_kde5, Does this also happen when you use the "plain" gtk3 VCL plugin instead of gtk3_kde5? You can select this one by setting the environment variable "SAL_USE_VCLPLUGIN=gtk3" before starting LibreOffice. Also, it may be helpful to know if this still happens with the current development version of LibreOffice. If you want to check, you can download a daily build at https://dev-builds.libreoffice.org/daily/master/ and use it as described e.g. at https://wiki.documentfoundation.org/Installing_in_parallel/Linux . > can't we have native Qt > bindings like you do with GTK?) There's actually a native qt5/kde5 backend that will be part of LibreOffice 6.2 (though it still has some bugs, s. meta bug 102495). You can also get a first impression of that by using a daily build if you like.
Yes it happens with plain gtk3 as well. I've tried to compile fresh libreoffice(checking for package version... 6.3.0.0.alpha0+) but it failed with errors after 25 hours of compiling(i can attach the log if you want to). I'm not sure i'll try it again anytime soon.
Feel free to attach the log here and I'll have a quick look. As an alternative to compiling yourself, you can also download existing daily builds, available at [1]. [2] describes how you can even use that without installing the packages on your system. [1]: https://dev-builds.libreoffice.org/daily/master/ [2]: https://wiki.documentfoundation.org/Installing_in_parallel/Linux
Created attachment 148951 [details] can't compile libreoffice I can't download daily builds because they're made for DEB/RPM based distros and i am using Manjaro. I'm attaching build log.
(In reply to sunweb from comment #8) > I can't download daily builds because they're made for DEB/RPM based distros > and i am using Manjaro. If the required tools (like 'dpkg-deb' or 'rpm2cpio') are available on Manjaro, I *think* you should be able to use the deb or rpm packages and just extract them as described in [1]. Or just download the debug builds as available e.g. at [2], since this is just a tar file. > I'm attaching build log. It indicates some unit test is failing. If you just want your build to finish, you can skip unit tests for now by running "make build-nocheck". [1] https://wiki.documentfoundation.org/Installing_in_parallel/Linux [2] https://dev-builds.libreoffice.org/daily/master/Linux-rpm_deb-x86_64@86-TDF-dbg/
I got RPM from here https://dev-builds.libreoffice.org/daily/master/Linux-rpm_deb-x86@87-TDF/current/ BY using: for i in ../*.rpm; do rpm2cpio $i | cpio -id; done I only got some: cpio: Malformed number J�����-� Extracting as a regular archive did the job though. However i can't get anything but gtk2 working. export SAL_USE_VCLPLUGIN=gtk3 && ./soffice loads gtk2 Setting up VCL as gtk3_kde5, kde5 and qt5 is also loading gtk2.
That's strange. I just tried https://dev-builds.libreoffice.org/daily/master/Linux-rpm_deb-x86_64@86-TDF-dbg/current/master_dbg~2019-02-07_10.11.14_LibreOfficeDev_6.3.0.0.alpha0_Linux_x86-64_archive.tar.gz and this one works fine and was using the gtk3 and kde5 VCL plugins when I set the SAL_USE_VCLPLUGIN environment variable accordingly...
Maybe thats because i'm using 32 bit version and pretty old hardware(OpenGL 2.1 is the maximum here) and newer libreoffice requires more or its not the case?
(In reply to sunweb from comment #12) > Maybe thats because i'm using 32 bit version and pretty old hardware(OpenGL > 2.1 is the maximum here) and newer libreoffice requires more or its not the > case? That shouldn't play a role. Can you add a link to the download you used?
https://dev-builds.libreoffice.org/daily/master/Linux-rpm_deb-x86@87-TDF/current/master~2019-02-01_18.50.31_LibreOfficeDev_6.3.0.0.alpha0_Linux_x86_rpm.tar.gz
I had a look at the build log: These builds only have gtk2 enabled. (Sorry, didn't know about this.) Since you already finished your own build, it might be easiest to just run "make build-nocheck" in your local git repo then, as mentioned in comment 9.
Hi, an update on the situation! My distribution currently updated fresh version to LibreOffice 6.2.0 and they've built it with kde5 support. Everything works as it should. Even menus aren't giant anymore and i have native file dialog, thanks!
(In reply to sunweb from comment #16) > Hi, an update on the situation! > My distribution currently updated fresh version to LibreOffice 6.2.0 and > they've built it with kde5 support. Everything works as it should. Even > menus aren't giant anymore and i have native file dialog, thanks! Thanks for retesting with the latest version. Setting to RESOLVED WORKSFORME as the commit fixing this issue hasn't been identified.