https://bz.apache.org/ooo/show_bug.cgi?id=96720

[email protected] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ACCEPTED                    |CONFIRMED
                 CC|                            |[email protected]
             Latest|---                         |4.2.0-dev
    Confirmation in|                            |

--- Comment #11 from [email protected] ---
There is many issues here.

1. "Under Ubuntu ONLY setDefaultName() does not work with FILEOPEN_SIMPLE".

Yes, this is **by design**. GTK can't support
gtk_file_chooser_default_set_current_name() for opening files, it gives the
following assertion:

(soffice:81466): Gtk-CRITICAL **: gtk_file_chooser_default_set_current_name:
assertion 'impl->action == GTK_FILE_CHOOSER_ACTION_SAVE || impl->action ==
GTK_FILE_CHOOSER_ACTION_CREATE_FOLDER' failed

which is why AOO doesn't even try to call
gtk_file_chooser_default_set_current_name() when the OPEN dialog is shown (see
SalGtkFilePicker::setDefaultName). The suggested filename can only be used when
saving. Blame GTK.

2. The code from the OP is just plain wrong: the current directory needs to be
given as a URL. The documentation for XFilePicker requires a URL for
setDisplayDirectory(). "/home" is not a URL. It should be "file:///home"

3. com.sun.star.ui.dialogs.Win32FilePicker allows paths instead of URLs (both
C:/ and file:///C:/ work, file:/C:/ doesn't), but other platforms are
stricter!!!

4. For com.sun.star.ui.dialogs.FilePicker, when the directory isn't a URL, the
default filename isn't shown either. I feel that when the directory is wrong it
shouldn't affect the file; not only is there no good reason for it to, but it
can also confuse users as to what is wrong, like the OP here who believed both
the file and directory are broken.

-- 
You are receiving this mail because:
You are on the CC list for the issue.
You are the assignee for the issue.

Reply via email to