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: launchd detecting when an application is running (Greg
Guerin)
2. Re: Touchscreens and control scaling (Michael Ash)
3. Re: KVO and master-detail NSTableViews (Ken Thomases)
4. Re: Help with SHA class (Greg Guerin)
----------------------------------------------------------------------
Message: 1
Date: Thu, 4 Jun 2009 09:51:04 -0700
From: Greg Guerin <email@hidden>
Subject: Re: launchd detecting when an application is running
To: list-cocoa-dev <email@hidden>
Message-ID: <email@hidden>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Tom Hohensee wrote:
I have written an application that I would like to launch whenever
a certain app is launched. I have used LaunchAgents in the past to
detect events such as USB insertion and volume mounting to perform
certain actions. I was wondering if there was a launchd.plist key
that allowed for launchd to detect an application startup.
Is this for distribution, or only for your personal use?
How soon after the original app launches do you need to start the
secondary app?
How much control do you have over the original app?
Can you replace the original app's existing executable with another
one that triggers your secondary app, then goes on to exec the
original executable? The trigger could be many things, including
something that launchd monitors (see 'man launchd.plist' for on-
demand conditions).
Maybe run a daemon that monitors FSEvents for creation of a temp-file
you know the original app will create.
Maybe on-demand monitor the original app's user-defaults, so launchd
triggers that way.
Those are just some random ideas. It might help if you described
exactly what you're trying to accomplish, including what the original
app is. Describe the problem; don't propose a solution. If you've
already tried something, tell us what you've tried and exactly why it
didn't work. Be specific.
-- GG
------------------------------
Message: 2
Date: Thu, 4 Jun 2009 13:01:58 -0400
From: Michael Ash <email@hidden>
Subject: Re: Touchscreens and control scaling
To: cocoa-dev <email@hidden>
Message-ID:
<email@hidden>
Content-Type: text/plain; charset=UTF-8
On Thu, Jun 4, 2009 at 3:44 AM, Ben <email@hidden>
wrote:
Hi list,
I've been sketching out an application and could do with a little
advice on
which cocoa-direction to take. It's a full-screen (kiosk) type app,
running
in a very controlled environment (not for wide release) but which
would run
on an external touchscreen monitor.
While I can make buttons and labels big enough for fingers to poke,
I'm
concerned about controls like table headers and scrollers being
large enough
to make finger-size targets. I'm asking sooner rather than after
testing the
usability in case there are special considerations I should take
before
writing the first lines of code.
The only options I can think of are:
1. Make a normal app and use quartz debug to scale *everything* up
2. Subclass and/or redraw any controls too small for finger taps
3. Shut up and try it out first
There is also option 3: set the scaling of your window's content view
(or some other convenient superview) to scale everything it contains
up.
This is capability has been around forever and so is probably better
supported than the quartz debug option.
Mike
------------------------------
Message: 3
Date: Thu, 4 Jun 2009 12:07:37 -0500
From: Ken Thomases <email@hidden>
Subject: Re: KVO and master-detail NSTableViews
To: Stefan Reitshamer <email@hidden>
Cc: email@hidden
Message-ID: <email@hidden>
Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes
On Jun 4, 2009, at 5:24 AM, Stefan Reitshamer wrote:
I'm getting flaky behavior from my KVO code and I'm wondering what
I'm doing wrong. I can't find any similar examples.
I have a pop-up button and 2 NSTableViews.
The pop-up button selection controls the content of the left
NSTableView. The left NSTableView's selection controls the content
of the right NSTableView.
The pop-up button and NSTableViews are bound to separate
NSArrayControllers.
Each NSArrayController is bound to a separate NSMutableArray
property in my app controller.
My app controller observes "selectionIndex" in the pop-up button's
NSArrayController and "selectedObjects" in the left
NSArrayController.
I think you're manually using KVO when you could (and perhaps should)
be using bindings. I also think you're setting up the observations in
the wrong direction. I wouldn't have the app controller observe
properties of the array controller. Mediating controllers should bind
to (thus, implicitly observe and set) properties of the coordinating
controller (or the model, reached through the coordinating
controller).
First, I don't know if you need the array controller for the pop-up to
manage the selection. I think you should bind the pop-up's
selectedObject to a (possibly new) property on the app controller.
This may require use of both the content and contentObjects bindings
of the pop-up to get selectedObject to be an appropriate object.
Second, I think the array controller for the left table would bind to
or through this property (the one bound to the pop-up's selection) on
the app controller.
Lastly, the array controller for the right table would bind through
the selection property of the array controller for the left table.
Put another way, bindings are meant to reduce or eliminate glue code.
You seem to be reproducing the sort of glue code that one would
typically have in the pre-bindings days, just using KVO (and maybe
bindings themselves) to trigger the glue code.
Regards,
Ken
------------------------------
Message: 4
Date: Thu, 4 Jun 2009 10:35:02 -0700
From: Greg Guerin <email@hidden>
Subject: Re: Help with SHA class
To: list-cocoa-dev <email@hidden>
Message-ID: <email@hidden>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
I wrote a SHA class using the algorithm at http://en.wikipedia.org/
wiki/SHA1#SHA-1_pseudocode and while it runs without crashing, the
hashes it produces are not the same as those from numerous online
SHA-1 hashing converters. Of particular confusion is the issue of
byte swapping and how that might affect the rotation/addition
operations within the block hashing method. I'm clearly doing
something wrong, but after several days of trying, I haven't been
able to get the hashes to match online examples.
Why are you writing this algorithm?
Googling these keywords:
sha1 public domain
shows numerous hits. Since "public domain" means "no license", I
don't see why you'd want to reinvent this wheel, especially given the
known weaknesses of SHA1.
If you're writing it in order to learn about hash algorithms, then I
think it makes more sense for you to debug your code yourself, as
unhelpful as that may seem to be. I also suggest reading sources
other than Wikipedia, not necessarily because Wikipedia might be
wrong or have a typo, but because there might be more detailed step-
by-step explanations elsewhere on the web. Or look at the public
domain ones and see how they differ from yours.
You might also try running your code on a machine that's actually big-
endian, to see what happens. Unless you already are.
Iff you're running it on an Intel CPU, simply compile the code for
ppc and use the 'arch' command to run that slice instead of the
native slice. If it doesn't produce the same output, then you have
an implied-endian bug. If it does produce the same output, you still
have a bug.
If you're using an Intel CPU, maybe try finding a little-endian
implementation of the algorithm.
BTW, your code should probably be using the type names UInt32 and
UInt64, instead of making assumptions about sizes. There are also
places where you use the constant 4 instead of sizeof(UInt32).
Though these may not affect this implementation, they seem
questionable to me.
-- GG
------------------------------
_______________________________________________
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 831
*****************************************