https://forum.world.st/Streams-and-FileDialog-in-Pharo-6-and-7-tp5084352p5087782.html
Looks fine.
> On 26 Oct 2018, at 17:31, Guillermo Polito <
[hidden email]> wrote:
>
> Hi all,
>
> I've proposed a PR with some cleanups in this respect
>
>
https://github.com/pharo-project/pharo/pull/1941>
> This is the proposed replacement API that returns file references instead of streams or file names.
>
> "Get existing file reference"
> UIManager default
> chooseExistingFileReference: 'title'
> extensions: nil
> path: FileSystem workingDirectory.
>
> "Get existing file reference filtering by extensions"
> UIManager default
> chooseExistingFileReference: 'title'
> extensions: #('log')
> path: FileSystem workingDirectory.
>
> "Get existing file reference to file"
> UIManager default
> chooseExistingFileReference: 'title'
> extensions: nil
> path: FileSystem workingDirectory / 'PharoDebug.log'.
>
> "Get file reference for save (not necessarily existing)"
> UIManager default
> chooseForSaveFileReference: 'title'
> extensions: #('log')
> path: 'PharoDebuasdg.log'.
>
> On Fri, Oct 26, 2018 at 3:11 PM Guillermo Polito <
[hidden email]> wrote:
> Ok, so can we agree on deprecating the non compatible methods and redirect the user to the new ones?
>
> To me, the problem with returning a stream is that from a user perspective you don't know:
> - is the file encoded or binary
> - if it is encoded, in which encoding?
> - if i receive an open file stream, and I want to delete that file I have to close it, retrieve the file, delete it?
> - IMHO, what is the worst: whose responsibility is it to close the file?
>
> On Thu, Sep 6, 2018 at 10:43 PM Peter Uhnak <
[hidden email]> wrote:
> > It should return a FileReference, not an open stream. I believe there are methods that do that.
>
> There are different APIs for that.
>
> fileOpen*, as the name implies, _opens the file_ and returns the stream. (I think this should be the case for fileSave*)
>
> If you want file reference, then you can use e.g.
>
> UIManager default chooseFileMatching: #() label: nil
>
> or `chooseFileMatching:label:`, `chooseFileName:extensions:path:preview:`, `chooseFullFileName:extensions:path:preview:`, `chooseFullFileNameMatching:label:`.
> Also some methods for selecting directories (`chooseDirectory:path:`, chooseDirectory:from:`, ...)
>
> iirc some of them actually return String (file path) instead of FileReference. (
https://gist.github.com/peteruhnak/8ac6667b8eb11daee71517d0172b7355#file-ui-manager-md )
>
> So it can be confusing, but the API is already available.
>
> Also iirc UIManager should be preferred over UITheme builder.
>
> Peter
>
> On Thu, Sep 6, 2018 at 9:57 PM Sven Van Caekenberghe <
[hidden email]> wrote:
>
>
> > On 6 Sep 2018, at 21:37, Torsten Bergmann <
[hidden email]> wrote:
> >
> > Hi,
> >
> > A question to those who worked on the new streams for Pharo 7:
> >
> >
> > In PHARO 6 I used the following expression to open a file dialog and let the user choose
> > a binary file:
> >
> > s := UITheme builder fileOpen: 'Choose a file' extensions: #('exe').
> >
> > This returned
> > - either nil (when file dialog was canceled)
> > - a "MultiByteFileStream" instance when a file was selected
> >
> > The MultiByteFileStream instance already had the name of the file (= full path) and I was
> > able to query it for further use:
> >
> > s := UITheme builder fileOpen: 'Choose a file' extensions: #('exe').
> > s name inspect
> >
> > (for instance to display which file is processed in a window by showing the full path)
> >
> >
> >
> > Now in PHARO 7 same expression returns an instance of ZnCharacterReadStream (as MultiByteFileStream
> > is deprecated):
> >
> > s := UITheme builder fileOpen: 'Choose a file' extensions: #('exe').
> >
> > and ZnCharacterReadStream does not understand #name - and in fact the info about the name is
> > totally lost/not available. To me this looks missing/broken.
> >
> > So what is the recommended way in Pharo 7 to open a file dialog, let the use choose a file
> > and get a file stream but also the name? IMHO this is either broken or missing...
> >
> > Thanks
> > T.
>
> It should return a FileReference, not an open stream. I believe there are methods that do that.
>
> But that is an incompatible API change (same selector, different return type). So hard to decide.
>
>
>
>
> --
>
> Guille Polito
> Research Engineer
>
> Centre de Recherche en Informatique, Signal et Automatique de Lille
> CRIStAL - UMR 9189
> French National Center for Scientific Research -
http://www.cnrs.fr>
> Web:
http://guillep.github.io> Phone: +33 06 52 70 66 13
>
>
> --
>
> Guille Polito
> Research Engineer
>
> Centre de Recherche en Informatique, Signal et Automatique de Lille
> CRIStAL - UMR 9189
> French National Center for Scientific Research -
http://www.cnrs.fr>
> Web:
http://guillep.github.io> Phone: +33 06 52 70 66 13