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. |
> 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. |
>
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:
|
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:
|
> On 26 Oct 2018, at 15:11, 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? Well said, agreed on all points. Using a FileReference is soo much better. > 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 |
In reply to this post by Guillermo Polito
Hi all, I've proposed a PR with some cleanups in this respect 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:
|
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 |
In reply to this post by Guillermo Polito
go go go! FileReference! On Fri, Oct 26, 2018 at 3:12 PM Guillermo Polito <[hidden email]> wrote:
|
In reply to this post by Guillermo Polito
What about different names? UIManager default chooseFileIn: aFileReference withExtensions: #() title: 'title' 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]>:
|
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 <[hidden email]> wrote:
|
пн, 29 окт. 2018 г. в 10:07, Guillermo Polito <[hidden email]>:
Ok. For current situation it is probably the right thing to do. And monstrous names are easy to rename/deprecate in future. But I don't think that in clean system (without old API) using just a File in such names needs special explanation. Because we postulate that only file references are exposed to users. User chooses a file and Pharo gives him a reference to this file.
|
Free forum by Nabble | Edit this page |