Professional Web Applications Themes

application duality? - Mac Programming

Hi, what would be the bet way to make an application startable from both terminal and Finder (and behave differently)? Basically I have an old unix tool ported to osx but wanted to add a cocoa gui for it. I want to retain the command line behavior and have a gui on wish. This calls for a different behavior on those launch methods. any directions?...

  1. #1

    Default application duality?

    Hi,

    what would be the bet way to make an application startable from both
    terminal and Finder (and behave differently)?

    Basically I have an old unix tool ported to osx but wanted to add a
    cocoa gui for it. I want to retain the command line behavior and have a
    gui on wish. This calls for a different behavior on those launch methods.

    any directions?

    Patryk Guest

  2. #2

    Default Re: application duality?

    In article <3fbf83d4$inet.com.pl>, Patryk 'Silver Dream !'
    Łogiewa <remove.it.pl> wrote:
     

    I did this circa Lynx.

    I don't remember the details, but when launched from the Finder, you
    actually get parms sent via (argV, argC). IIRC, the different system
    versions send different args, but they're predictable. It's like a
    Finder process ID or something. The point is, you can step into the
    debugger and take a look using any application with args - Hello World!

    Once you do that, simply add a function to read the args, and if the
    first one is the "Finder" thing, you know you were launched from the
    Finder.

    Now as for arguments in Cocoa, I don't have a clue, but I have to
    imagine that all the argument stuff in Project Builder wasnt just for
    us Carbonites..
    Mikey Guest

  3. #3

    Default Re: application duality?

    In article <3fbf83d4$inet.com.pl>,
    "Patryk 'Silver Dream !' ?ogiewa" <remove.it.pl> wrote:
     

    Probably the best way is to separate your GUI code into two apps. One is
    called from the command line, and the other one goes in a bundle and
    does the GUI stuff. To avoid duplicating code, you can either have the
    GUI app execute the command-line app as a subprocess and send it things
    (which is I think the normal way to do this sort of thing), or you
    could, I think, set up a shared library that has all the common stuff.
    Michael Guest

  4. #4

    Default Re: application duality?

    Michael Ash wrote:
     
    >
    >
    > Probably the best way is to separate your GUI code into two apps. One is
    > called from the command line, and the other one goes in a bundle and
    > does the GUI stuff.[/ref]

    I thought of it - this would simplify many things as I can keep the
    command line port in its old shape (which I prefer) and have only the
    GUI stuff aside. There would probably be some more questions then how to
    make the CLI code accessible within the shell's path without tweaking
    the envars but this can be (hopefully) minor headache.

     

    Yes. This, however, requires some sort of communication between those
    two. Since my unix tool "behaves properly" - meaning: uses argc, argv,
    stdout and stderr only - this goes down to a method of passing those
    from, and to the GUI. Is there an established "standard" way of doing
    this in Cocoa/MacOS X?
     

    I would prefer the previous way as it allows the unix tool code to
    remain as it was.

    Patryk Guest

  5. #5

    Default Re: application duality?

    Mikey wrote:
     
    >
    >
    > I did this circa Lynx.
    >
    > I don't remember the details, but when launched from the Finder, you
    > actually get parms sent via (argV, argC). IIRC, the different system
    > versions send different args, but they're predictable. It's like a
    > Finder process ID or something. The point is, you can step into the
    > debugger and take a look using any application with args - Hello World!
    >
    > Once you do that, simply add a function to read the args, and if the
    > first one is the "Finder" thing, you know you were launched from the
    > Finder.[/ref]

    Hm, this looks a bit like a "hack", doesn't it? ;-) Of course it might
    also be the "official" method but would prefer to know that as to blame
    Apple when they change something and not you ;-)
     

    I think this could be hooked into before any Carbon or Cocoa stuff even
    shows up.

    Patryk Guest

  6. #6

    Default Re: application duality?

    In article <inet.com.pl>,
    "Patryk 'Silver Dream !' ?ogiewa" <remove.it.pl> wrote:
     

    If you want to use Cocoa, use NSTask to spawn the task and pass it
    arguments, and NSPipe + NSFileHandle to send it things in stdin and
    receive things via stdout. It's all quite easy with those, the only hard
    part is parsing everything, which is of course your own problem. :)

    If you're comfortable with UNIX, you can, of course, use pipe(), dup2(),
    fork(), and exec*(). If you aren't already familiar with those, then
    NSTask is probably better.
     
    >
    > I would prefer the previous way as it allows the unix tool code to
    > remain as it was.[/ref]

    I agree that this solution is probably not as good, but I threw it in
    for completeness.
    Michael Guest

  7. #7

    Default Re: application duality?

    In article <inet.com.pl>,
    "Patryk 'Silver Dream !' ?ogiewa" <remove.it.pl> wrote:
     

    NSTask. There's a great article on writing GUI wrappers around
    command-line tools at http://www.cocoadevcentral.com IIRC.

    Cheers,
    -- M. Uli Kusterer
    http://www.zathras.de
    Uli Guest

  8. #8

    Default Re: application duality?

    In article <inet.com.pl>,
    "Patryk 'Silver Dream !' ?ogiewa" <remove.it.pl> wrote:
     

    In cocoa you can run BSD tools as subprocesses just as if you were
    typing at the command line. It's a smidge more tedious, as you have to
    contruct an NSTask object, but its nothing tough. If your old tool is
    POSIX, then cocoa should interface to it just fine.

    This is the simplest way to write a cocoa wrapper to a command line tool.

    --
    |\/| /| |2 |<
    mehaase(at)sas(dot)upenn(dot)edu
    Mark Guest

  9. #9

    Default Re: application duality?

    Patryk 'Silver Dream !' Łogiewa wrote: 

    Thanks to everybody who replied. From your clues I found a nice article at:

    http://cocoadevcentral.com/articles/000025.php

    which explains the approach.


    The one question remains. This is not directly connected to the approach
    of wrapping the command up but rather of the different approach of
    making it react differently to the start from Finder or command line.

    Is there an "official" way of recogising if the code was started from
    Finder or Command line?

    Patryk Guest

  10. #10

    Default Re: application duality?

    In article <inet.com.pl>,
    "Patryk 'Silver Dream !' Łogiewa" <remove.it.pl> wrote:
     

    I doubt it. A command-line tool should come 'naked', in the normal UNIX
    way. A GUI app should be bundled. You aren't supposed to use a single
    executable for both, so there probably isn't an official way to
    distinguish.
    Michael Guest

  11. #11

    Default Re: application duality?

    In article <inet.com.pl>,
    "Patryk 'Silver Dream !' Łogiewa" <remove.it.pl> wrote:
     

    Well... you could always call getppid() to get the parent process's PID.
    From there some work with sysctl() could establish the parent process's
    name. I don't think there's a Cocoa way to do this, but all the
    functions are doented in man pages. Is that "official" enough?

    --
    Tom "Tom" Harrington
    Macaroni, Automated System Maintenance for Mac OS X.
    Version 1.4: Best cleanup yet, gets files other tools miss.
    See http://www.atomicbird.com/
    Tom Guest

  12. #12

    Default Re: application duality?

    Tom Harrington wrote: 
    >
    >
    > Well... you could always call getppid() to get the parent process's PID.
    > From there some work with sysctl() could establish the parent process's
    > name. I don't think there's a Cocoa way to do this, but all the
    > functions are doented in man pages. Is that "official" enough?
    > [/ref]

    Yes it is. ;-) The unix/posix ways is clear. I was wondering about a
    more "Apple way" as e.g. with the NSTask vs. system() calls.

    Patryk Guest

  13. #13

    Default Re: application duality?

    In article <3fbf83d4$inet.com.pl>,
    "Patryk 'Silver Dream !' ?ogiewa" <remove.it.pl> wrote:
     

    Let me ask you a different question. What happens if I launch your app from
    AppleScript? Which case would you want to execute? What if I launch it using
    AppleScript from the command line? What if I use a 3rd parth launcher tool to do
    it? What if I ssh in and launch it?

    There are many ways to launch your app besides Terminal and Finder and they are
    impossible to distinguish. Focusing just on the Finder vs. Terminal distinction
    is counter-productive.

    There are two good answers to your question:

    1. Have separate executables for the CLI tool and the GUI app. They can both be
    inside the bundle, or you can install the CLI tool in user's path (similar to
    what BBEdit does).

    2. Have one executable and require an argument to be passed in to indicate
    command-line use. See
    /Developer/Applications/Utilities/PackageMaker.app/Contents/MacOS/PackageMaker
    -help for an example.

    hth

    meeroh

    --
    If this message helped you, consider buying an item
    from my wish list: <http://web.meeroh.org/wishlist>

    Miro Guest

  14. #14

    Default Re: application duality?

    Miro Jurisic wrote: 
    >
    >
    > Let me ask you a different question. What happens if I launch your app from
    > AppleScript? Which case would you want to execute? What if I launch it using
    > AppleScript from the command line? What if I use a 3rd parth launcher tool to do
    > it? What if I ssh in and launch it?
    >
    > There are many ways to launch your app besides Terminal and Finder and they are
    > impossible to distinguish. Focusing just on the Finder vs. Terminal distinction
    > is counter-productive.[/ref]

    I don't really believe so. To me it is now rather a single question
    left: Can I safely get to know that I was launched from the Finder? Even
    if I don't use it later on, I would like to know that.
     

    Yup. This one I discussed already.
     

    Adding just one more arg is not a problem, Besides, I already know what
    to do with the app. Just wanted to clear out the remaining question.

    TNX.

    Patryk Guest

  15. #15

    Default Re: application duality?

    In article <3fc27e02$inet.com.pl>,
    "Patryk 'Silver Dream !' ?ogiewa" <remove.it.pl> wrote:
     
    >
    > I don't really believe so. To me it is now rather a single question left: Can
    > I safely get to know that I was launched from the Finder? Even if I don't use
    > it later on, I would like to know that.[/ref]

    No, you can't.

    meeroh

    --
    If this message helped you, consider buying an item
    from my wish list: <http://web.meeroh.org/wishlist>

    Miro Guest

Similar Threads

  1. #38964 [Opn->Bgs]: Duality in treating variables.
    By iliaa@php.net in forum PHP Bugs
    Replies: 0
    Last Post: September 26th, 03:21 PM
  2. #38964 [NEW]: Duality in treating variables.
    By faust04 at o2 dot pl in forum PHP Bugs
    Replies: 0
    Last Post: September 26th, 03:20 PM
  3. Replies: 0
    Last Post: August 9th, 11:33 AM
  4. Replies: 2
    Last Post: August 7th, 07:13 AM
  5. Replies: 0
    Last Post: July 3rd, 08:58 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139