Bug Hunting Session
Bug 92969 - UI: right-click in "Options/Paths" to open folder in file manager
Summary: UI: right-click in "Options/Paths" to open folder in file manager
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: Other All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: needsDevEval
: 97722 (view as bug list)
Depends on:
Blocks: Options-Dialog-Paths
  Show dependency treegraph
 
Reported: 2015-07-28 05:34 UTC by tommy27
Modified: 2018-05-29 09:17 UTC (History)
11 users (show)

See Also:
Crash report or crash signature:


Attachments
screenshot of the paths list (22.05 KB, image/png)
2015-07-28 05:34 UTC, tommy27
Details
Mockup for a streamlined version (77.20 KB, image/png)
2017-07-23 08:11 UTC, Heiko Tietze
Details

Note You need to log in before you can comment on or make changes to this bug.
Description tommy27 2015-07-28 05:34:38 UTC
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
Comment 1 Jean-Baptiste Faure 2015-07-31 15:39:16 UTC
Agreed, valid enhancement request.

Best regards. JBF
Comment 2 tommy27 2017-07-23 07:20:49 UTC
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?
Comment 3 Heiko Tietze 2017-07-23 08:11:22 UTC
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.
Comment 4 Yousuf Philips (jay) (retired) 2017-07-24 15:27:57 UTC
*** Bug 97722 has been marked as a duplicate of this bug. ***
Comment 5 Yousuf Philips (jay) (retired) 2017-07-24 16:25:20 UTC
(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.
Comment 6 tommy27 2018-01-09 05:21:31 UTC
an "open" button would be even better than my original request
Comment 7 Manuj Vashist 2018-01-15 16:32:04 UTC
Hi, I want to work on this enhancement.
adding 'needsDevEval' to know if it is a easy hack or not,
and for code pointers.
Comment 8 Heiko Tietze 2018-01-16 08:29:45 UTC
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.
Comment 9 Yousuf Philips (jay) (retired) 2018-01-16 19:09:12 UTC
(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?
Comment 10 Cor Nouws 2018-01-17 15:45:01 UTC
(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.
Comment 11 tommy27 2018-01-17 15:59:29 UTC
@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
Comment 12 Manuj Vashist 2018-01-20 02:50:57 UTC
Heiko's comment #3 describing the UI is seems the final call(and better) on this...(?)
Comment 13 Yousuf Philips (jay) (retired) 2018-01-20 13:53:50 UTC
(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.
Comment 14 Heiko Tietze 2018-02-16 10:58:49 UTC
(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.
Comment 15 V Stuart Foote 2018-02-16 18:54:20 UTC
@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.
Comment 16 Xisco Faulí 2018-05-29 09:17:30 UTC
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.