Looks fine.
On 26 Oct 2018, at 17:31, Guillermo Polito <guillermopolito@gmail.com> 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 <guillermopolito@gmail.com> 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 <i.uhnak@gmail.com> 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-... )
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 <sven@stfx.eu> wrote:
On 6 Sep 2018, at 21:37, Torsten Bergmann <astares@gmx.de> 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