Re: Cocoa Sounds
What I've done in the past is to simply play a silent sound before I actually need to play a sound for real. This "primes the pump". _murat On Nov 9, 2009, at 11:40 AM, lbland wrote: > hi- > > On Nov 9, 2009, at 12:58 PM, Chunk 1978 wrote: > >> one thing i've always had an issue with is sound lag, which always >> (yet only) happens during a first sound. after the initial lag, >> sounds will play on time. at first i though it was my code, but >> recently i've noticed that it happens in Calculator. >> >> if you open Calculator, then choose Speech > Speak Button Pressed, >> you'll notice a lag when you first press a button. >> >> how is it possible to avoid this? are there other 3rd frameworks for >> sound that would be more ideal to use other than what's available in >> cocoa? > > It happens in our Cocoa apps. It also happens with the Apple Mail app. > > Click "Get Mail" and after Activity stops and 4 seconds later there is the > beep. > > This is on Mac OS X 10.6.1 and the latest and fully loaded MacBook Pro > computers. > > So, I think the lag is simply what you get. > > ... the good news is that other people have the problem. The bad news is: > since reading this post (and the one a few days ago) every time I check my > mail I now notice that the sound really lags! > > thanks!- > > -lance > > ___ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/cocoa-dev/mlist0987%40gmail.com > > This email sent to mlist0...@gmail.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
CoreImage on threads?
I'm trying to use run multiple CoreImage operations concurrently using NSOperation. Sometimes it works, sometimes it doesn't. Smells like what you'd get when trying to run multiple operations that are not thread safe. Before I dig in much deeper, am I wrong that running multiple concurrent CoreImage operations is even supported? I wasn't able find any documentation on the subject one way or the other, but it seems odd that it shouldn't be supported. _murat___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: CoreImage on threads?
Just to be clear, it works great for me off the main thread. The problem I have is when I have multiple CoreImage operations on separate threads. _murat On Mar 21, 2010, at 9:30 AM, Jeff Johnson wrote: > In my experience, CoreImage is not thread safe. I could probably dig up the > details if necessary, but the gist is that we were experiencing > CoreImage-related crashes when running off the main thread. Moving to the > main thread fixed the crashes. > > Unfortunately, I'm not aware of any documentation regarding CoreImage thread > safety. > > -Jeff > > > On Mar 20, 2010, at 4:36 PM, mlist0...@gmail.com wrote: > >> I'm trying to use run multiple CoreImage operations concurrently using >> NSOperation. Sometimes it works, sometimes it doesn't. Smells like what >> you'd get when trying to run multiple operations that are not thread safe. >> >> Before I dig in much deeper, am I wrong that running multiple concurrent >> CoreImage operations is even supported? I wasn't able find any documentation >> on the subject one way or the other, but it seems odd that it shouldn't be >> supported. >> >> _murat___ > ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: iPad Programming Tutorial
On Apr 25, 2010, at 7:01 PM, ML wrote: > Does anyone know of a resource that helps understand how to NOT use interface > builder for developing applications? Some variant of this question pops up here every now and then. Quoting from a post of my own: "Interface Builder is a fundamental part of Cocoa development, not simply a shortcut for newbies or a way to get started quickly. Anyone who thinks developing without Interface Builder is a purer path to Cocoa development has already missed the point." _murat___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Key equivalents for non-menu items
On Feb 15, 2011, at 7:36 PM, Randy Widell wrote: > I would like to have a keyboard shortcut that tags a location on the > waveforms at the location of the mouse cursor. These commands do not make > any sense in the main menu...they could go there, but they would be clutter. Why do you think they wouldn't make sense in the main menu? That's where we put them in SoundEdit 16. A design point: you should not have any operations that can't be invoked using a mouse. So you should have a button or menu for these commands of yours. _murat___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Trouble with design pattern
Sorry, the forward declarations go in your .h files. You still have to import your MyDocument.h in your implementation files (ie. your CustomView.m files). What warnings are you getting? As far as your nil document problem, I don't know. I suspect something is not setup correctly. In your code fragment [[[self window] windowController] document]] you're making three calls, any of which might be returning nil. Which is it? _murat On Feb 18, 2011, at 2:22 PM, Carlos Eduardo Mello wrote: > Thanks for the tip. > > I've just tried your suggestion: placed the forward declarations in the > custom view files and declared instances of the MyDocument type. I checked > all the details and tested several times, but the compilers still give me the > same warnings, and now there is a nother problem: > > [[[self window] windowController] document]] doesn't seem to be garanteed to > return something other than nil at [awakeFromNib]. > > Is there some other point in the document intializing cycle where I could put > that call so I can store it for repeated use during app's execution? ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why does NSArray count return NSUInteger?
Maybe array indexes and counts are unsigned because you can't have a negative
number of objects in an array?
_murat
On May 29, 2011, at 1:04 PM, julius wrote:
> Hi,
> I have just spent time investigating why
> an if statement involving an [array count] was apparently misbehaving.
>
> The construct was this:
> if(3 < ([zAry count] - 10))
> It delivers a (to me unexpected) result when [zAry count] < 10.
>
> In fact
> if(3 >= ([zAry count] - 10))
> also returns an unexpected result for the same [zAry count] value.
>
> The reason is that [zAry count] returns a result of type NSUInteger
>
> Thus for this type of comparison I need to coerce the type to NSInteger i.e.
> if(3 < ((NSInteger)[zAry count] - 10))
>
>
> Why might the Cocoa developers have chosen to do this?
> Julius
>
>
> ==
> Here to satisfy possible curiosity is my test code snippet and results
> NSMutableArray * zAry = [[NSMutableArray alloc]init];
> for(NSInteger i = 0; i < 7; i++) {
> [zAry addObject:@"obj"];
> }
>
> NSLog(@"[zAry count] = %d",[zAry count]);
>
> if(3 < ([zAry count] - 9)) {
> NSLog(@"A1: wrong result for: 3 < %d",([zAry count] - 9));
> } else {
> NSLog(@"A2: correct result for: 3 < %d",([zAry count] - 9));
> }
>
> if(3 >= ([zAry count] - 9)) {
> NSLog(@"B1: correct result for: 3 >= %d",([zAry count] - 9));
> } else {
> NSLog(@"B2: wrong result for: 3 >= %d",([zAry count] - 9));
> }
>
> NSInteger zAryCount = [zAry count];
> if(3 < (zAryCount - 10)) {
> NSLog(@"C1: wrong result for: 3 < %d",(zAryCount - 9));
> } else {
> NSLog(@"C2: correct result for: 3 < %d",(zAryCount - 9));
> }
>
> NSUInteger zUInt = 7;
> if (3 < (zUInt - 9)) {
> NSLog(@"E1: wrong result for: 3 < %d",(zUInt - 9));
> } else {
> NSLog(@"E2: correct result for: 3 < %d",(zUInt - 9));
> }
>
> // these produce the required result
> if(3 < ((NSInteger)[zAry count] - 9)) {
> NSLog(@"F1: wrong result for: 3 < %d",([zAry count] - 9));
> } else {
> NSLog(@"F2: correct result for: 3 < %d",([zAry count] - 9));
> }
>
> if(3 >= ((NSInteger)[zAry count] - 9)) {
> NSLog(@"G1: correct result for: 3 >= %d",([zAry count] - 9));
> } else {
> NSLog(@"G2: wrong result for: 3 >= %d",([zAry count] - 9));
> }
>
> 2011-05-29 20:41:19.107 TestIf[4858:903] [zAry count] = 7
> 2011-05-29 20:41:19.110 TestIf[4858:903] A1: wrong result for: 3 < -2
> 2011-05-29 20:41:19.110 TestIf[4858:903] B2: wrong result for: 3 >= -2
> 2011-05-29 20:41:19.111 TestIf[4858:903] C2: correct result for: 3 < -2
> 2011-05-29 20:41:19.111 TestIf[4858:903] E1: wrong result for: 3 < -2
> 2011-05-29 20:41:19.111 TestIf[4858:903] F2: correct result for: 3 < -2
> 2011-05-29 20:41:19.112 TestIf[4858:903] G1: correct result for: 3 >= -2
>
>
> http://juliuspaintings.co.uk
>
>
>
> ___
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/mlist0987%40gmail.com
>
> This email sent to mlist0...@gmail.com
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Why does NSArray count return NSUInteger?
Maybe this will assuage your outrage (excuse the lame programmer poetry): If you were to look at the apis for NSArray and see that indices are signed integers, you could reasonably conclude that storing/retrieving an object from a negative index is a legitimate thing to do. That would maybe be a fun capability, but then it raises questions like is the array zero-based or what? Etc. Starting to make more sense? _murat On May 30, 2011, at 2:10 PM, julius wrote: > > On 30 May 2011, at 21:56, Dave Zarzycki wrote: > >> On May 30, 2011, at 1:45 PM, julius wrote: >> >>> >>> On 30 May 2011, at 20:03,Quincey Morris wrote >>>> >>>> On May 30, 2011, at 08:27, julius wrote: >>>> >>>>> All I had hoped was that someone on this list might illuminate the issue >>>>> more than has happened so far. >>>> >>>> The problem isn't really lack of illumination, but that you're not >>>> prepared to accept the consequences of the explanation. >>> >>> Hilarity and riot. >>> >>>> >>>> Here's my version of the illumination: >>>> >>> snip >>>> -- It at least theoretically provides opportunities for compile-type (== >>>> better) error messages if you accidentally pass a value of the wrong type. >>>> >>>> -- It at least theoretically eliminates the need to code some range >>>> validation checks. >>>> >>> >>> Here is a nice instance that I think quite germane. >>> >>> The input parameter to NSArray's objectAtIndex: is an NSUInteger. >>> Both these code snippets work perfectly (they retrieve element 3). >>> zStr = [zAry objectAtIndex:3.1]; >>> and >>> CGFloat zF1 = 3.2; >>> zStr = [zAry objectAtIndex:zF1]; >>> >>> I'm sure that by setting the right flags one could get warning messages to >>> appear. >> >> >> Julius, >> >> As others have pointed out, this has nothing to do with Objective-C or Cocoa. > > NSArray and its count method has nothing to do with Cocoa? > > > I'm off to save a few sheep off the Antrim coast. > > Julius > > > http://juliuspaintings.co.uk > > > > ___ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/cocoa-dev/mlist0987%40gmail.com > > This email sent to mlist0...@gmail.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Cocoa Touch: Accessory view never calls "up outside" action?
I'm using a UIButton subclass as an accessory view in a table cell. I create
the button in my cell's initWithStyle:reuseIdentifier: method, as shown below.
Here's the problem: I touch inside my button, but even when I drag my finger
out of the button and lift up, it's my "up inside" action that gets called, not
my "up outside" action as I expect.
Puzzling.
Any help appreciated.
_murat
- (id)initWithStyle:(UITableViewCellStyle)style reuseIdentifier:(NSString
*)reuseIdentifier
{
self = [super initWithStyle:style reuseIdentifier:reuseIdentifier];
if (self)
{
self.accessoryView = [[[CustomButton alloc] initWithFrame:CGRectMake(0,
0, 40, 10)]autorelease];
[(UIControl*) self.accessoryView
addTarget: self
action: @selector(inside:forEvent:)
forControlEvents: UIControlEventTouchUpInside];
[(UIControl*) self.accessoryView
addTarget: self
action: @selector(outside:forEvent:)
forControlEvents: UIControlEventTouchUpOutside];
}
return self;
}
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: How to get an italic font
Is there some reason you can't use -[NSFontManager convertFont:toHaveTrait:] ?
It "returns a font whose traits are the same as those of the given font, except
that the traits are changed to include the single specified trait."
So something like:
NSFont* myFont = [your code here];
NSFont* myItalicFont = [[NSFontManager sharedFontManager] convertFont:myFont
toHaveTrait:NSItalicFontMask];
_murat
On Dec 3, 2009, at 11:15 PM, Gerriet M. Denkmann wrote:
> I want an italic font corresponding to an existing font.
>
> I tried:
>
> NSFontDescriptor *fd1 = [ NSFontDescriptor fontDescriptorWithName:
> @"Times" size: textFontSize ];
> NSLog(@"%s text NSFontDescriptor %@",__FUNCTION__, fd1);
> // NSFontNameAttribute = Times; NSFontSizeAttribute = 16;
>
> fontText = [ NSFont fontWithDescriptor: fd1 size: textFontSize ];
> NSLog(@"%s text NSFont %@",__FUNCTION__, fontText);
> // "Times-Roman 16.00 pt. P [] (0x1190e0f90) fobj=0x1190e0590,
> spc=4.00"
>
> So far so good.
>
> Now I try to make the italic variant:
> NSFontSymbolicTraits symbolicTraits = NSFontItalicTrait;
> NSFontDescriptor *fdi = [ fd1 fontDescriptorWithSymbolicTraits:
> symbolicTraits ];
> NSLog(@"%s italic NSFontDescriptor %@",__FUNCTION__, fdi);
> // NSCTFontTraitsAttribute = { NSCTFontSymbolicTrait = 1; };
> NSFontSizeAttribute = 16;
> Note: NSFontNameAttribute has disappeared
> The documentation says: "Returns a new font descriptor that is the same as
> the receiver but with the specified symbolic traits taking precedence over
> the existing ones."
>
> italicText = [ NSFont fontWithDescriptor: fdi size: textFontSize ];
> NSLog(@"%s italic NSFont %@",__FUNCTION__, italicText);
> // "LucidaGrande 16.00 pt. P [] (0x1190e0f90) fobj=0x10046adb0,
> spc=5.06"
>
> This is comple nonsense: Lucida Grande is not italic and does not have an
> italic variant (only normal and bold).
>
> I would have expected something like Times-Italic.
>
> So: how to get an italic variant to a given font without hardcoding font
> names?
>
>
> Kind regards,
>
> Gerriet.
>
> ___
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/mlist0987%40gmail.com
>
> This email sent to mlist0...@gmail.com
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Undo Names in NSPersistentDocument
On Dec 18, 2009, at 8:39 PM, Graham Cox wrote: (regarding undo action names when using NSPersistentDocument) > Unfortunately I haven't used Core Data so I'm not sure what's needed to fit > in with that, if the framework hasn't already solved it. As near as I can tell, 5 years after Core Data's appearance, action names for undo is still a "roll your own" proposition if you're using Core Data and bindings. I'd love to be proved wrong on this, or pointed to solutions coded by others, but my Googling hasn't un-earthed anything yet... _murat___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: rightMouseDown not working as documented?
On Jan 22, 2010, at 4:20 PM, Corbin Dunn wrote: > Please log a bug requesting our documentation to clarify this, or asking us > to change the behavior if you were expecting something else. Radar 7573344 _murat___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Workaround [Re: NSTextView refuses to scroll inside of an NSCollectionView]
For the archives-
I ran into the problem where NSScrollviews from an NSCollectionViewItem's
template view do not work properly in a collection view. This is a problem that
was reported on this list back in 2007, and reported as a bug then, but is
still broken in 10.6.2. I couldn't find a solution online so crafted one of my
own.
My gift to future coders who run into this problem:
@interface CBScrollView:NSScrollview
{
}
@end
@implementation CBScrollView
- (void) fixScrollerTargets
{
if ([self verticalScroller] && [[self verticalScroller] target] != self)
{
[[self verticalScroller] setTarget:self];
}
if ([self horizontalScroller] && [[self horizontalScroller] target] != self)
{
[[self horizontalScroller] setTarget:self];
}
}
- (id)initWithCoder:(NSCoder *)decoder
{
if (self = [super initWithCoder:decoder])
{
[self performSelector:@selector(fixScrollerTargets) withObject:nil
afterDelay:0];
}
return self;
}
- (void) dealloc
{
[NSObject cancelPreviousPerformRequestsWithTarget:self
selector:@selector(fixScrollerTargets)
object:nil];
[super dealloc];
}
@end
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Set the Cursor Position
Some audio software does a similar thing for adjusting on screen knobs. I much un-love it. _murat On Aug 19, 2010, at 6:43 PM, Sherm Pendley wrote: > One such exception would be 2d or 3d graphics apps, where it's > expected to have a tool that allows the user to click and drag to > scale or rotate an object. When such a tool is active, one might > respond to drag events by modifying the model to match the mouse > movement, then warping the cursor back to its original position. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
NSFileWrapper serializedRepresentation bloat?
I create an NSFileWrapper for a directory hierarchy like this (all items are directories, no files): test-dir/ test-dir/inner-dir-a test-dir/inner-dir-b test-dir/inner-dir-c The wrapper's serialized representation weighs in at around an astounding 1mB (1,022,234 bytes)! Seems that the overhead per folder is around 300kB. Can that be right? Code: NSURL* url = [NSURL fileURLWithPath:@"/User/foo/Desktop/test-dir"]; NSFileWrapper w = [[NSFileWrapper alloc] initWithURL:url options:0 error:nil]; NSData* data = [w serializedRepresentation]; NSLog(@"%d", [data length]); _murat ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSFileWrapper serializedRepresentation bloat?
Problem ID: 8840391 _murat On Jan 8, 2011, at 7:55 PM, Ken Ferry wrote: > Hi, > > That's what I see too. From inspecting the serialized rep, it looks like > it's icon data. > > Since at least in my test case the folders did not have custom icons, it > seems like one could do better. Could you file a bug please? > > -Ken > Cocoa Frameworks > > On Sat, Jan 8, 2011 at 5:16 PM, mlist0...@gmail.com > wrote: > I create an NSFileWrapper for a directory hierarchy like this (all items are > directories, no files): > > test-dir/ > test-dir/inner-dir-a > test-dir/inner-dir-b > test-dir/inner-dir-c > > The wrapper's serialized representation weighs in at around an astounding 1mB > (1,022,234 bytes)! > > Seems that the overhead per folder is around 300kB. Can that be right? > > Code: > > NSURL* url = [NSURL fileURLWithPath:@"/User/foo/Desktop/test-dir"]; > NSFileWrapper w = [[NSFileWrapper alloc] initWithURL:url options:0 > error:nil]; > > NSData* data = [w serializedRepresentation]; > > NSLog(@"%d", [data length]); > > > _murat ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Help on Cocoa Class references
On Jan 18, 2011, at 2:46 AM, Leanne Attard wrote: > When i click on the title bar… You don't normally handle titlebar clicks yourself. What are you trying to do with click on the titlebar? _murat___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Using NSWindow without NIB (XIB) file ?
This should be a FAQ. The topic of Cocoa without Interface Builder comes up on the list surprisingly frequently, usually from someone who, like you, is "trying to understand how Cocoa really works". You may be thinking that graphical UI builders (like Interface Builder) are somehow a crutch and a barrier to understanding. That might be the case for other environments, but Interface Builder is a integral part of Cocoa Application development, not a shortcut for newbies. Which is to say, if you think bypassing Interface Builder is a purer path to app development, you have already missed the point. But to answer your question, yes, it is possible to create an NSWindow (or any other UI element) programmatically. _murat On Jan 25, 2011, at 2:48 AM, David Remacle wrote: > Hello > > Is it possible to use NSWindow without NIB file ? > > I can compile terminal application without using Xcode (by using gcc > -framework Foundation files -o progname) but how do that with a gui > application with Nib file ? > > It's just for understand how xcode compile the application with nib file > and obtain an .app file. > > Is there a note in the documentation that explain ? ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Minimal document-based app
What Fritz said. Unlike other graphical UI layout tools, Interface Builder is central to Cocoa development, not simply a shortcut for newbies or a way to get started quickly. Anyone who thinks developing without Interface Builder is a purer path to understanding Cocoa has already missed the point. _murat On May 1, 2012, at 7:50 AM, Fritz Anderson wrote: > On 1 May 2012, at 2:28 AM, ecir hana wrote: > >> If nothing else, it would explain to me how things works, 20 lines of >> code would help me better than 20 documentation pages. There tutorials >> above certainly did the explaining very well. > > Every few months, a beginner comes who wants to skip NIBs to "see how it > works." Please understand why experienced developers advise against this, > even though they understand the impulse. > > NIBs _are_ how it works. They don't contain or generate code. They don't > contain or generate scripts. They don't exercise much of the API you're > trying to use. They contain archived objects and their connections. > > Their effects can (often) be mimicked in code, but by the same token, > Objective-C can be mimicked in assembly. It is useful to understand a bit of > assembly when you use a high-level language, but except in special > circumstances, nobody advocates writing programs in it. And in the case of > compiling Objective-C, at least the translation passes (notionally) through > assembly code. > > Similarly, it is useful to understand how NIBs are reconstituted into > objects, but one must understand that the underlying mechanism is > reconstitution, not executing code that simulates reconstitution. Unlike the > translation of a high-level language, there is no executable layer through > which reconstitution passes. (At least in the sense you mean.) > > NOTE: On iOS, it is frequently useful to build object hierarchies in code, > but the Cocoa Touch API is designed to make that easy. Even there, most > designs take the form of reconstituting objects from NIBs. > > — F > > > ___ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/mlist0987%40gmail.com > > This email sent to mlist0...@gmail.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
multi-window document best practices?
I've have come across some surprising behavior when trying to implement a
document with two windows, each loaded from its own nib.
In my NSDocument subclass, I have
- (void) makeWindowControllers
{
NSWindowController* wc1 = [[[NSWindowController alloc]
initWithWindowNibName:@"MNKDocument" owner:self]autorelease];
[self addWindowController:wc1];
[wc1 window]; // loads nib the first time it's called.
NSLog(@"wc1->window = %@", [wc1 window]);
NSWindowController* wc2 = [[[NSWindowController alloc]
initWithWindowNibName:@"MNKDocumentSecondWindow" owner:self] autorelease];
[self addWindowController:wc2];
[wc2 window]; // loads nib the first time it's called.
NSLog(@"wc2->window = %@", [wc2 window]);
}
wc1 is loading the default nib provided by Xcode's document-based app template.
wc2 is loading a nib I made by simply duplicating the default nib.
The "File's Owner" in both nibs is my document subclass. In the first nib file,
the "File's Owner" has its "window" outlet connected to the window in the nib.
Pretty vanilla.
In the second nib, the File Owner's "window" outlet is disconnected. The window
in the second nib is connected to the file owner's "secondWindow" outlet.
After the nibs are loaded, I can see in the debugger that wc1->window points to
the correct window, but wc2->window is nil. WTF?
By experimenting, I have discovered that inside -[NSWindowController window],
there is some magic happening. If owner->window is pointing at the window being
loaded, the window controller's window member gets properly set. Otherwise, it
does not.
That seems wrong, or at least very unexpected. And undocumented.
Can anyone explain what's going on and why? And what the "right" way to do
multiple windowed docs is?
_murat
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: multi-window document best practices?
On May 12, 2012, at 4:45 PM, Kyle Sluder wrote: > Document-as-File's-Owner only makes sense if you aren't overriding > -makeWindowControllers. I don't think that's the case. Certainly nothing in the docs suggest it. Went for a drive and reflected on this a bit. I think the fact that there's a setter for NSDocument's 'window' member but not a getter, and that the underlying _window member is private should have been clues. Furthermore, the documentation for setWindow: suggests that it has a role in the nib loading mechanism. So I think my mistake was setting the window outlet in one nib but not the other. My approach was thwarting the very mechanism on which I was depending. _murat ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: multi-window document best practices?
On May 12, 2012, at 5:55 PM, Kyle Sluder wrote: > You are correct that nothing in the docs prohibits passing the document as > the file's owner argument for window controllers you construct yourself. And > in the case of a single window controller, it might work—though this is not > guaranteed. Huh. In NSDocument.h, it is written "The default implementation of (makeWindowControllers) ... creates a new window controller ..., specifying this document as the nib file's owner..." Presumably, Apple is telling us this so we know how to do it ourselves. If this is a pattern we ought not emulate, this would be an ideal place to mention that. > But if you have two or more window controllers, and you need to set the > window for each of them, then clearly the document's window property is not > the appropriate place for this. It's not at all clear. > And it will result in multiple -awakeFomNib: messages being sent to your > NSDocument. Heh, assuming awakeFromNib will only ever be called once is a newbie mistake I've made more than once ;) I presume you meant windowControllerDidLoadNib: not awakeFromNib. I would *expect* multiple windowControllerDidLoadNib: calls, once for each nib loaded. That's perhaps why windowControllerDidLoadNib: has a windowController arg; so you can know which nib is being loaded and act appropriately. > The document-loads-nib pattern is explicitly documented as a convenience > wrapper around creating your own NSWindowController instance. Yes, it is convenient. > The window outlet on NSDocument exists solely for the purpose of supporting > this convenience. I don't think so. I think it's there to support the convenience of having the nib's file's owner be the document, just like it is in the single window case. If it were important that nibs should be built differently for single and multiple window cases, I'd think the docs would mention it someplace, but they don't. _murat ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: multi-window document best practices?
On May 13, 2012, at 3:07 PM, Willeke wrote: > How to Subclass NSWindowController: The NSWindowController subclass instance > should be the File’s Owner for the nib... Thank you. I missed this, probably because I'm not actually subclassing NSWindowController. But it settles it as far as I'm concerned. _murat ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
_updateTrackingAreas really slow
I have an NSCollectionView with really simple (i.e. no tracking areas) item views. In a test case of about 1500 items, scrolling gets unacceptably choppy. I've tracked this down to calls to a private method, -[NSView _updateTrackingAreas]. While scrolling, _updateTrackingAreas is called for my item views each time they move a few pixels, even though they have no tracking areas. _updateTrackingAreas in turn calls -[NSNotificationCenter postNotificationName:object:userInfo:], which is what is actually taking up all the time. Stubbing out _updateTrackingAreas improves the scrolling dramatically, but I'd like to find a sanctioned way to at least delay the recalculation of tracking areas until scrolling is done. Any pointers? _murat ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
trackingAreas can be snuck up on without triggering?
I have a view for which I am adding a tracking area so that I can update the
cursor. The view entirely fills my window and is the only view in the window's
content view.
The tracking area is being registered thusly:
- (void) awakeFromNib
{
NSTrackingArea* trackingArea = [[NSTrackingArea alloc ] initWithRect:[self
bounds]
options:NSTrackingCursorUpdate|NSTrackingActiveInActiveApp
owner:self
userInfo:nil];
[self addTrackingArea:trackingArea];
}
and I have defined in my view:
- (void) cursorUpdate:(NSEvent *)event
{
NSLog(@"cursorUpdate: %@", [NSDate date]);
[[NSCursor openHandCursor] set];
}
If I whip the mouse into the window's content area, my cursorUpdate method is
called and I see the correct cursor. If I slowly sneak the mouse into my
window's content area, I see the window resize cursor for a moment as I cross
into the window content area (I'm running Lion), then... nothing. The cursor
reverts to the arrow cursor, and my cursorUpdate: method is not called, even
though I am well into my view's rectangle.
If I inset my view from the boundaries of the window a bit (16-ish pixels),
things behave as expected.
What am I doing wrong?
Sample project at
_murat
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: trackingAreas can be snuck up on without triggering?
No, the window is very vanilla. No scrollviews. Hierarchy is
NSWindow
NSView (window's content view)
MyView
Your alternate approach is essentially to give up on tracking areas, no? The
tracking area approach has an attractive simplicity, especially once my view
hierarchy and cursor tracking needs get more complicated, but if it's broken, I
guess I'll have to roll my own solution. And file a bug report.
I should have mentioned that this is on 10.7.4. Won't be able to test on 10.6.8
until Monday. Hi Alex!
_murat
On May 19, 2012, at 10:29 PM, Quincey Morris wrote:
> On May 19, 2012, at 22:10 , mlist0...@gmail.com wrote:
>
>> If I whip the mouse into the window's content area, my cursorUpdate method
>> is called and I see the correct cursor. If I slowly sneak the mouse into my
>> window's content area, I see the window resize cursor for a moment as I
>> cross into the window content area (I'm running Lion), then... nothing. The
>> cursor reverts to the arrow cursor, and my cursorUpdate: method is not
>> called, even though I am well into my view's rectangle.
>
> Does the window contain a NSScrollView? If so, there are certain
> places/timings where the scroll view takes control of the cursor. IIRC, the
> easiest workaround is to set scrollView.documentCursor to the same cursor you
> set for your view in 'cursorUpdate:' -- though I haven't tested the effects
> of this in Lion.
>
> Another [or a complementary] approach is to invoke 'cursorUpdate:' like this:
>
> - (void) mouseMoved: (NSEvent*) event {
> [self cursorUpdate: event];
> … other code for this method, if you have it …
> }
>
> It doesn't hurt to do the same in 'mouseDown:', 'mouseUp:', 'mouseDragged:',
> 'mouseEntered:' and 'mouseExited:', if you use any of those. This saves a lot
> of puzzling over other "missing" cursor updates, and it often simplifies your
> code by centralizing cursor setting.
>
>
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: trackingAreas can be snuck up on without triggering?
On May 20, 2012, at 8:04 AM, Kyle Sluder wrote: > Have you implemented -updateTrackingAreas? Implementing it did not help. Not a surprise since my view doesn't change geometry. _murat ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: trackingAreas can be snuck up on without triggering?
On May 20, 2012, at 9:02 AM, Ken Thomases wrote: > On May 20, 2012, at 10:04 AM, Kyle Sluder wrote: > >> Have you implemented -updateTrackingAreas? > > Or you can try specifying NSTrackingInVisibleRect to take care of much tedium > for you. Nope, didn't help either. _murat ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: trackingAreas can be snuck up on without triggering?
Belt *and* suspenders? ;) _murat On May 20, 2012, at 7:43 AM, Quincey Morris wrote: > On May 20, 2012, at 02:21 , mlist0...@gmail.com wrote: > >> Your alternate approach is essentially to give up on tracking areas, no? The >> tracking area approach has an attractive simplicity, especially once my view >> hierarchy and cursor tracking needs get more complicated, but if it's >> broken, I guess I'll have to roll my own solution. And file a bug report. > > Not "give up:, really. Tracking areas are important because they provide > much-improved 'mouseMoved:' behavior. > > The problem is that your code isn't the only code using tracking areas, and > trying to predict which tracking area will "win" the cursor is difficult. > > Invoking 'cursorMoved:' from other events having a mouse location isn't an > admission of defeat. It turns a fragile boundary-crossing solution into a > robust state-detection solution. > > ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: trackingAreas can be snuck up on without triggering?
On May 20, 2012, at 10:45 AM, Lee Ann Rucker wrote: > But if you're only updating the cursor, why not try addCursorRect:cursor: ? > Presumably that's smart enough to know about the grow zone. The docs note that -addCursorRect:cursor: is "legacy api", supplanted in Leopard by... tracking rects! Not only that "The underlying implementation for the legacy methods is based on NSTrackingArea..." But IT WORKS! Thanks. _murat ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: trackingAreas can be snuck up on without triggering?
Bug ID# 11502520. _murat On May 20, 2012, at 11:42 PM, Lee Ann Rucker wrote: > Heh. I'd file a bug with Apple - this could be an edge case they didn't > consider when they redid grow zones. At the very least they could make sample > code showing what they're doing behind the scenes with the tracking rects. > > - Original Message ----- > From: mlist0...@gmail.com > To: "Lee Ann Rucker" > Cc: "Cocoa Dev" > Sent: Sunday, May 20, 2012 11:11:51 AM > Subject: Re: trackingAreas can be snuck up on without triggering? > > On May 20, 2012, at 10:45 AM, Lee Ann Rucker wrote: > >> But if you're only updating the cursor, why not try addCursorRect:cursor: ? >> Presumably that's smart enough to know about the grow zone. > > The docs note that -addCursorRect:cursor: is "legacy api", supplanted in > Leopard by... tracking rects! Not only that "The underlying implementation > for the legacy methods is based on NSTrackingArea..." > > But IT WORKS! Thanks. > > _murat > ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
