On 10/3/17, tim Rowledge <tim at rowledge.org> wrote:
> 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?

Not at all. There seems to be some duplication of code and functions,
the dialogs do not follow the recent (Squeak 5.1) UI themes and for
example.

MVC projects look very nice these days and if we talk about
implementing different GUIs it will become important again.

UIManager subclass: #MVCUIManager
    has

chooseDirectory: label from: dir
	"Let the user choose a directory"
	^self notYetImplemented


chooseFileMatching: patterns label: labelString
	"Let the user choose a file matching the given patterns"
	^self notYetImplemented

So a ToolBuilder version would be fine covering both, Morphic and MVC.



> I can just substitute proper pattern matching as is already
> available in the filelist anyway.

Please go ahead!

>As an aside, the current visuals suggest
> to me that the suffix-matching version was originally an EToy thing - is
> that true?

I do not know. And it does not matter that much. A File chooser dialog
UI style should fit the rest of the UI.

> IT’s certainly radically different visually than the other
> filelist derived file/directory picking UIs.

Yes.

> 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?

Either one or the other.


Image save as ...
-------------------------
> 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?

I understand that improved file dialogs are helpful for an improved
'image save as...' mechanism.

--Hannes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Choosing_files_2017-10-03.png
Type: image/png
Size: 99031 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20171003/11d4c94b/attachment-0001.png>