Description: If I install libreoffice-kde5 that provides QT5/KDE integration, when I try to save the file with a different name or produce a pdf with it, the "save" dialog defaults to home directory and misses the file name (empty box) Steps to Reproduce: 1. install libreoffice 6.1 with libreoffice-kde5 2. open a file, i.e. with Writer (i.e. double click in Dolphin file manager) 3. press File -> Save as Actual Results: a file dialog is open, but the default destination is home directory (not the original file one) and file name box is empty Expected Results: File dialog shout default to the original file directory and have the original file name Reproducible: Always User Profile Reset: Yes OpenGL enabled: Yes Additional Info: [Information automatically included from LibreOffice] Locale: it Module: StartModule [Information guessed from browser] OS: Linux (All) OS is 64bit: yes Versione: 6.1.0.2 Build ID: 1:6.1.0~rc2-3 Thread CPU: 4; SO: Linux 4.17; Resa interfaccia: predefinito; VCL: gtk3_kde5; Versione locale: it-IT (it_IT.UTF-8); Calc: group threaded plasma-desktop 5.13 libqt5 5.11
Yep
Katarina Behrens committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=87a4623a8dd5c9efed8335bb56145b9ea9dcce36 tdf#119133: Fix initial file and folder selection It will be available in 6.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Thanks for the fix! At a quick test, the file name is now properly initialized. However, when running KDE Plasma 5, the preselected directory is now always "$HOME/Documents", no matter where the currently open document is located. It was just "$HOME" before, but should be the directoy holding the current file. This seems to come from method 'css::beans::Optional<css::uno::Any> getValue(OUString const& id)' (with id "WorkPathVariable") in 'shell/source/backends/kde5be/kde5access.cxx'.
> At a quick test, the file name is now properly initialized. > However, when running KDE Plasma 5, the preselected directory is now always > "$HOME/Documents", no matter where the currently open document is located. > It was just "$HOME" before, but should be the directoy holding the current > file. > > This seems to come from method 'css::beans::Optional<css::uno::Any> > getValue(OUString const& id)' (with id "WorkPathVariable") in > 'shell/source/backends/kde5be/kde5access.cxx'. Can't confirm. I do SAL_USE_VCLPLUGIN=gtk3_kde5 soffice Open /path/to/example/file.ods Save As File name is pre-filled with "file.ods", fpicker is in folder "/path/to/example". So what am I doing wrong? Also, is this master or 5.2@LiMux?
(In reply to Katarina Behrens (CIB) from comment #4) > Can't confirm. I do > > SAL_USE_VCLPLUGIN=gtk3_kde5 soffice > Open /path/to/example/file.ods > Save As > > File name is pre-filled with "file.ods", fpicker is in folder > "/path/to/example". So what am I doing wrong? Also, is this master or > 5.2@LiMux? master. Further experimenting turned out it depends on the actual path on what happens. The document's directory is preselected in the file picker if file path is e.g. "~/file.ods" or "/mnt/external_ssd/data/file.ods", but not if it's "/tmp/file.ods". Is this intended?
(In reply to Michael Weghorn from comment #5) > [...] > > Is this intended? At least the gtk3 vclplug behaves the same, so it's in any case unrelated to this change. (The intention might be to protect users from accidently saving files at a place that's gone after reboot or so, but I haven't investigated further.) Sorry for the noise...
> At least the gtk3 vclplug behaves the same, so it's in any case unrelated to > this change. (The intention might be to protect users from accidently saving > files at a place that's gone after reboot or so, but I haven't investigated > further.) Not letting users save into /tmp (as unexpected as it may be) is intentional indeed, see bug 43895
(In reply to Katarina Behrens (CIB) from comment #7) > Not letting users save into /tmp (as unexpected as it may be) is intentional > indeed, see bug 43895 Thanks for the hint!
Katarina Behrens committed a patch related to this issue. It has been pushed to "libreoffice-6-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=bb95d1843e5812c9f2bbecdff80f59b83be013db&h=libreoffice-6-1 tdf#119133: Fix initial file and folder selection It will be available in 6.1.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 119450 has been marked as a duplicate of this bug. ***
*** Bug 119422 has been marked as a duplicate of this bug. ***
*** Bug 119754 has been marked as a duplicate of this bug. ***