Well, there are still variants
 - chooseFile*
 - fileOpen*
 - fileSave*
 - chooseFileName*
 - chooseFullFileName*

I prefered rather to be explicit and to avoid confusion with the old API
(which I deprecated, not removed!)

On Sat, Oct 27, 2018 at 2:42 PM Denis Kudriashov <[email protected]>
wrote:

> 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 <[email protected]>:
>
>> 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 <
>> [email protected]> 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 <[email protected]> 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 <[email protected]>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> > On 6 Sep 2018, at 21:37, Torsten Bergmann <[email protected]> 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
>>> <http://www.cnrs.fr>*
>>>
>>>
>>> *Web:* *http://guillep.github.io* <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
>> <http://www.cnrs.fr>*
>>
>>
>> *Web:* *http://guillep.github.io* <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
<http://www.cnrs.fr>*


*Web:* *http://guillep.github.io* <http://guillep.github.io>

*Phone: *+33 06 52 70 66 13

Reply via email to