пн, 29 окт. 2018 г. в 10:07, Guillermo Polito <[email protected]>:
> 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!) > 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. > > 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 >
