Slashdot Mirror


Perl Carbon/Cocoa Bindings on Mac OS X?

gigawattwarlock asks: "As an almost new Mac OS X user (I've been adminning my wife's Mac for a while now), I am used to writing Perl scripts for her Mac, which work just fine. Simply put, I have become spoiled with the GTk bindings for Perl on Linux. I love being able to use and abuse a robust GUI, quickly and easily. And to make matters worse, I find the Aqua interface near addictive ... enough so that the idea of installing another desktop environment (KDE, Gnome, et. al) just seems a little silly, and a bit of overkill, to me. Does anyone know if there are any perl bindings in the works for Mac OS X or maybe even an already existent alternative graphical library or interface within Mac OS X?"

22 of 57 comments (clear)

  1. camelbones by Fiery · · Score: 5, Informative

    Here's a project that's doing this. They seem to have functioning code, too.

    1. Re:camelbones by tim1724 · · Score: 2

      Camelbones works pretty well, but the documentation is nearly non-existant, unfortunately. But if you've used AppKit and Foundation from Objective-C (or Java, I suppose) then it shouldn't be too hard to figure out from the examples.

      I made a few simple test programs and didn't have any trouble, but I have a feeling that some of the more esoteric bits of Cocoa might not work too well.

      The PerlObjective-C bridge is pretty good. Perl is pretty well suited for interacting with Objective-C (better than Java, certainly) due to its dynamic nature.

      --
      -- Tim Buchheim
    2. Re:camelbones by bsartist · · Score: 2

      Camelbones works pretty well

      Thanks, I'm glad you like it.

      the documentation is nearly non-existant, unfortunately.

      Guilty as charged. All I can say is, I didn't think very many people were interested in it; I can count the daily hits on the project page with one hand. Seems like the interest level is higher than I thought, though, so I'll get off my lazy ass and write more docs, pronto.

      --
      Lost: Sig, white with black letters. No collar. Reward if found!
  2. Just use Objective C by foobar104 · · Score: 5, Informative

    Yeah. There are several, in various stages of incompleteness.

    But why don't you just read the tutorial and learn to program Cocoa with Objective C? Programming Cocoa apps with Objective-C, using Project Builder and Interface Builder, is, I dare say, easier than writing Perl scripts that call Cocoa functions would be. You don't even need to be terribly familiar with C to write simple apps.

    Don't get me wrong. I love Perl as much as the next guy. But I don't like writing GUI code. It's a pain in the ass, no matter how nice the programming language might be. The combination of Interface Builder and Objective C makes whipping up little Cocoa apps easy as pie, and fun, too.

    You can find the Objective-C Cocoa tutorial in PDF form here. It's also included with the OS X developer's tools under /Developer/Documentation/Cocoa/ObjCTutorial.

    1. Re:Just use Objective C by BitGeek · · Score: 3, Informative

      Please mod this parent up, its NOT off topic.

      The reason is this: Getting access to perl code you've written or integrating perl with an Obj-C API is really easy using this method.

      If you write an application in Obj C (or Java-- actually Java would be my choice) you get to use interface builder to build your UI-- this is the best/fastest way to build a great UI. Then, its a simple matter of linking that UI to the perl scripts you've already written.

      This can be done in a number of ways, the most explicit being to simply call the shell from within your ObjC application.

      ObjC (despite my prior prejudice against it) is turning out to be a pretty decent and relatively easy language to learn. And, of course, when you consider Interface Builder its the best way to build an interface for any language-- just write minimal ObjC to tie your buttons, etc, to the bulk of your code.

      I imagined you'll spend 3 hours learning the ObjC stuff and then be back on your way programming-- and actually get more productive than if you have a Perl Aqua UI to work with because it would be slower to specify that Aqua UI in Perl using the custom API (than using Interface Builder.)

      So please, mod this parent up-- essentially the "bridge" is already there, its just "unconventional". Not "offtopic".

      --
      Yeah, and you guys panned the ipod too: http://apple.slashdot.org/article.pl?sid=01/10/23/ 1816257
    2. Re:Just use Objective C by bsartist · · Score: 2

      using Project Builder and Interface Builder, is, I dare say, easier than writing Perl scripts that call Cocoa functions would be.

      Yes indeed it is! That's why I included support for PB+IB in CamelBones from the start - because I hate writing GUI code.

      --
      Lost: Sig, white with black letters. No collar. Reward if found!
  3. Ask Pudge! by 2nd+Post! · · Score: 5, Informative

    Have you looked here?

    Pudge has a site with lots of Mac+Perl info and projects, including a link to this, a tool to connect Perl to the Apple Event model.

    Of course this begs the question why you haven't already looked at AppleScript Studio and AppleScript, which allows you to script the OS and many of it's Apps?

    This snippet allows me to start my apps when I get into work:

    tell application "ICQ 3.0X"
    activate
    end tell
    tell application "AOL Instant Messenger (SM)"
    activate
    end tell
    tell application "Yahoo! Messenger"
    activate
    end tell
    tell application "Microsoft Outlook"
    activate
    end tell

    It's not particularly complex nor instructive, but AppleScript is full featured and extensive. I have a cronjob run an AppleScript in the mornings, where the AppleScript opens iTunes, opens a playlist, and then start playing, as my alarm clock!

    tell application "iTunes"
    play user playlist "Sweet-Sad"
    play
    end tell

    1. Re:Ask Pudge! by 2nd+Post! · · Score: 2

      Work, man, I don't get a choice. The firewalls and stuff restrict me to what apps I run at work.

      At home it's Eudora, Netscape, and Fire.

      But thanks anyway, I was hoping to make a more complicated script eventually, with if-then-else clauses and logon if already active and do nothing if active *and* logged on, etc.

    2. Re:Ask Pudge! by 2nd+Post! · · Score: 2

      Cause I don't log out.

      I guess I *could*, but I usually just close the screen and go home, open the screen and fire up my AppleScript

  4. O'Reilly book on Perl/Cocoa coming soon? by wka · · Score: 2, Informative
    From the preface to Building Cocoa Applications: A Step-by-Step Guide, (page xviii, after mentioning an upcoming book on Cocoa and Java):
    "(And for those interested in writing Perl applications for this new platform [OS X], watch for Programming Cocoa Applications with Perl, also coming soon from O'Reilly.)"
    Note: I don't see anything about this on O'Reilly's new and upcoming book list, so it's possibly quite a few months off.
    1. Re:O'Reilly book on Perl/Cocoa coming soon? by Elian · · Score: 2, Informative

      Yep, a while off. A few chapters done, and more to come. (Sez the man feverishly writing the thing... :)

  5. jaguar by Anonymous Coward · · Score: 4, Informative

    I wouldn't put too much work into your own solutions...

    Perl-Objc bindings are included in jaguar.

    See: Library/Perl/darwin/PerlObjCBridge.pm

    1. Re:jaguar by Elian · · Score: 2, Informative

      This doesn't work at all well. Tried it, no joy. The problem is that Cocoa only works with real, honest-to-goodness applications, and you have to load the frameworks in the right order.

    2. Re:jaguar by bsartist · · Score: 2

      Perl-Objc bindings are included in jaguar.

      Yes, but they only work well with Foundation classes, because they're implemented as a module that gets loaded into a traditional Perl script. AppKit depends pretty heavily on being surrounded by an application bundle, I'm afraid.

      CamelBones is implemented as a framework that gets linked into an application, and lets you build your GUI with Interface Builder. On the other paw, it can't be loaded into a standalone script as a module; like AppKit, it requires an application bundle.

      The two products are addressing different problems, really; which one will be more useful to you depends on what you want to accomplish.

      --
      Lost: Sig, white with black letters. No collar. Reward if found!
  6. use python w/ native mac GUI or Gtk/Qt on mac X by Splork · · Score: 3, Informative

    python apparently has excellent macos X gui support. (i don't pay the apple tax myself so i can't judge first hand). on top of that you should be able to use anything with Qt or Gtk bindings using X on the mac (python and perl both have good bindings there).

    [and before any perl weenies mod this down because i said to use a different language: grow up!]

    1. Re:use python w/ native mac GUI or Gtk/Qt on mac X by bsartist · · Score: 2

      python apparently has excellent macos X gui support.

      I haven't actually *created* anything using PyObjC, but I did learn quite a bit about the inner workings of the Objective-C runtime by studying the code. I'd go so far as to say that I couldn't have written CamelBones without first studying the PyObjC bridge - there's some stuff in there that I still haven't seen documented anywhere. So, as far as my own limited exposure to it goes, I'd say that yes, Python's support for Cocoa is very good.

      I agree with the other part of your post, too - the more options that OS X programmers have, the better. Language bigots need to grow up.

      --
      Lost: Sig, white with black letters. No collar. Reward if found!
  7. More Resources by pudge · · Score: 5, Informative

    I meant to respond earlier, but didn't get the chance. There are several ways to go about this. One is to the oft-mentioned CamelBones, which is in initial stages, but is a great start for Cocoa bindings. For Carbon, there is a vaporware project I've played with, a SWIG-based glue for Perl, Python, Tcl, Ruby, and maybe more, and more details of it will be forthcoming when it's ready.

    Right now there is also the Carbon-based MacOSX::File, which offers much of the same functionality as the Mac::Files module included in MacPerl, and there is OSXMacPerl, a basic clone of the MacPerl module (DoAppleScript and more are provided).

    And some day I would like to port the Mac:: modules to Carbon, if I get the tuits.

  8. Re:Apple: OSX Now available for Intel by twiztidlojik · · Score: 2, Interesting

    You, my friend, do not belong at slashdot. Just because someone ported a kernel and some low-level tools to the Wintel platform, it doesn't mean that it comes with:
    Drivers
    a GUI
    Carbon support
    Cocoa support
    Framework support
    OS 8.6+ support

    or anything else that comes with OS X. In other words, you can't run, say, iTunes in Darwin for Intel/AMD. I would hope that the Slashdot community would know that a kernel is not all that an operating system is. You, obviously, cannot tell the difference.
    This would be analogous to say, building a house. Suppose you could make a foundation for a house in a flat, grassy area and build a house on it. This would be OS X. Now, let's say that you could take a barrel of concrete and pour it down a sheer cliff. This sloppy, messy, incoherent splatter would be Darwin for Intel/AMD. Yes, it would be concrete, and yes, it might even mold itself into a semblance of a foundation. BUT , you cannot build a full-fledged house on a sheer cliff with a small, globular, spattered foundation that may not even be in one specific area!

    --
    I will now redundantly add my name to the end of my post. You know, in case you forgot me or something.
  9. Re:Use Ruby with RubyCocoa by rjamestaylor · · Score: 2
    As I read your post I imagined your response to another request...
    [Dying Man]: Can you call my priest? I need to get right with God.

    [NikWest]: [Hands the man a Playboy and some Kleenex]
    Not exactly what you have asked for, but as I like masturbating a lot better than praying you might want to give it a try.

    Has it ever occured to you that when someone asks for an apple they want an apple and not your opinion of oranges?
    --
    -- @rjamestaylor on Ello
  10. Re:Apple: OSX Now available for Intel by foobar104 · · Score: 2

    In other words, you can't run, say, iTunes in Darwin for Intel/AMD.

    I know this is trollfodder (not you; the guy two posts above you) but here it is anyway.

    As was pointed out to me just the other day, you can just barely run Darwin for Intel at all. The list of supported hardware is incredibly short. Behold:

    Supported Hardware:
    -------------------

    IDE:
    Only the PIIX4 IDE controllers have been found to work.
    Attached devices must be UDMA/33 compatible or better.
    Ethernet:
    Intel 8255x 10/100 ethernet controllers are supported.
    Video:
    You must have a VESA 2.0 compliant video card. Almost all
    modern graphics cards are VESA 2.0 compliant. However, emulators
    such as vmware do not have VESA 2.0 compliant emulated video cards.
    Successfully tested hardware:
    All 440BX motherboards tested have worked with their internal
    IDE controllers.
    IBM ThinkPad A21m (with onboard Intel ethernet)
    Known to not be supported:
    All AMD and VIA based systems.

  11. Re:Use Ruby with RubyCocoa by foobar104 · · Score: 2, Flamebait

    If *you* weren't so uptight you'd have thought the analogy somewhat funny.

    Um... except it wasn't. It's only funny if it's both witty and apt. Yours was only witty in the sense that you used the word "masturbation." And, as I pointed out, it wasn't apt at all.

    You missed the mark, friend.

  12. Re:Apple: OSX Now available for Intel by SIGFPE · · Score: 2

    You might notice that I didn't say "MacOS X". I said Darwin. I know full well what Darwin is. It's a pretty definitive answer to the question of "Does MacOS X exist for Intel?". The answer is that part of the code has been ported. But of course you're so full of yourself that you think I need a lecture in the parts of an OS. I think you're not terribly smart. You might know some fluff about OSes but you're certainly too slow to realise that when someone makes a short statement it doesn't mean that that is the sum total of everything that they know.

    --
    -- SIGFPE