Add a "Select {current folder}" button to filepanels

[humdinger]

This is hrev4902.

Expander has a custom file panel with a button "Select {current folder}":

This saves you from having to navgate to a folders parent, just to select that folder.

Is is possible to backwards-compatibly have this button for every BFilePanel that has the node_flavor B_DIRECTORY_NODE?

[humdinger]

Expander's file panel sporting a "Select {this folder}".

[humdinger]

Is this in the scope of a GCI task?

[Giova84]

Any news about this ticket? Could be easily implemented? That would be definitely an useful enhancement! :-)

[pulkomandy]

Unfortunately, not the easy way. Some applications (for example Expander) customize the filepanel to add such a button. If we put one there by default, such apps would then have two buttons. Maybe we can have a separate flag or method to enable this button instead, so existing apps aren't affected. But then we need to update all apps to make use of the feature, which isn't so great.

[humdinger]

As I read owenca's ​Filer issue #20: How about not adding another button, but just keeping the file panel's "Open" button active if there's no folder selected? Pressing open would then choose the current folder. Not completely obvious, but still better than the hoops we have to jump at the moment: Going up to the parent folder to choose our folder.

Oh, oh, how about re-labeling the "Open" button to "Open current folder" if no folder is selected, "Open {folder name}" if one folder is selected and "Open {number of selected folders} folders" if more than one folder is selected.

[axeld]

That wouldn't really solve the issue of applications customizing the panel, though. We really have only two choices here AFAICT:

1. Add a flag that adds the button or changes how "open" works (I haven't made up my mind about that yet, although I often wondered why "open" would just open the folder, and not close the panel).
2. Detect R5 software, and let them suffer, and document Haiku's different behavior (and fixing all apps in tree).

Both solutions won't provide a consistent user experience, though, although 2.) is slightly better in this regard, as the problem will fade away with time :-)