Send Cocoa-dev mailing list submissions to
email@hidden
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.apple.com/mailman/listinfo/cocoa-dev
or, via email, send a message with subject or body 'help' to
email@hidden
You can reach the person managing the list at
email@hidden
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Cocoa-dev digest..."
Today's Topics:
1. Re: Detecting that a process has ended? (Rick Mann)
2. Re: Detecting that a process has ended? (Greg Guerin)
3. Re: Programmatically Picking Elements (Pierce Freeman)
----------------------------------------------------------------------
Message: 1
Date: Sat, 27 Jun 2009 10:20:53 -0700
From: Rick Mann <email@hidden>
Subject: Re: Detecting that a process has ended?
To: Chris Suter <email@hidden>
Cc: "email@hidden" <email@hidden>
Message-ID: <email@hidden>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
On Jun 27, 2009, at 05:34:45, Chris Suter wrote:
On 27/06/2009, at 7:29 PM, Rick Mann <email@hidden> wrote:
I think it'll work very well. It's not a GUI process (although most
of the techniques in the TN support only processes in the current
context). In this case, the kqueues will do just fine.
Ah, sorry, I missed that one. Still, if it's your own code, it's
sometimes easier to use an IPC mechanism which was what I was trying
to say.
No worries. In answer to your earlier question, I don't control the
other code. Well, I do (it's open source), but I don't want to change
it. It's a complex Java servlet container.
--
Rick
------------------------------
Message: 2
Date: Sat, 27 Jun 2009 10:55:18 -0700
From: Greg Guerin <email@hidden>
Subject: Re: Detecting that a process has ended?
To: list-cocoa-dev <email@hidden>
Message-ID: <email@hidden>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Rick Mann wrote:
No worries. In answer to your earlier question, I don't control the
other code. Well, I do (it's open source), but I don't want to
change it. It's a complex Java servlet container.
A "tender" process might work. Instead of spawning the target
process directly, you spawn a tender whose sole job is to spawn the
target process and wait for it to die, then communicate that event
back to your initiating process in whatever way you want. The tender
is written and controlled entirely by you, so you can have it perform
whatever actions you want: IPC, distributed notification, etc.
The /usr/bin/time command is somewhat like this, in that it runs
another command with the purpose of reporting the child's execution
time. The bash shell also has a builtin 'time' command.
-- GG
------------------------------
Message: 3
Date: Sat, 27 Jun 2009 11:17:12 -0700
From: Pierce Freeman <email@hidden>
Subject: Re: Programmatically Picking Elements
To: Kyle Sluder <email@hidden>, Cocoa-Dev List
<email@hidden>
Message-ID: <C66BB038.10D0E%email@hidden>
Content-Type: text/plain; charset="US-ASCII"
Hey Kyle:
Thanks for your reply... I looks like that took a lot of time to
type. ;)
Ah. Please do re-read the documentation, as it will at the very
least
better inform your vocabulary. An "outlet" is a property or instance
variable that has been tagged with the IBOutlet macro and as such is
available for wiring in Interface Builder. For example, the
nextResponder outlet on instance of NSResponder. Objects themselves
cannot be outlets.
The term you're looking for is "View." Read the View Programming
Guide, especially the section on the View Hierarchy. Everything
contained in a window is a view. Views draw themselves in response
to
-drawRect: (sometimes using helper objects like instances of NSCell).
Views can also contain other views.
I suppose that's what I get from constantly switching between web
programming and Cocoa programming. Sometimes it takes a few days to
fully
switch mindsets - Which my clients don't seem to be too willing to
give me.
First off, only tackle this if you are incredibly comfortable with
the
view hierarchy and Cocoa in general. You're going to need to
understand a lot about how views work, much more than just playing
around with IB will tell you.
Unfortunately, I kind of figured this... Most of the complex things
aren't
easy. Yes, obviously, as they are considered complex. ;)
Secondly, you're going to need a very sharp delineation between your
business-side concept of a user interface and the Cocoa concept of a
user interface. Your business terms, for example, might include
things such as "List of People" or "Expense Report." Your Cocoa
terms
are things like NSTableView and NSTextFieldCell. Your biggest
challenge is going to be drawing the line between these two things,
and sometimes it's very difficult to say what is a business
requirement and what is an implementation detail. You're only ready
to make these distinctions when you've had quite a bit of experience
with the framework.
Third, don't expect to implement a web-based Interface Builder. You
will set yourself up for failure quite quickly. Resist the
temptation
to offer your users a generic table in which they can create columns,
bind controls to business objects, etc. There's a tool that does
that
already, and its name is Interface Builder. It sounds like you're
developing an internal application -- despite the fact that this
setup
allows for greater communication and faster turnaround between the
developers and the customers, too often developers (myself included)
have taken a very release-oriented attitude. You don't need to
make a
super-generic tool that your customers can use to implement their
dream interface. You have the convenience of proximity, which means
the customer can walk down the hall and say: "We need a window that
looks like X so we can do Y." Those of us in the consumer software
market would kill for this kind of customer interactivity. Besides,
do your customers really want to learn how to make an interface?
They've got more important things to do!
I feel really bad about typing this next part as it looks like that
took a
LOT of time to write. When I said "more going for" I more meant the
following:
A user logs on to a web application. They have some options for
filing a
web report. Choices: single line and multiple line. They can choose
how
many of these fields they have for various variables that they want to
input. This is then saved in a MYSQL database for later use.
The client side application fetches the data in the MYSQL databases
and then
displays it. The problem is that it is a variable number of fields
and a
variable number of types.
So, it's technically not a online Interface Builder - I think I'll
let the
capable guys at 280 North handle that. It's more a dynamic online
tool,
which I think may require a lot of the same tools. But I'll let more
experienced people (you) tell me if I'm totally wrong on that.
In short, don't try to obsolete yourself. You will wind up with
happier customers if you accept your limitations and they accept
theirs. Take advantage of your situation: iterate frequently, be
responsive to customer needs, and don't be afraid to say "no" to
crazy
requirements proposals -- including your own.
That's very good advice, especially with dealing with some of my
clients.
One wants some fading elements, noises, complete dynamic... On the
web. Just
Wow.
Once again, thanks for all your help.
Sincerely,
Pierce Freeman
------------------------------
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins (at) lists.apple.com
http://lists.apple.com/mailman/listinfo/cocoa-dev
End of Cocoa-dev Digest, Vol 6, Issue 941
*****************************************