Whilst tinkering around I stumbled across UIManager>chooseFileMatching: etc and was surprised to find that it gets implemented with a filelist derived ui that matches only on file suffixes instead of the patterns that the API specifically calls out.

I can’t find much in the way of usage of the root call in the image nor with some googling, so I doubt it will cause any problem if I fix the problem; any objections? I can just substitute proper pattern matching as is already available in the filelist anyway. As an aside, the current visuals suggest to me that the suffix-matching version was originally an EToy thing - is that true? IT’s certainly radically different visually than the other filelist derived file/directory picking UIs.

Also, there’s actually a class called FileChooser, which seems to be likewise unused and unloved. Should we unlove it enough to delete it? Or improve it to do proper theme stuff etc?

What I want to achieve is an improved UI for the image save as… so it is easier to save your image to a different directory. I want a simple dialog that looks like a plain fillintheblank except for a ‘more’ button that would add a directory chooser view. Of course, that will then require some change to the finding of the .sources, at least wrt the allinone package since the sources are kept with the image, ie deep in the package/Contents/Resources directory. Saving the default new image to a user location instead of the allinone would currently require copying the sources as well as the changes, not really the right thing. Once upon a time the normal place for the sources was gather with the vm but perhaps the requirements of the apple bundle stopped that?

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Strange OpCodes: RLBM: Ruin Logic Board Multiple