[Pythonmac-SIG] Replacing macfs.StandardGetFile and friends.

[Alexandre Parenteau]

I'd love to be able to filter based on the FSRef or FSSpec. Using the
typeList only is less useful, especially on OSX where it is not so widely
used.

> I was thinking of raising an exception if the user cancels, maybe
> KeyboardInterrupt? Is this a good idea, or should I stick with the

Raising... I don't know... Don't like that too much for user cancellation...

[my 2c in order to make it more difficult]

Alex.

> Folks,
> I'm thinking of replacing macfs.StandardGetFile() and friends with
> another set of methods to give similar functionality, but geared more
> towards the way things are used nowadays. There will of course (for
> 2.3) be backward-compatible macfs.StandardGetFile() methods and such.
> 
> First of all I was thinking of moving the functionality to EasyDialogs.
> The full interface is in Nav anyway, and an easy way to get files for
> opening or saving sounds like something that should go into EasyDialogs.
> 
> Second, I was thinking of providing three calls: AskFileForOpen(),
> AskFileForSave() and AskFolder(). Are those enough? Any thoughts on the
> names? All will have a couple of optional parameters:
> - prompt: a string to use as the prompt.
> - return_type: pass the type of object you want returned here, either a
> string, an FSSpec or an FSRef. FSRef is not allowed for
> AskFileForSave().
> - typelist: a list of 4-char filetypes that are acceptable
> (AskFileForOpen only). Do we need another interface, such as
> extensions? Mimetypes?
> - default: (AskFileForSave only) the default for the saved file name.
> - folder: the folder that you want to show the user initially.
> - preferenceKey: the Nav Services preference key. By passing something
> here the next time you call the dialog with the same preferenceKey it
> will be in the same place. Interaction of this with folder needs to be
> examined.
> 
> Any more NavServices features that should be exposed, such as automatic
> conversion of documents?
> 
> I was thinking of raising an exception if the user cancels, maybe
> KeyboardInterrupt? Is this a good idea, or should I stick with the
> current (value, ok) tuple? Return None?
> --
> - Jack Jansen        <Jack.Jansen@oratrix.com>
> http://www.cwi.nl/~jack -
> - If I can't dance I don't want to be part of your revolution -- Emma
> Goldman -
> 
> 
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
> 

-- 
Alexandre Parenteau
Computer Scientist
Core Technologies, AGM
Adobe Systems, Inc.
408-536-6166