So, I've implemented my proposed suggestions to support compressed files (more exactly, just gzipped files for now) in OpenSave. By default, open panels will show (and possibly return) .gz file names while save panels will not. This behavior can be overridden by supplying the boolean keyword 'compress' to the panel constructor. New functions/attributes in OpenSave are: compressSuffixes: a list of file-name suffixes where compression is assumed. Currently just ['.gz']. osOpen(filename, *args, **kw): should be used to open files where compression is relevant. Will return a file-like object. If the file is opened for input, compression will be handled automatically. If opened for output, will use compression if the file name has a suffix in compressSuffixes unless a boolean 'compress' keyword is supplied. Other args and kw are compatible with the underlying open() used [built-in for uncompressed; gzip.open() for compressed]. osUncompressedPath(inPath): will return a path to an uncompressed version of 'inPath'. Designed to be used to hand off uncompressed files to C++ layer interfaces. Returns 'inPath' if 'inPath' is already uncompressed. Otherwise it uncompresses into a temp file that gets deleted at APPQUIT. I've modified all uses of OpenSave that I could find to allow for compression where appropriate. Besides the main open panel, it works with the start-up command-line args and in the Chimera command line as far as I've tested. Let me know if anyone finds problems. --Eric
Hi Eric, Could you add a canDecompress option to chimera.fileInfo.register()? This will be set true or false when extensions register a new file type and will indicate whether the file opening routine can handle compressed files. Tom
On Friday, May 16, 2003, at 09:43 AM, Thomas Goddard wrote:
Could you add a canDecompress option to chimera.fileInfo.register()? This will be set true or false when extensions register a new file type and will indicate whether the file opening routine can handle compressed files.
Hi Tom, I'm guessing that you've decided that using osUncompressedPath in the extension code is unsatisfactory and you are therefore asking for this keyword. Which implies that the behavior you want is that for file types where 'canDecompress' is false, the open panel won't show compressed versions of that file type. Am I right? This leads to the possibly-surprising behavior of the open panel showing compressed files for some types and not others. Perhaps we should discuss this as group on Monday? --Eric
Hi Eric, The Open dialog should show all *.gz files if "File type" is set to "all". If "File type" is set to a specific type that does not support decompression it will not show *.gz files. If decompression is not supported then "all (guess type)" mode will not automatically pass a compressed file of that type to the open routine. Instead it will popup the normal dialog for unrecognized types, or popup a dialog saying compression is not supported for that type. Tom
I lean towards showing the compressed files in the browser (and allowing them on the start-up command line), but emitting an error instead of calling the registered callback. The error would say that compression isn't supported for this type and that the file needs to be decompressed by hand for use. This avoids the mysterious "some things appear in the browser, some don't" behavior. --Eric On Friday, May 16, 2003, at 10:57 AM, Thomas Goddard wrote:
Hi Eric,
The Open dialog should show all *.gz files if "File type" is set to "all". If "File type" is set to a specific type that does not support decompression it will not show *.gz files.
If decompression is not supported then "all (guess type)" mode will not automatically pass a compressed file of that type to the open routine. Instead it will popup the normal dialog for unrecognized types, or popup a dialog saying compression is not supported for that type.
Tom
participants (2)
-
Eric Pettersen -
Thomas Goddard