Description: libreoffice-kde5 file dialog doesn't add automatically the file extension which are important for.docx .xlsx, otherwise the system recognize them as zip. When removing that package and letting only libreoffice-gtk, extension are added automatically. Steps to Reproduce: 1. if isn't installed install libreoffice-kde5 package 2. save a writer document as .docx but doesn't add manually the extension Actual Results: file are saved without .docx extension. Expected Results: file should be saved with the .docx extension Reproducible: Always User Profile Reset: No Additional Info: Using lubuntu 18.10 Version: 6.1.4.2 Build ID: 1:6.1.4-0ubuntu1 CPU threads: 2; OS: Linux 4.18; UI render: default; VCL: gtk3_kde5; Locale: es-CL (es_CL.UTF-8); Calc: group threaded
On my Linux PC, LibreOffice vanilla works properly with all flavours of Ubuntu 18.10. IMHO, bug has to be filed at KDE or Canonical as the software is tweaked/recompiled by them.
Thank you for reporting the bug. KDE5 support has been hugely improved in LibreOffice 6.2. Could you please try to reproduce it with LibreOffice 6.2 from https://wiki.documentfoundation.org/QA/GetInvolved#Test_Pre-releases? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
I installed 6.2RC2 but I don't get the "kde look" in the file picker/dialog that the libreoffice-kde5 package gave me. In help->about appears VCL:kde4 and not gtk3_kde5 which i was getting before. I don't know who is responsible of libreoffice-kde5 package, but there is the problem. vanila LO works ok in 6.1.4.2 and 6.2. Should I file KDE or Ubuntu? Who is responsible for libreoffice-kde5 https://packages.ubuntu.com/disco/libreoffice-kde5 ? Version: 6.2.0.2 Build ID: 2ce5217b30a543f7666022df50f0562f82be0cff CPU threads: 2; OS: Linux 4.18; UI render: default; VCL: kde4; Locale: es-CL (es_CL.UTF-8); UI-Language: en-US Calc: threaded
I installed 6.2.0.2 in an up-to-date lubuntu 18.10 VM as you suggested Xisco. I can confirm that the issue Hans is reporting is still there: the VCL is "kde5", the save dialog doesn't have an option to add the file extension automatically, and files are saved without an extension if not explicitly added.
FYI KDE4 used to have its own auto-extension checkbox in the file open dialog, so the LO KDE4 integration used that KDE setting and skipped LOs' own handling. Probably that setting doesn't exist anymore, as file dialogs are now Qt5 based and now LO has to handle the file auto-extension on its own.
Created attachment 148457 [details] Screenshot of save dialog in KDE 5 For me, with a current daily build of the "master" branch, the file extension is automatically added when using the "kde5" VCL plugin and taking these steps: 1) open a new Writer document 2) "File" -> "Save as" 3) type "test" as file name (without ".docx" at the end) 4) select filter "Word 2007-2019 (.docx)" 5) make sure the checkbox "Automatically select filename extension" is checked 6) click "OK" The attached screenshots shows the dialog at the point in time I click "OK". The file is the saved as "test.docx". Is this the scenario that this bug report is covering or did I misunderstand anything? Version: 6.3.0.0.alpha0+ Build ID: 87bf8b7900fe4757bd8494f7a72966915f653eb6 CPU threads: 2; OS: Linux 4.19; UI render: default; VCL: kde5; TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2019-01-19_19:05:11 Locale: en-US (en_DK.UTF-8); UI-Language: en-US Calc: threaded With an older build of master (~1 month old, as of commit 6ba8d6533081dab96c00695dd7a908e0f7bcf164; currently don't have a newer one with gtk3_kde5 available), I can confirm that this works as described above with kde5, but not with gtk3_kde5. So this looks like it might be a gtk3_kde5 problem only, but I might be missing something...
Created attachment 148473 [details] lubuntu LXQt file saver Hi Michael, the problem is in Lubuntu 18.10 which uses LXQt, the checkbox doesn't exist there (see attachment). In KDE it exists, as you pointed. Who creates the checkbox? Libreoffice or the filemanager (in kubuntu dolphin)?
(In reply to Hans P. Möller from comment #7) > Who creates the checkbox? Libreoffice or the filemanager (in kubuntu > dolphin)? A quick search suggests that kio is responsible for this in KDE Plasma, s. https://sources.debian.org/src/kio/5.51.0-1/src/filewidgets/kfilewidget.cpp/?hl=2312#L2312 (but I didn't have a closer look)
(In reply to Hans P. Möller from comment #7) > Created attachment 148473 [details] > lubuntu LXQt file saver @Hans: Is that screenshot with LibreOffice 6.1 and the the gtk3_kde5 VCL plugin or with 6.2 and the kde4 one? Btw, when using the "qt5" VCL plugin (i.e. starting LibreOffice with the env variable "SAL_USE_VCLPLUGIN=qt5" set), the checkbox is also there, but seems to have no effect, the file extension is not added.
(In reply to Michael Weghorn from comment #9) > (In reply to Hans P. Möller from comment #7) > > Created attachment 148473 [details] > > lubuntu LXQt file saver > > @Hans: Is that screenshot with LibreOffice 6.1 and the the gtk3_kde5 VCL > plugin or with 6.2 and the kde4 one? > > Btw, when using the "qt5" VCL plugin (i.e. starting LibreOffice with the env > variable "SAL_USE_VCLPLUGIN=qt5" set), the checkbox is also there, but seems > to have no effect, the file extension is not added. with LO 6.1 and VCL=gtk3_kde5. I havent been able to run 6.2 with VCL=kde5, only kde=4. But Olivier could and had the same issue.
Created attachment 148495 [details] LO 6.2 Lubuntu 18.10 filepicker Here it is screenshot of LO 6.2 with lubuntu 18.10. Filepicker doesn't have the add extension checkbox
As your screenshots show, more custom controls are missing in the save dialog when run on LXQt ("Save with password", "Encrypt with GPG key"). I just tested with LXQt on Debian testing and can confirm the behaviour is the same with a current daily build of master and using the kde5 VCL plugin. This is rather unfortunate, since kde5 is selected as the default VCL plugin there... All controls are there when using e.g. the gtk3 VCL plugin instead. Btw, when using the plain qt5 VCL plugin, the controls are also there (but the file extension is not added, regardless of whether the checkbox is enabled...).
how can I change it to use the qt5 VCL? I thought there where only kde and gtk
(In reply to Hans P. Möller from comment #13) > how can I change it to use the qt5 VCL? I thought there where only kde and > gtk Set "SAL_USE_VCLPLUGIN=qt5". In fact, there's currently quite a bunch of VCL plugins on Linux (gtk, gtk3, kde4, kde5, gtk3_kde5, gen,...), some of them deprecated already (kde4 e.g. has already been removed from the current development version). Note however, that qt5 (which kde5 is based upon) and kde5 are only available from 6.2 on and currently still have several known issues... (s. meta bug 102495).
(In reply to Michael Weghorn from comment #14) > (In reply to Hans P. Möller from comment #13) > > how can I change it to use the qt5 VCL? I thought there where only kde and > > gtk > > Set "SAL_USE_VCLPLUGIN=qt5". > > In fact, there's currently quite a bunch of VCL plugins on Linux (gtk, gtk3, > kde4, kde5, gtk3_kde5, gen,...), some of them deprecated already (kde4 e.g. > has already been removed from the current development version). Note > however, that qt5 (which kde5 is based upon) and kde5 are only available > from 6.2 on and currently still have several known issues... (s. meta bug > 102495). Did you try this in lubuntu? it doesn't work in my case. I had to use export instead of set to change the envvar but it still launches with vcl=kde4
> > Did you try this in lubuntu? it doesn't work in my case. I had to use export > instead of set to change the envvar but it still launches with vcl=kde4 Nevermind, I could do it with ~$ SAL_USE_VCLPLUGIN=qt5 libreoffice6.2 --writer
So VCL=qt5 havs the checkbox but doesn't add the extension. Should I open a new bug?
Sorry for my misleading comment 14. That was not meant as a command to be executed "as is", but rather as a "human-readable instruction" that first had to be converted into a "machine-readable command" like the one you used... (In reply to Hans P. Möller from comment #17) > So VCL=qt5 havs the checkbox but doesn't add the extension. Should I open a > new bug? Yes, that would be good. I think it makes sense to deal with these two things separately. (This behaviour matches my observations from comment 9.)
Michael Weghorn committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/c902b3a96dcfbc52e53164f108e605547e598bc7%5E%21 tdf#122752 kde5: Use plain qt5 fpicker for non-Plasma desktops It will be available in 6.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Weghorn committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/bf93bae6990b01ee726b59b0969b93585719671a%5E%21 tdf#122752 gtk3_kde5: Use non-native fpicker for non-Plasma desktops It will be available in 6.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Backports for LibreOffice 6.2 for the two commits: https://gerrit.libreoffice.org/#/c/67131/ https://gerrit.libreoffice.org/#/c/67132/ With these commits, you will get the plain Qt5FilePicker that has all custom controls with "kde5" (but the file auto extension not yet working, s. comment 17 -> to be handled separately). For the "gtk3_kde5" case, all custom options except for the file autoextension checkbox are there. Personally, I'm not sure whether investing time into adding the file auto-extension to the gtk3_kde5 file picker (for the non-Plasma case) makes much sense, since 1) kde5 is "the future" and will be used instead of gtk3_kde5 by default from LibreOffice 6.2 (on KDE Plasma and LXQt desktops) 2) The idea of gtk3_kde5 is to use the stable gtk3 VCL plugin and just add a native KDE filepicker on top. Since LXQt cannot use that one anyway, there seems to be little value in using gtk3_kde5 over gtk3 anyway... I'd rather suggest to change the order, so that LXQt prefers the plain gtk3 VCL plugin over the gtk3_kde5 one. Any other opinions on this?
Michael Weghorn committed a patch related to this issue. It has been pushed to "libreoffice-6-2": https://git.libreoffice.org/core/+/71562327d4f4d9d46b129fbb41184f21116ba78d%5E%21 tdf#122752 kde5: Use plain qt5 fpicker for non-Plasma desktops It will be available in 6.2.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Weghorn committed a patch related to this issue. It has been pushed to "libreoffice-6-2": https://git.libreoffice.org/core/+/9455565fba299645372ddf432d25b679af51281f%5E%21 tdf#122752 gtk3_kde5: Use non-native fpicker for non-Plasma desktops It will be available in 6.2.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Better late than never... > 2) The idea of gtk3_kde5 is to use the stable gtk3 VCL plugin and just add a > native KDE filepicker on top. Since LXQt cannot use that one anyway, there > seems to be little value in using gtk3_kde5 over gtk3 anyway... > I'd rather suggest to change the order, so that LXQt prefers the plain gtk3 VCL > plugin over the gtk3_kde5 one. > > Any other opinions on this? I disagree. It's Lx*Qt*, so one should prefer the qt5 plugin. But does it have a file picker? Regards, Rene
Hi Rene, (In reply to Rene Engelhard from comment #24) > > I disagree. It's Lx*Qt*, so one should prefer the qt5 plugin. But does it > have a file picker? Yes, the qt5 plugin does have a file picker (which is currently used for the lxqt case even when the kde5 plugin is used, s. commit from comment 19). Currently, LXQt selects the VCL plugin to use in the same order as kde5, s. [1], i.e. it tries "kde5" (where it gets the plain qt5 file picker), then "gtk3_kde5", "gtk3", "gtk", "gen. Other than the "kde5" plugin, plain "qt5" uses native Qt rendering instead of Cairo rendering, which is more of an experiment at the moment, and not really usable so far, so it's not included in any fallback list and I don't think it would make sense to set it as default for LXQt at the current stage. IMHO, there are two questions to answer: A) What should be the first option on LXQt (i.e. the first entry in it's "fallback list"? I'd currently see these 2 options: * a) leave kde5 the first option (as is) * b) write a separate vcl plugin on top of qt5 that uses Cairo rendering (similar to what kde5 does) B) What should be the order of all other VCL plugins in the fallback list for LXQt? For A), I'd personally suggest to leave it as is for now, until the qt5 and kde5 plugins have matured a little more, and potentially revisit the question then (and avoid the overhead of keeping a separate plugin in sync now). My previous comment was targeted at question B), and one thought of mine was to drop gtk3_kde5 from the list for the LXQt case, for the reasons mentioned in comment 21, which would mean that the fallback list for LXQt would be ["kde5", "gtk3", "gtk", "gen"] in case A) stays as is. That's just my personal opinion though, and I'd be interested to hear what you think about this. [1] https://gerrit.libreoffice.org/plugins/gitiles/core/+/master/vcl/source/app/salplug.cxx#189
(In reply to Michael Weghorn from comment #25) > My previous comment was targeted at question B), and one thought of mine was > to drop gtk3_kde5 from the list for the LXQt case, for the reasons mentioned > in comment 21, which would mean that the fallback list for LXQt would be > ["kde5", "gtk3", "gtk", "gen"] in case A) stays as is. Or one could just live with the fact that adding file extension doesn't work automatically with gtk3_kde5 on non-Plasma desktops. Or make it work, but I'm not sure whether the time would be spent better at other places right now.
I'm closing this bug report. Please leave a comment here or open a new bug if you think anything else still needs to be done.
*** Bug 123595 has been marked as a duplicate of this bug. ***