Loading ...
Sorry, an error occurred while loading the content.

Re: [frontierkernel] Some OSX things for testing

Expand Messages
  • Seth Dillingham
    ... My main point was that the scripting interface in Frontier has largely been defined to hide the differences between the platforms. I think it would be
    Message 1 of 5 , Jul 25, 2005
    View Source
    • 0 Attachment
      On 7/19/05, Karsten Wolf said:

      >AFAICT not. In my knowledge windows and linux just use filepath
      >strings. On Frontier windows shares the "tyfilespec" but simply uses
      >only the name part. For the Linux part: does it use Unicode? OSX
      >filenames are Unicode only (another problem with frontier).

      My main point was that the scripting interface in Frontier has largely
      been defined to hide the differences between the platforms.

      I think it would be better to enhance the existing verbs to make better
      use of unix-style paths and unicode where possible, rather than
      creating a new set of mac-only file-handling verbs. I'd rather add the
      functionality of these long-path verbs to what we already have (such as
      automatic coercion between filespec and filepath, and alias on mac).

      Seth
    • Karsten Wolf
      ... I don t see it that way. Untill V5 frontier was mac only. If it were to define a platform independent file path representation, that still has to be done.
      Message 2 of 5 , Jul 25, 2005
      View Source
      • 0 Attachment
        Am 25.07.2005 um 16:21 schrieb Seth Dillingham:

        > My main point was that the scripting interface in Frontier has largely
        > been defined to hide the differences between the platforms.
        I don't see it that way. Untill V5 frontier was mac only. If it were to
        define a platform independent file path representation, that still has
        to be done. There are too many scripts with ifMac/ifWin cases &
        file.getPathChar().

        If you want platform independence you're free to define some abstract
        framework[*] for it. I'm into the details that framework will
        eventually use.

        The category is named carbon because these are carbon only. It also
        acts as a playground. If they become stable and are accepted they could
        be integrated into the file category. I'm not asking for including a
        carbon category into the main trunk.

        I have them because I need them.

        I will have them in my kernel at least till all file.* verbs can handle
        long filenames. That's a lot of plumbing...

        > I think it would be better to enhance the existing verbs to make better
        > use of unix-style paths and unicode where possible, rather than
        I regard unix-style path only as an option.

        Unicode is a necessity. I'm thinking about using CoreFoundation. It's
        just a thousand places in the source...

        See: http://developer.apple.com/darwin/cflite.html

        > creating a new set of mac-only file-handling verbs. I'd rather add the
        > functionality of these long-path verbs to what we already have (such as
        > automatic coercion between filespec and filepath, and alias on mac).
        filespec, string & alias. filepath is a string.

        As I said before: That's a lot of work. I simply don't see it done.
        What's currently happening in kernelwork? Not much on this list... So
        DIY.

        -karsten


        [*]
        sth. like
        frontierFilePath
        - volume
        volumename on mac
        driveletter on win
        ???(perhaps mount point) on linux
        - ordered list of directory names
        - encoding

        goes along with changing the kernel to use these and with some library
        for

        x = file.getPlatformPath(aFrontierPath)
        x = file.getMacPath(aFrontierPath)
        etc...
      Your message has been successfully submitted and would be delivered to recipients shortly.