Folders are just a bunch of files with a label. So why not handle these as such?

Registered by Bengt Lüers

The context-menu for folders could be more specific to enable more functionality. Basically items in the folder are pooled by "meta-filetypes" such as "image", "audio" and "video".

Blueprint information

Status:
Not started
Approver:
None
Priority:
Undefined
Drafter:
None
Direction:
Needs approval
Assignee:
None
Definition:
New
Series goal:
None
Implementation:
Unknown
Milestone target:
None

Related branches

Sprints

Whiteboard

For _files_ there is the "open with"-entry in the context-menu to chose a program for opening it with. That even works with multiple files, already. For _folders_ is applying this method does result in the problem, that the opened program might not be able to handle all of the given files. This is because of the simple fact that individual programs can only handle _some_ filetypes, but folders may contain files of _any_ filetypes.

So there are basically two possibilities to cope with that:
1. Currently, every program handles failures it self. For exception, VLC prompts the user that the file is not playable, when trying to play it.
2. The other way would be to let the user specify what he wants to be opened. By filetype for instance. Lets see where that gets us.

If for example there are 51 of GIMPs .xcf-sources and 140 .png images in a folder, likely the images are to be shown in EOG or something. In case, the user wants to open some of the sourcefiles, that will take a while anyway and the few klicks to enter the folder and select the wanted files are an adequate effort.

If that was all, it would lead to something like such an context-menu:
...................................................
____________................................
| xxxxxxxxxx |___________..............
| open with ---> EOG xxx |............
| xxxxxxxxxx | x Picasa xx|.............
| xxxxxxxxxx | x Gwen xxx|.............
| xxxxxxxxxx | x other... x |.............
| xxxxxxxxxx |___________|...............
|___________|...................................
........................................................
But this would also need some intelligent behaviour of the menu, to decide, which files to open. If you want to enqueue and play files of an audiobook into your audio-player, that operation will take some hours though initiating and aborting will take very shortly. Because of the second action making the user's experience, it should be preferred instead of showing the .info or re-downloading the corresponding .torrent. You see, size is not only a good indication for complexity or importance of an action. In an other case, speeding things up might be good simple but routine tasks and complex but infrequent tasks alike.

Giving this complexity back to the user could be solved by giving all options:
............................................................................
______________________......................................
| xxxxxxxxxxxxxxxxxxxx |__________.................
| open 140 .PNGs with ---> EOG xxx|..................
| open x51 .XCFs with xx| xx Picasa x|............
| xxxxxxxxxxxxxxxxxxxx | xx Gwen x |.............
| xxxxxxxxxxxxxxxxxxxx | xx other... |...................
| xxxxxxxxxxxxxxxxxxxx | _________ |................
|_____________________|................................
.................................................................
Cleaned up it would need another sub-menu:
............................................................................................
__________............................................................................
| xxxxxxxx |___________________________________............
| contents --> 140 .PNGs --> open with EOG xxx |.........
| xxxxxxxx | xxx 51 .XCFs x | xx open with Gwen xx |........
| xxxxxxxx | xxx 25 .JPGs x | xx open with Picasa xx |...........
| xxxxxxxx | _____________ | xx other... xxxxxxxxxx | ............
| xxxxxxxx | ....................... |_____________________|...........
|_________|..........................................................................
..............................................................................................
Here we are, making the decision based on the filetype does not allow us to open the JPGs and the PNGs at once. We will have to open them twice or navigate down to the folder and select them by hand.

== Solution ==

What I want to suggest here is to strike a balance between to much complexity for the program and to much complexity for the user. The context-menu could pool some filetypes. (An image viewer like supports JPG, PNG, SVG and so on, audioplayers will usually support all installed codecs)
..................................................................................................
__________ ................................................................................
| xxxxxxxx |________________________________________ ...........
| contents --> 165 images xxxxx --> open with EOG xx | ............
| xxxxxxxx | xxx 51 GIMP-sources | xx open with Picasa x| ........
| xxxxxxxx |___________________ | xx open with Gwen xx| .........
| xxxxxxxx | ................................. | xx other... xxxxxxxxx | ........
| xxxxxxxx | ................................. |____________________| .........
|_________| .................................................................................
....................................................................................................
Folders are just a bunch of files. Can't it be simple as that? :)

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.