> On Mar 18, 2013, at 12:15 PM, Chris Tracewell wrote:
>
>> I have a main window which has a child/auxilary window. When the user
>> presses a button in the UI the main window controller inits the child,
>> assigns itself as the object for the child window's myOwner property and
>> then launche
On Mon, Mar 18, 2013, at 05:15 PM, Rick Mann wrote:
>
> On Mar 18, 2013, at 16:30 , Kyle Sluder wrote:
>
> > 2. NSCoding is not trustworthy. Your app must blindly trust any object
> > archive it loads. This is a significant security risk.
>
> I don't think that argument is any more true for wha
On Mar 18, 2013, at 5:15 PM, Rick Mann wrote:
>> 2. NSCoding is not trustworthy. Your app must blindly trust any object
>> archive it loads. This is a significant security risk.
>
> I don't think that argument is any more true for what I'm proposing than what
> what exists today.
Property lis
On Mar 18, 2013, at 5:14 PM, Rick Mann wrote:
> NSArchiver calls look like -setValue:forKey:, so it seems reasonable that the
> protocol could be usurped to write out fairly clean user defaults plists.
There’s a lot of other gunk the archiver needs to store so it can handle
pointer cycles and
On Mar 18, 2013, at 16:30 , Kyle Sluder wrote:
> 2. NSCoding is not trustworthy. Your app must blindly trust any object
> archive it loads. This is a significant security risk.
I don't think that argument is any more true for what I'm proposing than what
what exists today.
--
Rick
__
On Mar 18, 2013, at 16:46 , Jens Alfke wrote:
> It wouldn’t be human-readable. NSArchiver doesn’t produce readable output.
> Even if you made a version whose output was a tree of directories, it would
> still be pretty unreadable due to all the metadata in it. (After all, XML is
> “human-read
On Mar 18, 2013, at 4:21 PM, Rick Mann wrote:
> It seems like an NSArchiver subclass could call -encodeWithCoder: to create a
> dictionary that could live in a plist file (as opposed to creating an
> NSData), and it could easily be used transparently. The advantage to this is
> twofold: you a
I'm using NSUbiquitousKeyValueStore (KVS) to store some basic prefs for my app.
I always write to NSUserDefaults and iCloud each time I update things. As I was
building up my code, I was running into some issues getting the coding right,
so I ended up with data in NSUserDefaults (on local disk),
On 19/03/2013, at 10:21 AM, Rick Mann wrote:
> t seems like an NSArchiver subclass could call -encodeWithCoder: to create a
> dictionary that could live in a plist file (as opposed to creating an
> NSData), and it could easily be used transparently. The advantage to this is
> twofold: you avo
On Mon, Mar 18, 2013, at 04:07 PM, Rick Mann wrote:
> I'm a little bit surprised that I can't add my NSCoding-conforming object
> directly to NSUserDefaults. Why is this? Is it just a long-standing
> oversight of NSUserDefaults, or is there a technical reason why it
> doesn't work?
A couple possib
On Mar 18, 2013, at 16:17 , Graham Cox wrote:
> Because the defaults are stored as a plist, so the objects written there have
> to be property list objects. I agree, it's a bit annoying that this isn't
> handled transparently. You have to convert those objects to NSData, one way
> to do that
On 19/03/2013, at 10:07 AM, Rick Mann wrote:
> I'm a little bit surprised that I can't add my NSCoding-conforming object
> directly to NSUserDefaults. Why is this? Is it just a long-standing oversight
> of NSUserDefaults, or is there a technical reason why it doesn't work?
Because the defaul
I'm a little bit surprised that I can't add my NSCoding-conforming object
directly to NSUserDefaults. Why is this? Is it just a long-standing oversight
of NSUserDefaults, or is there a technical reason why it doesn't work?
--
Rick
___
Cocoa-dev m
On Mar 18, 2013, at 2:12 PM, Jean Suisse wrote:
>> Normally for shared preference or data you would write to a shared file in
>> /Library/Application Support/companyname/filename, but you have to take
>> special care if you're sandboxing your app.
>
> Indeed. It would seem this requires to be
> Normally for shared preference or data you would write to a shared file in
> /Library/Application Support/companyname/filename, but you have to take
> special care if you're sandboxing your app.
Indeed. It would seem this requires to be root.
> Never write into your application bundle. It wi
On Mar 18, 2013, at 1:46 PM, Sean McBride wrote:
> On Sat, 16 Mar 2013 11:14:55 +0100, Jean Suisse said:
>
>> According to you, what would be the best course of action ? Should I
>> write into my application's bundle ?
>
> Never write into your application bundle. It will fail in many cases, m
On Sat, 16 Mar 2013 11:14:55 +0100, Jean Suisse said:
>According to you, what would be the best course of action ? Should I
>write into my application's bundle ?
Never write into your application bundle. It will fail in many cases, most
notably: read-only file systems and App Sandbox.
Cheers,
On Mar 18, 2013, at 12:15 , Chris Tracewell wrote:
> I can't really include the parent header in the child window controller as it
> is included in the parent window controller.
You can, if you need to, since the #import mechanism prevents recursion.
However, it's unlikely you need to.
Leavin
On Mar 18, 2013, at 12:15 PM, Chris Tracewell wrote:
> I have a main window which has a child/auxilary window. When the user presses
> a button in the UI the main window controller inits the child, assigns itself
> as the object for the child window's myOwner property and then launches the
> ch
I have a main window which has a child/auxilary window. When the user presses a
button in the UI the main window controller inits the child, assigns itself as
the object for the child window's myOwner property and then launches the child
window as a modal via NSApp runModalForWindow. This worked
I guess Cocoa just likes me more. :-)
Thanks for the answers.
--
Seth Willits
On Mar 18, 2013, at 7:44 AM, Uli Kusterer wrote:
> Odd, my experience has been exactly the opposite. Unless I bind to
> NSUserDefaultsController, I don't get notified when other parts of my app
> change a default
Odd, my experience has been exactly the opposite. Unless I bind to
NSUserDefaultsController, I don't get notified when other parts of my app
change a default. So I guess the answer is: "It always breaks on Uli's work
Mac" :-)
Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere...
22 matches
Mail list logo