What about different names?

UIManager default

    chooseFileIn: aFileReference

    withExtensions: #()

    title: 'title'

    

 UIManager default

      chooseFileForSaveIn: aFileReference

      withExtensions: #()

      title: 'title'

We can just expect file references because it is what is exposed to users in pharo file system. Not neccessery to put it in method name.

пт, 26 окт. 2018 г., 16:32 Guillermo Polito <[hidden email]>:

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