We need to extend GtkFileChooserAction to support this.  Want to
propose a patch to add GTK_FILE_CHOOSER_ACTION_SELECT_FILES_AND_FOLDERS?

There is no need to add a "save" version of this, as multiple
selection does not make sense in a save-type mode.

Created attachment 25247 [details] [review]
proposed patch

Retitling for clarity.  Thanks for the patch; this will most likely go
in for 2.6.

GTK 2.6 or GNOME 2.6 ?

Can we have this reviewed?

regs,
 Chris

I don't think you'll ever get reasonable behavior for such a hybrid
selection ... the user doesn't have a clear view of what will happen

 - When they double click on a folder
 - When they select a folder and click [Open] / [Import]
 - If they deselect all files and click [Open] / [Import]

File-or-folder works well if you are dragging files in a file manager,
or right clicking on files in a file manager because it's very clear
what the action is, and what the object is. I don't think that will be
the case here.

I would suggest a more flexible rethinking of what
the UI should be for rythmbox is needed. Similar things come up for photos,
evolutions mail import dialog. It's not a one-off. But I think it
has to be much more obvious what is going to happen than what is
proposed here.

Imo, a logical behaviour would be:

 - When they double click on a folder 
      => browse the folder in the file choser
 - When they select a folder and click [Open] / [Import]
      => import the folder
 - If they deselect all files and click [Open] / [Import]
      => import is grayed out and nothing can be done

I think what is a bit more difficult is getting a consistent and convenient
behaviour with keynav, especially when pressing enter.

This bug is also the cause of http://bugzilla.gnome.org/show_bug.cgi?id=149356

In file-roller => create archive,  the user will want to use the fileselector to
add files AND directories at the same time, to be put into the archive.

(In reply to comment #7)
> Imo, a logical behaviour would be:
> 
>  - When they double click on a folder 
>       => browse the folder in the file choser
>  - When they select a folder and click [Open] / [Import]
>       => import the folder
>  - If they deselect all files and click [Open] / [Import]
>       => import is grayed out and nothing can be done
> 
> I think what is a bit more difficult is getting a consistent and convenient
> behaviour with keynav, especially when pressing enter.

It's not only a logical behaviour, it's also the default behaviour of GTK_FILE_CHOOSER_ACTION_SELECT_FOLDER (double-click: navigate, click Open: emit response signal). Owen Taylor's argument therefore does not stand.

People who are tired of waiting on the GTK+ developers tergiversations can have a look at mn_file_chooser_dialog_allow_select_folder() in Mail Notification (http://www.nongnu.org/mailnotify/). It implements the behaviour described above in just a few lines of code.

Let's resurrect this.  Christophe, would you be willing to redo your patch for GTK+ trunk or 2.12.x?

*** Bug 549515 has been marked as a duplicate of this bug. ***

Created attachment 139501 [details] [review]
Patch adding SELECT_FILES_AND_FOLDERS action

Here is a patch against current git adding such action.

I have only tested it in browse mode:
- selecting files or folders and clicking on open button returns them
- double clicking a file returns it
- selecting a file and pressing enter returns it
- double clicking folder enters it
- selecting a folder and pressing enter enters it
- clicking on open button when nothing is selected returns current directory

Hi,

The last behaviour (#6), "clicking on open button when nothing is selected
returns current directory", often confuses me when I deal with "directory
selection" dialogs. It makes the whole __selection__ idea inconsistent.

Here is an example:
- The user gets used to the behaviour of #6. So, she always looks at the
  breadcrumbs to identify the directory that will be used.
- Then, she may accidentally "select" a directory and she is surprised
  that the operation took place in a child directory. Not really what she
  intended.

I guess, the reason for behaviour #6 is some legacy from the past and
a supposed (but questionable) "usability enhancement".

I think it is quite confusing that the current directory
is automatically selected when actually "__nothing__ is selected explicitly"
by the user.

So, I second Christophe Fergeau's suggestion:

"If they deselect all files and click [Open] / [Import]
       => import is grayed out and nothing can be done"

Well I am not sure about it, but I think it's important to be consistent with directory selection mode.

I think the case where it is useful is when you double click on a folder and enter it, without this behaviour you would need to go up before validating.

And also without this behavior I don't know how single click mode would be possible to implement.

And I don't think that it's so confusing, if people select the action and not cancel, they expect something to be done.

Hi,
just to add what a non-technical user expects:

a) return path of whatever is selected (file or folder) when hitting ok
b) return current dir if nothing is selected when hitting ok
c) return invalid path when hitting Cancel or closing the window
d) single click selects files or folders
e) multi selection if available returns list of paths of files and folders
f) double click (or enter if already selected) enters folders 

This is what I as user would expect as behaviour and I suppose that this is 
what the use of different operative systems has taught me to be some kind
of default sane behaviour.

(In reply to comment #15)
> Hi,
> just to add what a non-technical user expects:
> 
> a) return path of whatever is selected (file or folder) when hitting ok
> b) return current dir if nothing is selected when hitting ok
> c) return invalid path when hitting Cancel or closing the window
> d) single click selects files or folders
> e) multi selection if available returns list of paths of files and folders
> f) double click (or enter if already selected) enters folders 

That is what happens

Ping
Can someone have a look at it before it needs to much work to update ? :)

One year later, should I check/update the patch for latest git or lose hope to get it reviewed ?

We are like Ents here; we do things slowly ;)

Sorry for the delay.  Yes, could you please check if the patch is still current?