#86 enhance "file selection" pane

[theliquidmetal]

1. "file selection" pane is to simple, there is only 3 colums avalilable: size, type, and date modified. It would be great if users can customize with any other tags, whether it is standard or custom.
2. still in "file selection" pane, it would be great if it supports drag and drop with other apps.

[Urs Fleisch]

Concerning the 2nd point: Dropping into the Kid3 window is supported for tagged files and pictures. Dragging files from the file list to another application is not (yet) supported. What use cases do you see for such drag operations?

[theliquidmetal]

I used to view/edit files. Without dragging feature, i have to copy the filename, back to the explorer, search that file, than open that file with my prefered app. Note: i have plentiful file with cryptic name, grouped a few dozen in aech folder. Sometimes, it is hard or does not make sense to name a bunch of files with semantic rules when it is related to research data.

[theliquidmetal]

For the 1st point, such as my case, user can't always rely on filename. Thats why the column flexibility in "file selection" pane is very useful. User can display whatever metadata which is useful for themselves.

[Joe]

I agree. Lets say I have a folder with a few hundred files, and I only want to work on tracks from one particular album or artist. It would be much easier if I could sort on other fields.

[Urs Fleisch]

I agree that such an addition would be helpful. Let me explain why it is nevertheless still not implemented. The contents of the file list are provided by a QFileSystemModel, a beast of an item model in the Qt framework which seems to be tailored to the needs of its file dialog, but not really for extension by other use cases. It was source of quite a few memory and performance headaches in the past. I had to reach for some quite nasty workarounds like resetting the whole model when its reponsiveness came to a crawl when filtering or selecting a huge number of files. This was caused by some shortcomings happening with proxy models stacked on top of it. I am mentioning all this because the implementation for this feature would involve adding to such a proxy model because the QFileSystemModel itself does not offer a means to add additional columns. Adding such columns would follow the principles used in KExtraColumnsProxyModel, but this model has one important drawback:

Not supported: adding/removing extra columns at runtime;

Not being able to add/remove columns at runtime would not make such a feature look very professional. And what hinders me more is the fact that such an implemenation would impact the performance also for users which do not use additional columns. Therefore, as long as I do not find the time to replace the whole QFileSystemModel with something better or implement a proxymodel without the shortcomings of KExtraColumnsProxyModel, I'll have to postpone this feature.

[Joe]

I wish I understood what you just said. Anyway great work. Love the program :)