Description: Hope that nobody gets offended by this report, it is not my intention and I truly hope that I do not get misunderstood. I've been using LibO 6.2 for a while on Kubuntu linux (KDE5). On this platform LibO defaults to the new KDE5 VCL. While I greatly appreciate the effort to bring this new VCL in LibO and the much smoother transitions in between slides that you get in presentations with it, I am encountering a lot of little issues, that make me think there can be problems with a wide "production" consumption of it for the time being. As LibO is getting to its 6.2.2 release, it looks like in a short time LibO 6.2 will stop being "fresh" and shall get promoted to "still", unless the KDE5 VCL can receive fixes for most of its little problems, I expect that by that time all those KDE5 users who are not expert enough to use the SAL environment variables to force usage of other VCLs may get a little in trouble or at best confused. As you probably know, the most relevant issues are: - Weird "scrollbar" screen appearing when starting presentations - Weird behavior of the mouse/keyboard in some conditions And most important - Sudden inability to perform some actions (for instance, I've decided myself to write this report while trying to edit a presentation, I have a line selected, but there is no way to erase it pressing DEL) - Some unexpected crashes every now and then Among these, the third one seems the most troublesome problem now (may be related to the second, though). My intention here is not to reiterate these issues (that have probably already been reported), rather to submit the following suggestions for consideration, in order to provide some more time to the KDE5 (and QT5) VCL plugins to reach a perfect cooking while preserving the less experienced linux users from problems that may reduce the LibO appeal to them. 1) Please, consider keeping around the KDE4 VCL for one more release (do not remove it in 6.3) 2) Please, provide an easier way to configure the VCL than the SAL_USE_VCLPLUGIN environment variable. For instance, the "Advanced" option tab could include a "Use conservative view module" option when significant changes in VCLs are introduced. I apologize again if this report may appear to the developers of the KDE5 VCL as diminutive with respect to their achievements. This is definitely not the intention. Conversely, I appreciate this work very much. Steps to Reproduce: See description. Actual Results: See description. Expected Results: See description. Reproducible: Always User Profile Reset: No Additional Info: [Information automatically included from LibreOffice] Locale: en-US Module: PresentationDocument [Information guessed from browser] OS: Linux (All) OS is 64bit: yes Version: 6.2.2.1 Build ID: fcd633fb1bf21b0a99c9acb3ad6e526437947b01 CPU threads: 8; OS: Linux 4.18; UI render: default; VCL: kde5; Locale: it-IT (en_US.utf8); UI-Language: en-US Calc: threaded
Thank you for considering this topic and caring about end users. (In reply to sergio.callegari from comment #0> > I've been using LibO 6.2 for a while on Kubuntu linux (KDE5). On this > platform LibO defaults to the new KDE5 VCL. While I greatly appreciate the > effort to bring this new VCL in LibO and the much smoother transitions in > between slides that you get in presentations with it, I am encountering a > lot of little issues, that make me think there can be problems with a wide > "production" consumption of it for the time being. [...] Some initial thoughts: * I do agree that I wouldn't call kde5 production-ready at it's current stage. * As you mentioned, LibreOffice 6.2 is currently "fresh" and it will remain so until 6.3 is released, which is scheduled for August. * I do agree that "ordinary" users shouldn't be bothered with setting environment variables. * Should the decision be that kde5 is not "ready" yet: * One approach might be to change the default selection order of VCL plugins, e.g. prefer gtk3_kde5 over kde5. * Another approach might be to say that it's up to the people packaging or installing the software to decide whether or not to enable/install the kde5 VCL plugin in the first place (i.e. no need to set environment variables if the '*-kde-integration' package isn't installed anyway) > As you probably know, the most relevant issues are: > - Weird "scrollbar" screen appearing when starting presentations > - Weird behavior of the mouse/keyboard in some conditions > And most important > - Sudden inability to perform some actions (for instance, I've decided > myself to write this report while trying to edit a presentation, I have a > line selected, but there is no way to erase it pressing DEL) > - Some unexpected crashes every now and then There's a meta bug, tdf#102495, for keeping track of kde issues. Please do create new bug reports if anything isn't covered there yet. Without checking all of those, I'm currently not aware of any reports for your second and third case, but in particular the second one is rather vague and nothing that can be handled properly without clear steps on how to reproduce... IMHO, any potential decision to switch off kde5 as default (for those desktops where it currently is the default) should be based on bug reports there. > 1) Please, consider keeping around the KDE4 VCL for one more release (do not > remove it in 6.3) IMHO, this is not an option, since bringing it back would take quite some effort and it's certainly not a long-term solution, so I think that effort would better be spent elsewhere (e.g. in improving kde5). Should kde5 not be the way to go now, I'd rather suggest to go with gtk3_kde5 or gtk3. Anyway, kde4 is still available for 6.2 - and 6.3 is still quite a bit ahead, so at least for 6.3, I think it's too early to take any decision as of now. For 6.2, a decision could either be taken now/soon or once it gets closer to becoming "still". - I don't know what's better. > > 2) Please, provide an easier way to configure the VCL than the > SAL_USE_VCLPLUGIN environment variable. For instance, the "Advanced" option > tab could include a "Use conservative view module" option when significant > changes in VCLs are introduced. Making kde5 an experimental feature might be an alternative which uses an already established mechanism. That's just my thoughts, any other opinions are welcome...
Hullo, > Hope that nobody gets offended by this report, it is not my intention and I > truly hope that I do not get misunderstood. Even if nobody said 'you people suck and your KDE5 code sucks' I'm so offended and I'm going to cry into my flowery pillow :D Just kidding > As LibO is getting to its 6.2.2 release, it looks like in a short time LibO > 6.2 will stop being "fresh" and shall get promoted to "still", unless the > KDE5 VCL can receive fixes for most of its little problems, I expect that by > that time all those KDE5 users who are not expert enough to use the SAL > environment variables to force usage of other VCLs may get a little in > trouble or at best confused. In general any X.Y.2 LibO isn't for faint-hearted or even production-ready, this is made abundantly clear all over the place so users who don't want to get confused should stick to Still version. It was no different when gtk3 plugin was new, fwiw In other words, it is bit too early to panic. If it is this broken some 4-5 months down the road, let's talk again. > As you probably know, the most relevant issues are: > - Weird "scrollbar" screen appearing when starting presentations FWIW I fixed this one > - Weird behavior of the mouse/keyboard in some conditions > And most important > - Sudden inability to perform some actions (for instance, I've decided > myself to write this report while trying to edit a presentation, I have a > line selected, but there is no way to erase it pressing DEL) Never heard of those two, please file a ticket > My intention here is not to reiterate these issues (that have probably > already been reported), rather to submit the following suggestions > > 1) Please, consider keeping around the KDE4 VCL for one more release (do not > remove it in 6.3) Nope. If anything, gtk3_kde5 should be the default. > 2) Please, provide an easier way to configure the VCL than the > SAL_USE_VCLPLUGIN environment variable. For instance, the "Advanced" option > tab could include a "Use conservative view module" option when significant > changes in VCLs are introduced. ... and with that, kde5 could be hidden behind experimental features. But from what you've written, it doesn't look like anything of that will be necessary, those issues you describe don't look terribly complex or difficult to fix ?
Thanks for all the clarifications. My report was concerned with the fact that 4 months before 6.3 are really not those many, and that even if "fresh" and particularly a .2 is not for the faint hearted, it is the first time in which using "fresh" I find myself really a bit bad a ease with bug reporting. In fact my problem are not the bugs themselves, but actually their nature that this time is quite subtle. I really cannot find what triggers behaviors like those at points 2/3 in my previous post, so I find it very hard to open bugs that make sense or that can be at least slightly useful, and this is probably what makes me see the 4 months shorter than they actually are. For what concerns the gtk3_kde5 VCL, on my system if I launch LibO as: SAL_USE_VCLPLUGIN=kde4 libreoffice6.2 then it uses the kde4 plugin with SAL_USE_VCLPLUGIN=gtk3 libreoffice6.2 then it uses the gtk3 plugin but with SAL_USE_VCLPLUGIN=gtk3_kde5 libreoffice6.2 still it seems to use the kde5 VCL and it reports using the kde5 VCL. This is why I was suggesting keeping around the kde4 VCL. On my kubuntu 18.10 installation using LibO with the Document Foundation packages, the gtk3_kde5 VCL does not seem to be selectable.
(In reply to Katarina Behrens (CIB) from comment #2) > In other words, it is bit too early to panic. If it is this broken some 4-5 > months down the road, let's talk again. I took this topic to today's ESC (Engineering and Steering Committee) call and the decision (according to suggestion) was to take some more time, keep an eye and take a decision once 6.2 is getting closer to become "still" (i.e. the 6.3 release). From the minutes (to become available in the mailing list archives at [1] sometime soon): * keep kde5 as default on KDE Plasma and LXQt desktops for LibreOffice 6.2? (Michael W) + kde5 is currently default on Plasma & LXQt + tdf#124044 correctly states it’s not yet ready for “production” + concerned that by the time 6.2 is ‘still’ - will it be ready. + talked with Bubli – and suggest waiting some weeks until 6.2.5 + happy if you are (Michael) + if you do the work – you decide (Miklos) => leave it to those doing the work to decide. So basically, a decision is supposed to be taken in time for LO 6.2.5 (s. schedule at [2]). (In reply to sergio.callegari from comment #3) > My report was concerned with the fact that 4 months before 6.3 are really > not those many, and that even if "fresh" and particularly a .2 is not for > the faint hearted, it is the first time in which using "fresh" I find myself > really a bit bad a ease with bug reporting. I do understand quite well. On the other hand, there's been quite some positive reaction on kde5 as well, so I think it's reasonable to do as outlined above. I'd like to encourage you to keep track of the current status and tell us how you see it once again it get's closer to the 6.2.5 freeze. > In fact my problem are not the bugs themselves, but actually their nature > that this time is quite subtle. I really cannot find what triggers behaviors > like those at points 2/3 in my previous post, so I find it very hard to open > bugs that make sense or that can be at least slightly useful, and this is > probably what makes me see the 4 months shorter than they actually are. In case you can still find out more about this, this would be really helpful for any developer considering to look into this, and thus for getting those ugly things fixed. It's OK for a bug to not be 100 % reproducible and say e.g. "When I do this, about 1 out of 10 times, this and that fails." While those are for sure not the nicest bugs to analyse, it's not uncommon and there are ways to deal with that. > For what concerns the gtk3_kde5 VCL, on my system if I launch LibO as: > > SAL_USE_VCLPLUGIN=kde4 libreoffice6.2 > > then it uses the kde4 plugin > > with > > SAL_USE_VCLPLUGIN=gtk3 libreoffice6.2 > > then it uses the gtk3 plugin > > but with > > SAL_USE_VCLPLUGIN=gtk3_kde5 libreoffice6.2 > > still it seems to use the kde5 VCL and it reports using the kde5 VCL. > > This is why I was suggesting keeping around the kde4 VCL. On my kubuntu > 18.10 installation using LibO with the Document Foundation packages, the > gtk3_kde5 VCL does not seem to be selectable. The packages provided by TDF actually don't include gtk3_kde5. In case it's decided to "disable" kde5 for 6.2, the easiest thing would probably be to revert commit [3], resulting in kde5 not to be chosen automatically any more, but the order on KDE Plasma and LXQt then becoming: gtk3_kde5, kde4, gtk3, gtk, gen In your case, where gtk3_kde5 is not available, that would mean that kde4 would be used (as desired). People still wanting to use kde5 would then have to set the SAL_USE_VCLPLUGIN environment variable (i.e. kde5 would become opt-in rather than opt-out in some sense...) [1] https://lists.freedesktop.org/archives/libreoffice/2019-March/thread.html [2] https://wiki.documentfoundation.org/ReleasePlan/6.2#6.2.5_release [3] https://gerrit.libreoffice.org/plugins/gitiles/core/+/f2bf002e90bf5cc74cf190d66507e59b78ba73e9%5E!
Thank you Michael for reporting here the strategy you proposed. I very much appreciate having the ability to see where the project goes and what is being suggested. And I also very much appreciate seeing that user feedback is taken in consideration with so much care and promptness! For the plan, I obviously believe that it makes a lot of sense. Thank you also for thoroughly answering to my previous message. I'll definitely keep trying the kde5 vcl as new releases come out on the 6.2 branch and keep trying to do my best in trying to help the developers with some feedback when I find something worth reporting. In the meantime, there is something that is still not 100% clear to me. Is the building of the gtk3_kde5 vcl plugin incompatible with that of the kde5 vcl plugin in the LibO deb packages? I am (maybe wrongly) getting this impression from your last statement: "In case it's decided to "disable" kde5 for 6.2, the easiest thing would probably be to revert commit [3], resulting in kde5 not to be chosen automatically any more, but the order on KDE Plasma and LXQt then becoming: gtk3_kde5, kde4, gtk3, gtk, gen" from which it seems like either you have gtk3_kde5 or kde5 on the plugin list. Would it be possible (and sensible) to ship both the gtk3_kde5 plugin and the kde5 for the time being, so letting people on KDE plasma play with both gtk3_kde5 and kde5 in view of the decision that might be taken at 6.2.5?
Thank you for your reply. (In reply to sergio.callegari from comment #5) > In the meantime, there is something that is still not 100% clear to me. Is > the building of the gtk3_kde5 vcl plugin incompatible with that of the kde5 > vcl plugin in the LibO deb packages? No; it's possible to build (and package) all VCL plugins at the same time; it's just that the packages provided by TDF don't do so. > Would it be possible (and sensible) to ship both the gtk3_kde5 plugin and > the kde5 for the time being, so letting people on KDE plasma play with both > gtk3_kde5 and kde5 in view of the decision that might be taken at 6.2.5? It's possible, but currently not done for the TDF packages. I'd currently not add another VCL plugin for TDF's 6.2 builds. Since gtk3_kde5 is basically gtk3, with the difference that native kde5 file dialogs are used, using gtk3 would give you quite a good impression of gtk3_kde5 as well. > "In case it's decided to "disable" kde5 for 6.2, the easiest thing would > probably be to revert commit [3], resulting in kde5 not to be chosen > automatically any more, but the order on KDE Plasma and LXQt then becoming: > gtk3_kde5, kde4, gtk3, gtk, gen" > > from which it seems like either you have gtk3_kde5 or kde5 on the plugin > list. The list is used to decide which VCL plugin is used by default. The first one available will be used. In case the decision should be to switch back defaults, I'd personally go back to the state it was in before (which position should kde5 take otherwise?). kde5 could still be used by setting the environment variable.
It should be rather easy to include the gtk3_kde5 VCL plugin, since we already build gtk3 and kde5. Please ask in the next ESC call to include it, so people can easier cross-check and verify. AFAIK you just need the additional configure option --enable-gtk3-kde5. I thought distro-configs/LibreOfficeLinux.conf would be the TDF build (it's also written in distro-configs/README), so I could have prepared a quick patch, but it turns out it includes (on master): --disable-kde5 --disable-gtk3 That's definitely not the TDF build and not Jenkins, since these configs are (supposed to be) in distro-configs/Jenkins/ $ git show origin/libreoffice-6-2:distro-configs/LibreOfficeLinux.conf --enable-kde4 --disable-gtk3 and no kde5 at all?! I'm all for making the "kde5" in the fallback list depend on the experimental option, if it'll still be too buggy in three months.
Hi Bubli, Michael Weghorn, Jmux, LibreOffice 6.2.4.1 is planned to be tagged this week [1]. I think it's time to decide whether we keep KDE5 or we fallback to KDE4 ( or gtk3-kde5 ). I'll add it to the esc agenda. What is your opinion on this? Right now we have 30 bugs open [2] and none of them is critical/major [1] https://wiki.documentfoundation.org/ReleasePlan/6.2#6.2.4_release [2] https://bugs.documentfoundation.org/buglist.cgi?bug_severity=blocker&bug_severity=critical&bug_severity=major&bug_severity=normal&bug_severity=minor&bug_severity=trivial&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&f1=blocked&list_id=947008&o1=substring&query_format=advanced&resolution=---&v1=102495
(In reply to Xisco Faulí from comment #8) > Hi Bubli, Michael Weghorn, Jmux, > LibreOffice 6.2.4.1 is planned to be tagged this week [1]. I think it's time > to decide whether we keep KDE5 or we fallback to KDE4 ( or gtk3-kde5 ). > I'll add it to the esc agenda. What is your opinion on this? > Right now we have 30 bugs open [2] and none of them is critical/major Imo at least those annoying bugs should be fixed: bug 122239 (X11 primary selection still buggy in Writer) bug 124484 (can't fix the problem but at least the crash must not happen) bug 120870 and its spin-off bug 120470 (video overlay broken in slideshow) Here are some crashers that only happen w/ a11y enabled (on one hand, small subset of users affected, but if affected, it is very visible): bug 120556 bug 122200 (tentative dupe of bug 122200) There is also bug 123859 but I'm pretty confident if there's any remaining crasher, it is now outside kde5 code. With the bugs from the first group fixed, I would keep kde5 in 6.2
Oh geez why can't I edit my own comments in this ancient bug-tracking system? > bug 120870 and its spin-off bug 120470 (video overlay broken in slideshow) spin-off is bug 124027 > bug 122200 (tentative dupe of bug 122200) bug 122200 (tentative dupe of bug 122056)
I agree with bubli wrt most annying issues that should be fixed. In addition to the first list, I'd add tdf#120774, which is already fixed on master but needs some more work to be backported to 6.2 (In reply to Katarina Behrens (CIB) from comment #9) > With the bugs from the first group fixed, I would keep kde5 in 6.2 Sounds reasonable to me. @Sergio, as the original reporter: Anything you want to add here or any other concerns? (Let's set bug status to NEW in the meanwhile)
Consensus in today's ESC call was to keep kde5 enabled by default for 6.2.4 and decide for 6.2.5 depending on whether the mentioned bugs are fixed. From the minutes: > * KDE5 (Xisco) > + about to ship 6.2.4 rc1 - will be the 'still' version - do we want to keep KDE5 enabled by default ? > + Bubli believes there are some blockers to this currently. > + discussed this in March already (Michael W) > + decide in 6.2.5 on current status. > + propose to keep it as default for 6.2.4 and also for 6.2.5 if these are fixed: > + people doing the work should make the call (Michael) > + https://bugs.documentfoundation.org/show_bug.cgi?id=124044#c9 ( Bubli ) > + Primary selection does not work under KDE > https://bugs.documentfoundation.org/show_bug.cgi?id=122239 > + Impress crashes on slide show using "All displays" > https://bugs.documentfoundation.org/show_bug.cgi?id=124484 > + KDE5: UI is broken if opening a document with a video > https://bugs.documentfoundation.org/show_bug.cgi?id=120870 > + 2 accessibility crashes > => consensus on keeping it as default for now (Xisco, Thorsten etc.)
(In reply to Jan-Marek Glogowski from comment #7) > It should be rather easy to include the gtk3_kde5 VCL plugin, since we > already build gtk3 and kde5. Please ask in the next ESC call to include it, > so people can easier cross-check and verify. AFAIK you just need the > additional configure option --enable-gtk3-kde5. That also was adressed in the same call now (sorry for the delay!): > * enable kde5 and gtk3_kde5 in bibisect repo and > gtk3_kde5 for release build (x86_64)? (Michael W) > + build machines seem to have the right libraries. > + can these options be enabled ? > + would be really useful now (Thorsten) > + can we enable gtk3_kde5 - affecting 64bit too > + CentOS6 for x86 still, but can do some cross-compile for master going forward, using CentOS7 x86_64 (Thorsten) > + -m32 and some x86-devel packages and then it works. > + they take the config from lode / distro configs (Christian) > + if update it - will pickup the switches for bibisect > + not sure if we stay with kde5 - good to have the gtk3 fallback tested (Michael W) > + thought it was an exclusive switch (Christian) > + a run-time plugin; with KDE5 file-picker in a separate process (Micahel W) > + just gain functionality ? (Christian) > + yes (Michael W) > AI: + enable that in the distro config (Christian) > + was not included because tinderboxen were not updated, but no longer an issue (Christian)
Please also consider bug 122668 that seems to only occur with the KDE5 VCL and that may make presentations impossible with LibO 6.2 and the KDE5 VCL.
(In reply to sergio.callegari from comment #14) > Please also consider bug 122668 that seems to only occur with the KDE5 VCL > and that may make presentations impossible with LibO 6.2 and the KDE5 VCL. It's fixed on master now. :-)
LO 6.2.5rc1 will be tagged this week. The (known) blocking issues mentioned above (and more) have been fixed in the meanwhile and fixes were backported for the upcoming 6.2.5 release. What is left is that X11 primary selection doesn't work from Writer to external applications (s. bug 122239), which does have a fix for master pending in Gerrit, but it's a rather large one, so too risky to "quickly backport" it for 6.2.5, and possibly even 6.2.6. We (Katarina, Jan-Marek, me) discussed the current status today and don't see a reason to disable kde5 as default for 6.2 (on X11) any more and today's ESC call followed that suggestion. From the minutes: * Leave kde5 by default on Plasma/LXQt for 6.2.5 (tdf#124044) (Michael W, Jan-Marek) + The only real problem left is the the PRIMARY selection - Doesn’t work from Writer to external applications, but does otherwise e.g. inside LO or from external applications to LO - Fix for master / 6.3: https://gerrit.libreoffice.org/#/c/73288/ - That is a whole rewrite of the clipboard and D’n’D code for Qt5. - bubli, jmux and michael decided to postpone the backport decision to 6.2.6, but will very likely just skip it for 6.2 completely + We disabled kde5 for Wayland, as this has still major problems - FYI: currently any LO crashes on KDE Wayland https://bugs.kde.org/show_bug.cgi?id=408358 + We want to keep kde5 enabled for still - when the pending 6.2 patches are merged => suggest to keep things unchanged Therefore, closing this bug now. Thanks again for reporting it, your concern and and help to make LibreOffice better!
Thanks for the very rapid time in which the bugs that were worrying me about the kde5 vcl have been fixed!
I think that there may be also 125944 to consider.
(In reply to sergio.callegari from comment #18) > I think that there may be also 125944 to consider. I also have the problem with LibreOffice 6.2.8.2-2/KDE5/Fedora 31 KDE Desktop/Spins upon this matter, TDF#127642. I tried by installing Fedora 31 GNOME Desktop which LibreOffice 6.3.3.2.0+ is bundled with gtk3. And the problem , TDF#127642 has gone. Why LO has various VCL's ?
(In reply to Nukool Chompuparn from comment #19) > Why LO has various VCL's ? Those are to provide better integration with different desktop environments, e.g. the qt5/kde5/kf5 VCL plugin is supposed to provide a similar look and feel to other Qt/KDE applications when using LXQt or Plasma as desktop environment.