The new File list is nice, but it still has a problem
with the selection in the tree after typing. On win32 if one types C:\temp and hits ENTER the folder is not selected in the tree. If one enters C:\temp\ and ENTER it is selected. I think both options should be possible (since this is similar behavior as in Windows Explorer, and yes I'm biased). The reason is that anything after the "pathNameDelimiter" is always identified as pattern. See implementation in FileList>>pathAndPattern: One possible solution could to check first if a subdirectory with the extracted pattern exists "(FileDirectory on: base) fileOrDirectoryExists: pat" and react accordingly (ignore it as pattern and add it to the base). What do others think. Bye T. -- Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 |
> What do others think.
Two thoughts: First, I would only consider the last portion a pattern if it includes a wild card (there is little point in having a wild card that matches at most one file I think). Secondly, I would walk the tree and select the directory "closest to" the chosen input. Meaning that if there's a typo you end up as close as we can make it to the chosen location. Cheers, - Andreas Torsten Bergmann wrote: > The new File list is nice, but it still has a problem > with the selection in the tree after typing. > > On win32 if one types C:\temp and hits ENTER the folder > is not selected in the tree. > > If one enters C:\temp\ and ENTER it is selected. I think > both options should be possible (since this is similar > behavior as in Windows Explorer, and yes I'm biased). > > The reason is that anything after the "pathNameDelimiter" > is always identified as pattern. > See implementation in FileList>>pathAndPattern: > > One possible solution could to check first if a subdirectory > with the extracted pattern exists > "(FileDirectory on: base) fileOrDirectoryExists: pat" > and react accordingly (ignore it as pattern and add it to the > base). > > What do others think. > > Bye > T. |
On 07.10.2009, at 17:41, Andreas Raab wrote: > > What do others think. > > Two thoughts: First, I would only consider the last portion a > pattern if it includes a wild card (there is little point in having > a wild card that matches at most one file I think). IMHO if there is neither a directory given nor a wild card, a substring search should be performed. - Bert - > Secondly, I would walk the tree and select the directory "closest > to" the chosen input. Meaning that if there's a typo you end up as > close as we can make it to the chosen location. > > Cheers, > - Andreas > > Torsten Bergmann wrote: >> The new File list is nice, but it still has a problem >> with the selection in the tree after typing. >> On win32 if one types C:\temp and hits ENTER the folder is not >> selected in the tree. If one enters C:\temp\ and ENTER it is >> selected. I think both options should be possible (since this is >> similar behavior as in Windows Explorer, and yes I'm biased). The >> reason is that anything after the "pathNameDelimiter" >> is always identified as pattern. >> See implementation in FileList>>pathAndPattern: >> One possible solution could to check first if a subdirectory >> with the extracted pattern exists >> "(FileDirectory on: base) fileOrDirectoryExists: pat" >> and react accordingly (ignore it as pattern and add it to the >> base). >> What do others think. Bye >> T. > > |
In st80, there was also a nice feature: * and ? would also apply to any part of the hierarchy
like: /home/nice/squeak/*/*.cs Nicolas 2009/10/7 Bert Freudenberg <[hidden email]>
|
On Wednesday 07 Oct 2009 10:26:48 pm Nicolas Cellier wrote:
> In st80, there was also a nice feature: * and ? would also apply to any > part of the hierarchy > like: /home/nice/squeak/*/*.cs Since Squeak is a VM accessing filesystem on its host, shouldn't we be using URLs in the image and let FilePlugin resolve it into pathnames? Subbu |
K. K. Subramaniam wrote:
> On Wednesday 07 Oct 2009 10:26:48 pm Nicolas Cellier wrote: >> In st80, there was also a nice feature: * and ? would also apply to any >> part of the hierarchy >> like: /home/nice/squeak/*/*.cs > Since Squeak is a VM accessing filesystem on its host, shouldn't we be using > URLs in the image and let FilePlugin resolve it into pathnames? I'm not particularly in favor of that option in tools that actually expose the file names to users. When you type file paths in, it just feels wrong to type, e.g., /c/users/andreas/; and typing file:///C:/users/andreas/ is just plain awful (yes, that's *three* slashes after the colon - copied right out of firefox). It would be more useful if slashes could be universally used in code though; having to write stuff like foobar := (FileDirectoy default directoryNamed: 'foo') directoryNamed: 'bar'. is every bit as awful. Perhaps a binary operator #/ would be in order? I.e., foobar := FileDirectory default / 'foo' / 'bar'. (although this overloads the meaning of #/ which is not great either) Cheers, - Andreas |
Well we used URI with great success in Sophie, since we could use a
relative path then resolve it to a network path, file system path, or a specialized in memory path in order to store book objects in those three storage areas. But a few things come to mind for example we could someone do foo := CPlatform homeDirectory or documentDirectory or tempDirectory or musicDirectory and it would mostly do the right thing based on the platform to construct a URI. then what if you did fum := CPlatform homeDirectory , 'myStuff' , 'calledWhat' , 'where.txt' . using the ',' operator to concatenate a path together. Then a method to return the proper path based on the type you want, and of course the platform specific details. platformDirectoryPath = fum asFileSytemDirectoryPath. On 2009-10-07, at 9:04 PM, Andreas Raab wrote: > K. K. Subramaniam wrote: >> On Wednesday 07 Oct 2009 10:26:48 pm Nicolas Cellier wrote: >>> In st80, there was also a nice feature: * and ? would also apply >>> to any >>> part of the hierarchy >>> like: /home/nice/squeak/*/*.cs >> Since Squeak is a VM accessing filesystem on its host, shouldn't we >> be using URLs in the image and let FilePlugin resolve it into >> pathnames? > > I'm not particularly in favor of that option in tools that actually > expose the file names to users. When you type file paths in, it just > feels wrong to type, e.g., /c/users/andreas/; and typing file:///C:/users/andreas/ > is just plain awful (yes, that's *three* slashes after the colon - > copied right out of firefox). > > It would be more useful if slashes could be universally used in code > though; having to write stuff like > > foobar := (FileDirectoy default directoryNamed: 'foo') > directoryNamed: 'bar'. > > is every bit as awful. Perhaps a binary operator #/ would be in > order? I.e., > > foobar := FileDirectory default / 'foo' / 'bar'. > > (although this overloads the meaning of #/ which is not great either) > > Cheers, > - Andreas > -- = = = ======================================================================== John M. McIntosh <[hidden email]> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== |
John M McIntosh wrote:
> Well we used URI with great success in Sophie, since we could use a > relative path then resolve it to a network path, file system path, or a > specialized in memory path in order to store book objects in those > three storage areas. > > But a few things come to mind for example we could someone do > > foo := CPlatform homeDirectory or documentDirectory or tempDirectory > or musicDirectory and it would mostly do the right thing based on the > platform to construct a URI. Interesting. The result was a URI instead of a FileDirectory? In Qwaq^H^H^H^H Teleplace we we use e.g., FileDirectory [temp|home|log|cache]Directory to return instances of FileDirectory. Or did you implement most of the interesting file creation methods on URIs as well? > then what if you did > > fum := CPlatform homeDirectory , 'myStuff' , 'calledWhat' , > 'where.txt' . Ooooh. Comma. I like that. Already a generic concatenation operator. Much better than slash. > using the ',' operator to concatenate a path together. Then a method to > return the proper path based on the type you want, and of course the > platform specific details. > > platformDirectoryPath = fum asFileSytemDirectoryPath. That is quite nice. Yeah I could see using that. Any chance you can re-release the URI code as MIT? (IIRC, Sophie is BSD, right?). Cheers, - Andreas |
Andreas Raab wrote:
>> then what if you did >> >> fum := CPlatform homeDirectory , 'myStuff' , 'calledWhat' , >> 'where.txt' . > > Ooooh. Comma. I like that. Already a generic concatenation operator. > Much better than slash. i often build filenames using the comma (e.g. name, '.txt') so i don't think that its good to use the comma as a directory separator. just my few 2c thanks wolfgang |
In reply to this post by Andreas.Raab
On 7-Oct-09, at 9:04 PM, Andreas Raab wrote: > Perhaps a binary operator #/ would be in order? I.e., > > foobar := FileDirectory default / 'foo' / 'bar'. I wasn't actually going to mention this for a few more days, but since it's come up... I've been working on a new filesystem API built on top of the FilePlugin primitives. It does just what you propose above. The following gives an absolute path: ref := FSReference defaultDirectory / 'foo' / 'bar'. A reference is just well, a reference, to a file or directory, not an actual open stream, so it can respond to #exists #isDirectory #isFile #delete #copyTo: #fileStreamDo: and so on. It's much nicer than FileDirectory. It's completely untested on Windows, and there's no documentation yet, but if anybody wants to take a look it's here: http://source.wiresong.ca/mc/Filesystem-cwp.22.mcz Colin |
In reply to this post by Andreas.Raab
On 2009-10-07, at 9:53 PM, Andreas Raab wrote: > John M McIntosh wrote: >> Well we used URI with great success in Sophie, since we could use a >> relative path then resolve it to a network path, file system path, >> or a specialized in memory path in order to store book objects in >> those >> three storage areas. >> But a few things come to mind for example we could someone do >> foo := CPlatform homeDirectory or documentDirectory or >> tempDirectory or musicDirectory and it would mostly do the right >> thing based on the platform to construct a URI. > > Interesting. The result was a URI instead of a FileDirectory? In > Qwaq^H^H^H^H Teleplace we we use e.g., FileDirectory [temp|home|log| > cache]Directory to return instances of FileDirectory. Or did you > implement most of the interesting file creation methods on URIs as > well? As the Sophie storage Czar I ensured everything was a URI. The book storage manager then would instantiate a concrete class that would resolve the URI to the particular target (file, network, memory) at the point of doing the open/read/write/delete/copy. > >> then what if you did >> fum := CPlatform homeDirectory , 'myStuff' , 'calledWhat' , >> 'where.txt' . > > Ooooh. Comma. I like that. Already a generic concatenation operator. > Much better than slash. > >> using the ',' operator to concatenate a path together. Then a >> method to return the proper path based on the type you want, and of >> course the platform specific details. >> platformDirectoryPath = fum asFileSytemDirectoryPath. > > That is quite nice. Yeah I could see using that. Any chance you can > re-release the URI code as MIT? (IIRC, Sophie is BSD, right?). Oooh a license question. Well you would have to ask Michael, I'd *believe* the majority of the URI code predated usage in Sophie. However maybe we want to consider the issue, where this path to an object and then why would we make the object a URI or a text string? Perhaps it should be it's own unique class which you resolve to a URI or filesystempath when needed. As mentioned in another note the issue(s) for example path := path,'foo' does that mean we want to add the foo directory or tack on 'foo' to the last textual item? > > Cheers, > - Andreas -- = = = ======================================================================== John M. McIntosh <[hidden email]> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== |
In reply to this post by Andreas.Raab
On Thursday 08 October 2009 09:34:41 am Andreas Raab wrote:
> Perhaps a binary operator #/ would be in order? I.e., > > foobar := FileDirectory default / 'foo' / 'bar'. > > (although this overloads the meaning of #/ which is not great either) It is an excellent idea if URI extends Collection. Collections like squeakland, temp directory etc. could be defined as separate name spaces like home://, tmp://, squeakland:// and map entries to pathnames at run time. Imagine begin able to load projects with: squeakland := URI namespace: 'squeakland'. project = squeakland / 'featured projects' at: 'brule.pr'. Subbu |
In reply to this post by johnmci
On Wed, Oct 7, 2009 at 9:44 PM, John M McIntosh <[hidden email]> wrote: Well we used URI with great success in Sophie, since we could use a relative path then resolve it to a network path, file system path, or a specialized in memory path in order to store book objects in those I find this horribly confusing. e.g. fum := CPlatform homeDirectory , 'myStuff' , ('called' , 'What'), 'where.txt' . slash is much much better IMO. using the ',' operator to concatenate a path together. Then a method to return the proper path based on the type you want, and of course the platform specific details. |
Free forum by Nabble | Edit this page |