Bug 119133 - QT5 integration Save As or PDF Export dialog has and empty file name and always home directory
Summary: QT5 integration Save As or PDF Export dialog has and empty file name and alwa...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
6.1.0.2 rc
Hardware: All Linux (All)
: medium normal
Assignee: Katarina Behrens (CIB)
URL:
Whiteboard: target:6.2.0 target:6.1.1
Keywords:
: 119422 119450 119754 (view as bug list)
Depends on:
Blocks: PDF-Export-File-Dialog
  Show dependency treegraph
 
Reported: 2018-08-06 20:28 UTC by Marco Menardi
Modified: 2018-09-18 13:30 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marco Menardi 2018-08-06 20:28:22 UTC
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
Comment 1 Katarina Behrens (CIB) 2018-08-10 09:18:09 UTC
Yep
Comment 2 Commit Notification 2018-08-12 20:29:55 UTC
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.
Comment 3 Michael Weghorn 2018-08-13 08:44:59 UTC
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'.
Comment 4 Katarina Behrens (CIB) 2018-08-13 12:03:14 UTC
> 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?
Comment 5 Michael Weghorn 2018-08-13 12:46:53 UTC
(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?
Comment 6 Michael Weghorn 2018-08-13 12:59:00 UTC
(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...
Comment 7 Katarina Behrens (CIB) 2018-08-13 15:28:35 UTC
> 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
Comment 8 Michael Weghorn 2018-08-13 15:41:11 UTC
(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!
Comment 9 Commit Notification 2018-08-13 23:29:14 UTC
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.
Comment 10 Maxim Monastirsky 2018-08-23 22:45:34 UTC
*** Bug 119450 has been marked as a duplicate of this bug. ***
Comment 11 Maxim Monastirsky 2018-08-30 13:36:22 UTC
*** Bug 119422 has been marked as a duplicate of this bug. ***
Comment 12 Xisco Faulí 2018-09-13 10:56:25 UTC
*** Bug 119754 has been marked as a duplicate of this bug. ***