I'd suggest cleaning this up and then taking a look at the mess that is the FileList hierarchy. At the very least we should consider getting rid of FileChooser (replaced by the FileAbstractSelectionDialog hierarchy) and FileList2 (which doesn't appear to be used and indeed seems to have been usurped by improvements to FileList) and - although it might take some fiddly stuff - PluggableFileList.
> On 2019-08-22, at 7:30 AM, <
[hidden email]> <
[hidden email]> wrote:
>
> Hi everyone,
>
> while cleaning up something else, I discovered that we have the file reader registration infrastructure in two places: FileServices which is the actual implementation, and on the FileList tool. The FileList implementation only forwards calls to FileServices which makes sense for compatibility reasons but at the same time clutters the interface. I would like to deprecate these methods except if someone knows a good reason (e.g. a project) which heavily relies on this (refactoring code to use FileServices just requires changing the class name, the major calls are still the same).
>
> Bests
> Patrick
>
>
tim
--
tim Rowledge;
[hidden email];
http://www.rowledge.org/timNever trust a computer you can't lift.
Locked
