Zinc cannot open files in the “Zinc Project” format.



  • Stupid program claims to be not able to open its own file?

    Clicking the file from the Finder: the above.

    Using File, Open and selecting the same file, success.



  • TRWTF is the Finder, of course



  • @TheRider said:

    TRWTF is the Finder, of course
     

    Well, not this time. Finder certainly just run the command "zinc $FILENAME". It's up to zinc to be able to open the files it tells the OS it's able to open. The OS has no means of testing if your software is lying.

    (For a similar problem, look at Firefox.)



  • It's quite possible the file is corrupted...



  • @Mcoder said:

    Well, not this time. Finder certainly just run the command "zinc $FILENAME".

    Fucking seriously?

    How far Mac OS has fallen from its glory days...



  • No, I don't think that Finder needs to spawn a bash in order to launch an app bundle.



    The issue is probably with Zinc having registered itself wrongly or just flat-out refusing to open files given to it at program launch.



  • @j6cubic said:

    No, I don't think that Finder needs to spawn a bash in order to launch an app bundle.

    The issue is probably with Zinc having registered itself wrongly or just flat-out refusing to open files given to it at program launch.
     

    Of course it needs a "spawn", it's not going to run the app in its own memory. It wasn't even that weird under OS 7. Anyway, if you want to open a file from the command line with a Cocoa or Carbon based application, you do it like this

    $ open -a Zinc ShellF.zinc

    Anyway, according to the almighty Duck, Zinc is the ultimate SWF2EXE. There is you WTF.



  •  Reminds me of Cava Packager, a program that compiles Perl programs into binaries - if you dare to rename your project file to anything but "cava20.cpkjproj", you can't open it, because the "open project" dialog filters not only on extension but on the full filename!



  • @TGV said:

    Of course it needs a "spawn", it's not going to run the app in its own memory.
     

    I guess j6cubic is complaining that I used a bash-like syntax.

    Here, that's the same thing in C (without the blank space bug):

    exec('zinc', filename);

     



  • @Mcoder said:

    Here, that's the same thing in C (without the blank space bug):

    execlp("zinc", "zinc", filename);

    FTFY.

    (C uses double quotes for string literals; there's no plain exec function; argv[0] should contain the program's name)



  • Swf2exes that cost real money is a wtf, mostly that adobe couldn't do this natively. A lot of zinc functions are AS2 style and have differences between mac/win/Linux. The documentation is often slightly incorrect, plus it doesn't work as you expect. For example, there's a class to let you download from a HTTP server, but anything over a few megabytes and it just freezes.



  • @blakeyrat said:

    @Mcoder said:
    Well, not this time. Finder certainly just run the command "zinc $FILENAME".

    Fucking seriously?

    How far Mac OS has fallen from its glory days...

    I think the message comes from zinc. Its icon jumped up and down for a few seconds, and I got the zinc splash screen before the message came up.

    how did holy classic mac run and app from clicking on a "document file" in finder?



  • @tdb said:

    (C uses double quotes for string literals; there's no plain exec function; argv[0] should contain the program's name)
     

    Yep, there is a long time I don't do anything like that in C...

    Now I remember why. I also forget to "if(!fork())" before it, so I'd spawn a new process and annoy blakeyrat.



  • @Zemm said:

    how did holy classic mac run and app from clicking on a "document file" in finder?

    It didn't run a goddamned console command I can guarantee that.



  •  But why it would be a problem to run a command line exactly ?



  • Because a GUI shouldn't depend on a CLI. Modularity.



  • @blakeyrat said:

    Because a GUI shouldn't depend on a CLI. Modularity.
     

     And the same functionality, lauching program, should be done two time and not be common. You know, to avoid bug.



  • No; launching a file should be done using an OS call that both the CLI(s) and GUI(s) use to launch files. I don't know why this is hard.



  • @blakeyrat said:

    No; launching a file should be done using an OS call that both the CLI(s) and GUI(s) use to launch files. I don't know why this is hard.
    Hmmm, so blakey understands this concept when applied to a mac, but fails to comprehend it when it comes to linux?



  • @Zemm said:

    how did holy classic mac run and app from clicking on a "document file" in finder?

    Structured message passing. When you select one or more files in the Finder and invoke Open (or double-click one of them), the Finder creates a list of them and passes this list inside a single message to the application. If the program is not running, this will be the first message it receives. These messages are referred to as Apple Events. Messages are freeform nested structures, a bit like JSON with strictly typing, built using a C API, with a number of common request types such as opening files, printing files and opening URLs.

    Message type IDs and data type IDs, both 32-bit words (four-CCs, the same as type and creator codes), can be mapped to human language terms (using an aete, or AppleEvent Terminology Extension resource) and used within scripts. This is AppleScript — a high-level wrapper around the message passing system.

    I don't know for sure that this is still how programs communicate in OS X, but AppleScript isn't dead.



  • @Daniel Beardsmore said:

    @Zemm said:

    how did holy classic mac run and app from clicking on a "document file" in finder?

    Structured message passing. When you select one or more files in the Finder and invoke Open (or double-click one of them), the Finder creates a list of them and passes this list inside a single message to the application.

     

    On MacOS, is there a list of registered applications associated with known filetypes? Like the Win registry, or Gnome's File Associations?

    Just curious how the Mac determines what the file type is (filename extensions?) and decides which application to use.

     



  • @Cassidy said:

    On MacOS, is there a list of registered applications associated with known filetypes? Like the Win registry, or Gnome's File Associations?

    Just curious how the Mac determines what the file type is (filename extensions?) and decides which application to use.

    It has always been stored inside the application itself. Used to be in the BNDL, FREF and kind resources (along with all the associated icons), now it's inside info.plist, an amalgamation of all the classic metadata/manifest resources, which also supports URI schemes and file extensions. Mac OS automatically registers file types when it encounters a program. This means that when you drag a file over a program, the program icon will only darken (to show drag and drop acceptance) if the file type will be accepted, which the OS knows in advance.



  • @Daniel Beardsmore said:

    now it's inside info.plist, an amalgamation of all the classic metadata/manifest resources, which also supports URI schemes and file extensions
     

    I take it this info.plist is extensible...? Just curious how I can associate a new extension/type to be registered by an application if it doesn't darken to signify prior acceptance.



  • @Cassidy said:

    I take it this info.plist is extensible...? Just curious how I can associate a new extension/type to be registered by an application if it doesn't darken to signify prior acceptance.

    The programmer associates file types with the application, indicating among other things whether the application is an editor or a viewer for them (IIRC, editors can save documents through the Cocoa systems for doing so, viewers can't).

    Users can associate documents with applications by opening the document's Info window and selecting an application there to open that particular document with; they can try an application that the OS doesn't think can open the file, if they want to. A button then lets them choose to use the chosen application for all documents of that type, but initially it only applies to the one specific document.

    A user could edit Info.plist to make the OS believe the application can open documents of a given type, but because it's inside the application bundle most users won't even be aware it exists, and even if they are they'd need to know enough about coding for OS X to know the necessary format. Using the Info window in the Finder is a bit easier all around, I'd say :)



  • @Daniel Beardsmore said:

    Structured message passing. When you select one or more files in the Finder and invoke Open (or double-click one of them), the Finder creates a list of them and passes this list inside a single message to the application. If the program is not running, this will be the first message it receives. These messages are referred to as Apple Events. Messages are freeform nested structures, a bit like JSON with strictly typing, built using a C API, with a number of common request types such as opening files, printing files and opening URLs.


    Well that sounds more useful than argc and argv.



  • @Cassidy said:

    I take it this info.plist is extensible...? Just curious how I can associate a new extension/type to be registered by an application if it doesn't darken to signify prior acceptance.

    Sorry, I didn't make a lot of sense.

    Mac OS has always maintained a database of file associations. It was the Desktop Database in classic Mac OS, later supplemented by the third-party then official InternetConfig to handle URI schemes and file association mappings. InternetConfig had a UI (originally Quinn the Eskimo's, but Apple created a new one when they made it official), but the Desktop Database was strictly automated. Unlike the Registry, it was not in any way user editable, just an opaque file. Your options were to wipe it (hold certain keys during boot) or use various hacks to force reassociation. It was extended to cover file comments, and for many years, wiping the desktop database deleted all your file comments. Eventually Apple programmed the Finder to make a note of them and write them back into the fresh Desktop Database.

    Launch Services in OS X does, as Gurth noted, support per-file and per-file-type customisation now. The UI for mapping URI schemes and file extensions was removed, as the info.plist file contained inside each application—the application manifest—supports defining these directly, allowing them to be set automatically.



  • @spamcourt said:

    Well that sounds more useful than argc and argv.

    Apple Events are fantastic. Windows has a similar system called DDE that allows for custom messages to be passed using the message queue. The only use I've ever seen this put to it to let Explorer pass files and URLs to a running instance of a program, instead of the old Windows hack of starting a new process that uses mutexes to check whether it's already running (typically without figuring out whether that process is even owned by the same user).



  • The problem with Windows is no matter how cool and exciting their new stuff, 99% of Windows programmers still think they're writing for DOS. Or, at absolute best, Windows 95.



  • @blakeyrat said:

    The problem with Windows is no matter how cool and exciting their new stuff, 99% of Windows programmers still think they're writing for DOS. Or, at absolute best, Windows 95.

    Especially those people who still only see in 16 colours. Microsoft's 16 poorly-chosen colours, no less.



  • @Daniel Beardsmore said:

    Especially those people who still only see in 16 colours. Microsoft's 16 poorly-chosen colours, no less.

    Bigger problem are the ones that can see in colours. I have several friends who are colour-blind, including one that got fired from a job because the system only used colour to distinguish between states, so (s)he couldn't tell. (I include the s on the front of the he because this person is transgendered. That may have been the "real" reason for the firing though)

    @blakeyrat said:

    The problem with Windows is no matter how cool and exciting their new stuff, 99% of Windows programmers still think they're writing for DOS

    Is this going to change with RT? But then RT is all about changing everything about Windows, so maybe the stuff that "no-one uses" will be removed.


Log in to reply