Description: In the "Options" dialog → "LibreOffice" → "Paths", there appears to be no way to copy one of the listed paths to the clipboard. Possible fixes include: In the "Paths used by LibreOffice" listbox, and/or the "Edit Paths: ..." dialog: 1. Typing <ctrl>-C copies the selected path(s) to the clipboard. 2. Add a context menu that includes a "Copy to clipboard" choice. 3. Add a button that copies the selected path(s) to the clipboard. 4. In the "Edit Paths: ..." dialog, add an "Edit" button that would allow the user to edit the selected item (in a textbox). Steps to Reproduce: 1. In any LibreOffice application, select main menu → "Tools" → "Options". 2. In the tree view in the "Options" dialog, expand the "LibreOffice" item and select its child item "Paths". 3. In the "Paths used by LibreOffice" listbox, select an item. 4. Look for a UI element for copying to the clipboard. 5. If you don't find one (and you won't), press <ctrl> C. Actual Results: Nothing happens. Clipboard contents remain unchanged. Expected Results: The selected path(s) is/are copied to the clipboard. Reproducible: Always User Profile Reset: No Additional Info: Why I needed this: I wanted to create a new template. I didn't know the location in the file system where LibreOffice stores its templates, so I looked in the Options dialog. I found the location right away, but it's a long path (over 50 characters on Windows 10) that I cannot memorize long enough to close the Options dialog, invoke the Save As dialog, and type it there. So I wanted to copy it so I didn't have to memorize it – or even have to type it.
Let's ping the design team real quick on how this should work, right-click context menu, Ctrl-C...
Why do you need to copy the path? There is no way to paste it back within the program.
Unclear use case, resolving now.
(In reply to Heiko Tietze from comment #2) > Why do you need to copy the path? There is no way to paste it back within > the program. He could paste the path into the Name box in Save As... and then type the filename at the end, to put a new file in the right place without browsing through the folder structure. Being able to copy the path would also allow him to paste it into another program. For example, pasting it into a Windows File Explorer window so he could quickly get to that location and then do something else.
You don't need to enter the path in Save As since it is the current path because of this option. And I don't see much need to fiddle around with templates per file manager. Of course I can follow the ideas and it would be a nice-to-have thing. But unless we have a clear use case, ideally showing the need for many users, additional features just clutter the UI and generate coding effort.
>Why do you need to copy the path? There is no way to paste it back within the program. I want to paste it into a different program. If the paths were very short, or there were only a few of them, I might not have bothered reporting this as a bug, but the paths are long (around 60 characters each on my Windows system), and the dialog on my system currently shows 15 of them. That's a lot to have to type by hand, not to mention the risk of typos. (Actually, there *should* be a way to paste a path in; if I already have the path in my clipboard, I shouldn't have to retype it. But that would be a different issue.) > I don't see much need to fiddle around with templates per file manager. Not merely the file manager, but other programs. You may not have ever had such a need, but I have. > additional features just clutter the UI I don't see how supporting <ctrl>+C clutters the UI. Having it copy the path to the clipboard is fully consistent with long-established UI conventions. Right now, that key combination does nothing, so why not have it do something obvious and useful instead? This functionality actually belongs in the listbox control in the GUI library; it's a generic feature that's easily implemented.
Created attachment 172346 [details] Mockup I presume the fields are read-only and filled per file dialog to make sure the path exists. The current layout is sub-optimal for direct input since you can have multiple paths for one item (/foo; /bar). And it has a column for internal path, which is pointless to show IMO. I would propose to use a dynamic UI with normal input fields. We should check on enter and use weld::EntryMessageType::Error as feedback (the background becomes red) if the path not exists - and disable the okay button so the config dialog can not be closed.
Bug 92969 could be solved by adding another entry to the context menu.