Created attachment 98354 [details] Consistent “FilePicker” and “FolderPicker” Behavior Currently the “FilePicker” and “FolderPicker” dialog(s) behave inconsistently across platforms (Linux and Windows), and across different use cases. Consistency of dialog behavior would enhance the user experience and simplify deployment for all programs based on the dialog components. A summary of the “FilePicker” behavior and the desired behavior is provided in the tables of the attached document. The “FolderPicker” behavior should mirror the “FilePicker” behavior to the extent practical. The attached writer document provides a more detailed discussion of the desired behavior and how that compares with the current release across environments (Linux, Windows) and dialog styles (LibreOffice, System). It also contains supporting Macro code to enumerate use cases and test current release version behavior across environments.
Created attachment 98416 [details] Consistent "FilePicker" and "FolderPicker" behavior
Comment on attachment 98416 [details] Consistent "FilePicker" and "FolderPicker" behavior Prior upload of this document incorrectly assigned it to type text, so here it is with the corrected MIME type.
Please provide much simpler explanation. While we appreciate the extensive documentation - we have hundreds and hundreds of bugs to go through and having to read 4 pages of explanation is just too time consuming. Please just write a simple set of instructions (on the bug report itself) and attach the simplest test case you possibly can. Also, is this a regression or a new problem? Marking as NEEDINFO - once you provide much simpler steps and a much simpler test case, mark the bug as UNCONFIRMED and we'll try to confirm. Thanks for understanding - we truly to appreciate the effort you put into your explanation, just our volunteer teams are stretched much to thin to dedicate that much time to just reading about a single bug. In this case - I think you just have much too much information. I would recommend possibly taking this to the UX team and sorting it out with them.
(In reply to comment #3) As requested, here is a much simpler example. Problem description: ==================== Currently there is no overall consistency for FilePicker and FolderPicker behavior on LibreOffice. It varies by error conditions, operating system, and configuration choices. A valuable enhancement would be to change the behavior so that the operation is consistent to the extent possible. The following steps show a single example of this in a Linux environment. It would also be helpful if the setDisplayDirectory() call could return an error when it encounters directories that are not accessible or other errors. In this way the program could take appropriate action in the face of errors. How to reproduce the problem: ============================= 1. In LibreOffice, open Tools --> Options; in the LibreOffice – General tab ensure that “Use LibreOffice dialogs” is unchecked. 2. In LibreOffice, open Tools --> Macros --> Organize Macros --> pick any module to edit 3. Type (or cut/paste) the following program in to the empty “Sub” of your choice (Main will do): Dim oDialog 'FilePicker dialog oDialog = CreateUnoService("com.sun.star.ui.dialogs.FilePicker") Print "setDisplayDirectory --> /tmp/NoSuchFile" 'File/Directory does not exist oDialog.setDisplayDirectory(ConvertToURL("/tmp/NoSuchFile")) oDialog.Execute() Print "setDisplayDirectory --> /home/lost+found" 'Directory exists but is protected oDialog.setDisplayDirectory(ConvertToURL("/home/lost+found")) oDialog.Execute() 4. Run this Macro to see the behavior with the System dialog styles. 5. In LibreOffice, open Tools --> Options; in the LibreOffice – General tab ensure that “Use LibreOffice dialogs” is checked 6. Run the Macro again to see the behavior with the LibreOffice dialog styles. Current behavior: ================= -- Using System dialogs, “/tmp/NoSuchFile” generates no error and then leaves the user in “/tmp” -- Using System dialogs, “/home/lost+found” generates no error and then leaves the user in “/home/lost+found”, even though the contents of this directory are completely protected (no rwx access). -- Using LibreOffice dialogs, “/tmp/NoSuchFile” generates a user error and then leaves the user in “/home/<user-account>/Documents”. -- Using LibreOffice dialog, “/home/lost+found” generates a specific user error and then leaves the user in “/home/<user-account>/Documents”. Desired behavior: ===================== As can be seen with this simple test case, the behavior across all 4 examples is very different. To the extent possible and practical, all behavior should have consistent across OS supported (Linux, Windows, MacOS), choice of dialog (System, LibreOffice), and error conditions (e.g. protected and missing directories). For example, all behavior could follow the LibreOffice dialog models. ---------------------------------------- Hopefully this provides the simpler example that you were looking for. Did you mean "User Experience" team when you made reference to "UX"? I will defer to your judgement on where to best deal with this enhancement request. In researching how to provide feedback, enhancement requests, and bugs I did not run across any way to contact the UX team. I would follow up if you point me in the right direction. The case for developers to look at this now is that I believe that there is activity on what could be a related bug (43021), so a partial step towards consistency would still be a good thing. I have updated the document to streamline things a bit and put the simple Bugzilla examples at the front, with further analysis and screen shots towards the back for those that need it. I will upload this new version. This could provide a good starting point for the UX team as it considers the broader implementation of this enhancement (should they take up the request). I will also update 78209 along the lines of your request as well. Let me know if this format is better suited to your process.
Created attachment 99450 [details] Consistent “FilePicker” and “FolderPicker” Behavior (updated) This version streamlines things a bit, put sthe simple Bugzilla examples at the front, with further analysis and screen shots towards the back.
Thanks Ewald, a useful enhancement and clear documentation !
(wondering if component Framework would be a better one for this...)