Created attachment 117487 [details] screenshot of the paths list this is an enhancement request. see attached screenshot I think it would be an handy feature to have a "left or right click thing" to open the selected folder into the file manager sometimes I want to inspect the content of those folders and it would be great to open them directly from LibO interface
Agreed, valid enhancement request. Best regards. JBF
just a polite ping about this old enhancement request I filed exactly 2 years ago. I think it would be nice to open user profile subfolders in your file manager just selecting them and right-clicking on their path in the menu "Tools/Options/LibreOffice/Paths" actually you can only edit the path location with "left double click" or with the "Edit..." button. I'd like to have a "single right-click" action or an "Open" button to access to the each of the subfolder I select. actually if you wanna access to the content of some of the subfolder (i.e. AutoCorrect) you have to read the path and then manually reach that folder in your file manager... kinda annoying. a direct way to access it (with mouse action or button) would be a time-saver. @Jay & Heiko is this something that the UX-team would like to implement?
Created attachment 134792 [details] Mockup for a streamlined version Double-click works as expected and opens the path for tmp, downloads, images, classification (different dialog), backup. But not the other, likely because you can have multiple entries there. (WFM to this point) In this case the best solution is to provide the same behavior in the edit dialog meaning double-click on one of the radio buttons opens the file manager. That's the simple solution and could be an easyhack. But actually I would prefer a more consistent interaction. Double-click is normally the default interaction, and that's Edit here. With a context menu we could give access to the file manager. You can copy the selected path via ctrl+C or context menu in the edit dialog (only there because of the multiple paths); users may expect to paste and edit but I'd keep the dialog clean and list Edit only with in the context menu. Another non-standard behavior is the use of radio button to select the default path. My suggestion is to use the sequence for prioritization, with up/down buttons to sort the items. (In reply to tommy27 from comment #2) > just a polite ping about this old enhancement request I filed exactly 2 > years ago. Sorry for the delay. > is this something that the UX-team would like to implement? The UX folks do not implement. But your request is valid, removing needsUX.
*** Bug 97722 has been marked as a duplicate of this bug. ***
(In reply to tommy27 from comment #2) > I'd like to have a "single right-click" action or an "Open" button to access > to the each of the subfolder I select. Right-click isnt easily discoverable and not a11y/accessible, so i'd be against that, but having a 'Open' button next to the 'Default' and 'Edit' buttons, as well as next to the 'Add' and 'Delete' buttons in the edit paths dialog would be good in my book.
an "open" button would be even better than my original request
Hi, I want to work on this enhancement. adding 'needsDevEval' to know if it is a easy hack or not, and for code pointers.
The UI is defined in core/cui/uiconfig/ui/optpathspage.ui with code in cui/source/options/optpath.cxx with onclick handler IMPL_LINK_NOARG(SvxPathTabPage, PathHdl_Impl, Button*, void). Adding rarely used buttons impairs usability. We should expose only the primary functions to the user and keep the secondary hidden. That's why my suggestion was a context menu. And when the edit dialog is being touched it could get a redesign according comment 3.
(In reply to Heiko Tietze from comment #8) > Adding rarely used buttons impairs usability. We should expose only the > primary functions to the user and keep the secondary hidden. That's why my > suggestion was a context menu. And when the edit dialog is being touched it > could get a redesign according comment 3. I would consider the opening of a location of a path, where users would want to add or remove files from, as a primary function of a path and we have more than enough white space beside the current buttons for it rather than hiding it away behind a less accessible and discoverable context menu. @Stuart, @Cor, @Adolfo: thoughts?
(In reply to Yousuf Philips (jay) from comment #9) > I would consider the opening of a location of a path, where users would want > to add or remove files from, as a primary function of a path and we have > more than enough white space beside the current buttons for it rather than > hiding it away behind a less accessible and discoverable context menu. Reading the give reason for this function (I would not have thought about it myself...) : (In reply to tommy27 from comment #0) > sometimes I want to inspect the content of those folders and it would be > great to open them directly from LibO interface I would say it is really not that important to add a button.
@Cor you know... some enhancement are useful for some users and useless for others... it will always be like that. the original request was about a "right" or "left" click thing to access directly those folders instead of browsing the file manager, which may be cumbersome due to the "depth" of those subfolders which are often buried into some AppData Windows subfolders. somebody argued that an "open" button would be a better choice... anyway, I'd be happy with the "right or left click thing" as well
Heiko's comment #3 describing the UI is seems the final call(and better) on this...(?)
(In reply to Manuj Vashist from comment #12) > Heiko's comment #3 describing the UI is seems the final call(and better) on > this...(?) If stuart or adolfo agree with Heiko's proposal that right-click is better, then we'll go with that, else a final decision would need to be taken at a design meeting.
(In reply to Manuj Vashist from comment #12) Talked to Jay and we disagree on the importance of this function. While he thinks the button is needed to show the user what's possible I believe the dialog (and all UI in general) benefit from simplicity. The dialog is not meant to open the user space but rather to modify the path (edit). And I guess we do not want the user to mess with the managed files. That's why I prefer it to be hidden - and I could live with hiding Edit too. So how to proceed? Decide yourself, it's open source and the doer decides. UX gave input and whether it's done by a button or via context menu the advantage is there. But check the proposal carefully as it goes a bit beyond just adding one function. Ticket is still assigned to you, Manuj.
@Manuj, Heiko, * Fully implementing design of comment 3 looks correct. Please be mindful (i.e. run through the resulting UI) with keyboard navigation only. Keep the sequencing of the controls in order as this impacts a11y usability a lot.
Dear Manuj Vashist, This bug has been in ASSIGNED status for more than 3 months without any activity. Resetting it to NEW. Please assigned it back to yourself if you're still working on this.