Re: Is it possible to define class from interface builder?
On Aug 13, 2013, at 11:34 AM, Izak van Langevelde eezac...@xs4all.nl wrote: A user interface contains several instances of a specific form, which is easily created in Interface Builder. Is there any way to derive a subclass of NSView from this form, so that it can be reused? A good way to do this is to create a xib that has an NSView with your form all laid out. Then use the Inspector to set File’s Owner’s class to NSViewController; File’s Owner will get a “view” outlet as a result of that. Then just connect that “view” outlet to your view. That will get you a reusable NSViewController you can instantiate using -[NSViewController initWithNibName:bundle:] any number of times in your application, and you can thus substitute its view into your app at any place you like. You could also create an NSView subclass, call it a “ViewControllerHostView,” that knows how to embed a view controller’s view within itself based on a User Defined Runtime Attribute you set up in Interface Builder.[1] That way your ViewControllerHostView can have a controllerNibName property that gets set when it’s instantiated at load time; it can then, when it’s actually being presented, also load the view controller from the named nib and embed its view within itself. -- Chris [1] User Defined Runtime Attributes are values set in Interface Builder that then get set on your objects via KVC when a nib file is loaded. They work in OS X 10.6 and iOS 5 and later. ___ 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: Is it possible to define class from interface builder?
On 2013/08/15, at 15:08, Chris Hanson c...@me.com wrote: On Aug 13, 2013, at 11:34 AM, Izak van Langevelde eezac...@xs4all.nl wrote: A user interface contains several instances of a specific form, which is easily created in Interface Builder. Is there any way to derive a subclass of NSView from this form, so that it can be reused? A good way to do this is to create a xib that has an NSView with your form all laid out. Then use the Inspector to set File’s Owner’s class to NSViewController; File’s Owner will get a “view” outlet as a result of that. Then just connect that “view” outlet to your view. That will get you a reusable NSViewController you can instantiate using -[NSViewController initWithNibName:bundle:] any number of times in your application, and you can thus substitute its view into your app at any place you like. You could also create an NSView subclass, call it a “ViewControllerHostView,” that knows how to embed a view controller’s view within itself based on a User Defined Runtime Attribute you set up in Interface Builder.[1] That way your ViewControllerHostView can have a controllerNibName property that gets set when it’s instantiated at load time; it can then, when it’s actually being presented, also load the view controller from the named nib and embed its view within itself. -- Chris [1] User Defined Runtime Attributes are values set in Interface Builder that then get set on your objects via KVC when a nib file is loaded. They work in OS X 10.6 and iOS 5 Wow. That sounds like a *really* powerful workflow. Are there any good example code downloads or tutorials that illustrate this well? ___ 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
NSToolbar's setShowsBaselineSeparator
Dear list, I've been using NSToolbar's -setShowsBaselineSeparator: to remove the dark gray line below the toolbar (because I have Safari-like tabs below the toolbar). This is working nicely on 10.8, but on 10.6.8, there is a white line left in place of the dark gray base line. It's almost as if the toolbar is not redrawn when the separator line is switched off. Additionally if the window loses focus, then another white line can be seen above the toolbar (below the window's main title bar). Now, doing something to the toolbar, like setting it to icons only and back, or setting it to small size and back, makes the white lines go away. Here's how I do the job NSToolbar *tb = [[self windowForSheet] toolbar]; [tb setAllowsUserCustomization:YES]; [tb setAutosavesConfiguration:YES]; [tb setShowsBaselineSeparator:NO]; and I run this in my NSDocument's -windowControllerDidLoadNib: method. Has anyone else seen this behaviour and, better still, solved it? Is there a way to force the toolbar to redraw? Calling -display and/or -update on the window doesn't seem to do the trick. Many thanks, Martin ___ 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: Block gets NULL-ified when animation completes
The collection view will very likely have corresponding ivars for the animation
block and its completion handler. If that's the case, it should (shall) create
a copy of the anonymous animation (updates) and completion block when receiving
them in `performBatchUpdate:completion:`.
Now, `finish` is an imported field of the anonymous completion handler. The
copy operation of the anonymous completion handler will cause the block
`finish` to be copied as well. Since the outer block lives on the heap, the
imported fields of `finish` will live there, too. Effectively, imported fields
will be copied into the storage area of the outermost block.
It seems to me, that block `finish` should have a ref count of +1 within the
anonymous completion handler.
Vlad, could you please verify your observations and possibly create a simple
test class mimicking the behavior of the collection view (no animation, just a
dummy async method), e.g.
dispatch_block_t completion = ^{
NSLog(@invoking completion);
};
dispatch_block_t updates = ^{
NSLog(@invoking updates);
};
dispatch_block_t finish = ^{
NSLog(@invoking finish);
if (completion) {
completion();
}
};
if (animated) {
self.testClass performDummyMethod:^{
updates();
} completion:^(BOOL finished) {
finish();
}];
When TestClass actually makes copies of the block when setting its ivars
`_updates` and `_completion`, it should work (IMO).
See also: Block Implementation Specification
http://clang.llvm.org/docs/Block-ABI-Apple.html (especially, Imported const
copy of Block reference).
Andreas
On 09.08.2013, at 16:57, Vlad Alekseev ippo...@me.com wrote:
Hey!
I have a method where I update my collection view's layout parameter and want
to have a completion block invoked when animation completes:
- (void)transitionAnimated:(BOOL)animated
completion:(dispatch_block_t)completion
{
dispatch_block_t updates = ^{
self.layout.maximumScale = self.maximumScale;
};
dispatch_block_t finish = ^{
if (completion) {
completion();
}
};
if (animated) {
self.collectionView.userInteractionEnabled = NO;
[self.collectionView performBatchUpdates:^{
updates();
} completion:^(BOOL finished) {
self.collectionView.userInteractionEnabled = YES;
finish();
}];
}
else {
updates();
[self.layout invalidateLayout];
finish();
}
}
It works as expected if collection view contains some items. But it crashes
if collection view is empty. And it crashes here:
} completion:^(BOOL finished) {
self.collectionView.userInteractionEnabled = YES;
finish(); // CRASH because finish == NULL
}];
Debugger says that finish is nil:
(lldb) p finish
(dispatch_block_t) $1 = parent is NULL
What is going on with that block? Any ideas why it gets NULL-ified?
___
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/agrosam%40onlinehome.de
This email sent to agro...@onlinehome.de
___
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: Dismissing Open dlog before doc actually opens
On Aug 14, 2013, at 7:51, Graham Cox graham@bigpond.com wrote: On 14/08/2013, at 1:38 AM, Steve Mills smi...@makemusic.com wrote: unning an open panel modally is a user-hostile experience that prevents the user from interacting with other documents. OS X applications should not behave this way. Apple didn't feel that way in the past, so I don't believe it's user-hostile. They did, which is why first modeless dialogs (from System 1? 2?) and then sheets (OSX 1.0) were developed. Even as far back as the original Inside Macintosh the use of modal dialogs was strongly discouraged when it was possible to use something else. The original system design used a modal Open dialog but this became a modeless dialog in System 7 (1991), if I recall correctly. A modeless dialog* would be a plain old window. :-p I presume you’re thinking of semi-modal dialogs, which only block the current application, can be dragged around, and were introduced with System 7.0 (so over 20 years ago). Well, the window border style for them was introduced then, and ModalDialog() was extended to handle them … there were some developers who just used a regular window and added an inset line in the body to fake them a little before that. OSX only has semi-modal dialogs, real modal dialogs that can’t be dragged and block all applications don’t seem to exist anymore in this real multi-tasking OS. Anyway, history aside, the fact that orderOut: doesn't do anything suggests a problem somewhere - I've seen this happen before when an unhandled exception during the modal loop puts it into a state where the modal session can't be closed and the dialog won't go away. I vaguely remember having the same issue where an open panel stayed open too long. I think it might be related to autorelease pools holding on to the actual window-owning object (some private thing, I think). You might want to try creating an inner pool and releasing that right when you want the panel to close. Also keep in mind that in current MacOS X releases, open and save panels are out-of-process windows managed by PowerBox (think sandbox), and NSOpenPanel and NSSavePanel are only proxy objects in your process. Many actions you had on NSWindow are probably stubbed out, and the remaining ones send messages to PowerBox to manipulate the actual window there, or to manage the little transparent, borderless window that holds your accessory view. orderOut: may be one of those. Cheers, -- Uli Kusterer “The Witnesses of TeachText are everywhere... *) Strictly speaking, in Classic there could have been a modeless dialog: A window created from a DLOG resource, then used as a regular window, run using DialogSelect(). But they weren’t really a ‘thing’ as a UI element. Usually they were just a shorthand for loading controls into a window, or were implemented as semi-modal. ___ 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: Dismissing Open dlog before doc actually opens
On Aug 14, 2013, at 2:14 AM, Uli Kusterer witness.of.teacht...@gmx.net wrote: Also keep in mind that in current MacOS X releases, open and save panels are out-of-process windows managed by PowerBox (think sandbox), and NSOpenPanel and NSSavePanel are only proxy objects in your process. Many actions you had on NSWindow are probably stubbed out, and the remaining ones send messages to PowerBox to manipulate the actual window there, or to manage the little transparent, borderless window that holds your accessory view. orderOut: may be one of those. This is only true for sandboxed apps, but it is a very good point. If Steve's app is sandboxed, it needs to forward the- orderOut: message to Powerbox over XPC. That would require running the runloop. --Kyle Sluder ___ 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
Find bar in a text view
I have text views in a split view, and I use find bars with them. I'd like to implement incremental searching. When I turn it on in IB it works, except that if I collapse a subview showing the grey overlay, the overlay remains on screen. As a workaround, the documentation says I can turn the overlay off I should set the incrementalSearchingShouldDimContentView property to NO. The problem is that the find bar is all pre-implemented by NSTextView, and I can't see how to address the NSTextFinder instance. Any suggestions, or do I need to implement my own NSTextFinder instance? -- Shane Stanley sstan...@myriad-com.com.au 'AppleScriptObjC Explored' www.macosxautomation.com/applescript/apps/ ___ 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: Block gets NULL-ified when animation completes
Turns out, this is a bug in UICollectionView or even ARC. And it is easily
reproducible. You can download Apple's sample code:
http://developer.apple.com/library/ios/samplecode/CollectionView-Simple/Introduction/Intro.html
and modify it to return 0 items to the collection view. Then try to perform the
following code:
dispatch_block_t block = ^{
printf(finished);
};
UICollectionViewFlowLayout *layout = (UICollectionViewFlowLayout
*)self.collectionView.collectionViewLayout;
[self.collectionView performBatchUpdates:^{
layout.minimumInteritemSpacing = 20;
} completion:^(BOOL finished) {
block();
}];
It will crash since `finish` will be `nil`. But if you make data source to
return non-zero item count to the collection view then everything will work
good.
Created a bug report with ID 14744561. Affects iOS 6.0 and above.
You may refer to the Apple Dev Forums discussion thread:
https://devforums.apple.com/thread/198531?tstart=0
Thanks!
Vlad.
15 авг. 2013 г., в 9:25, Vlad Alekseev ippo...@me.com написал(а):
Hey,
ARC should drive this for me. If it wouldn’t, then it wouldn’t work in case
if there are items in the collection view.
Tried to copy manually - no results. BTW, not only «finish», but also
«completion» gets NULLified at the last step.
Vlad.
15 авг. 2013 г., в 9:22, Jens Alfke j...@mooseyard.com написал(а):
Sounds like you forgot to copy the block — if it’s being invoked after the
calling function returns (as a completion handler would) it needs to be
copied so it can survive the loss of its original stack frame.
—Jens
___
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: Dismissing Open dlog before doc actually opens
On Aug 14, 2013, at 04:14:58, Uli Kusterer witness.of.teacht...@gmx.net wrote: I vaguely remember having the same issue where an open panel stayed open too long. I think it might be related to autorelease pools holding on to the actual window-owning object (some private thing, I think). You might want to try creating an inner pool and releasing that right when you want the panel to close. Yup, I tried that at one point, hoping it would fix it, but it did not. The solution I have (see runUntilDate: in this thread) is working. -- Steve Mills office: 952-818-3871 home: 952-401-6255 cell: 612-803-6157 ___ 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: Dismissing Open dlog before doc actually opens
On Aug 15, 2013, at 06:41:49, Kyle Sluder k...@ksluder.com wrote: This is only true for sandboxed apps, but it is a very good point. If Steve's app is sandboxed, it needs to forward the- orderOut: message to Powerbox over XPC. That would require running the runloop. It is not sandboxed. -- Steve Mills office: 952-818-3871 home: 952-401-6255 cell: 612-803-6157 ___ 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: Block gets NULL-ified when animation completes
On Aug 15, 2013, at 5:41 AM, Vlad Alekseev ippo...@me.com wrote:
dispatch_block_t block = ^{
printf(finished);
};
UICollectionViewFlowLayout *layout = (UICollectionViewFlowLayout
*)self.collectionView.collectionViewLayout;
[self.collectionView performBatchUpdates:^{
layout.minimumInteritemSpacing = 20;
} completion:^(BOOL finished) {
block();
}];
As I said before, this is a bug in your code. ‘block’ needs to be copied since
it is going to be called after the calling function returns.
Yes, the collection view copies the completion block you pass it. But that
block is not ‘block’, it’s the inline block literal that calls ‘block’. That
gets copied, but when that is called it still tries to call the uncopied
‘block’, which fails.
—Jens
___
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: Block gets NULL-ified when animation completes
As I said before, this is a bug in your code. ‘block’ needs to be copied
since it is going to be called after the calling function returns.
I work under ARC. It goes to heap automatically.
Also, there are some circumstances that proves your wrong guess:
1. If I copy it manually, it still gets NULLified.
2. If there are some items in the collection view, it works as expected, no
explicit copy needed.
So it seems for me like a bug in the ARC/runtime or in the collection view
(unlikely).
Vlad.
15 авг. 2013 г., в 18:49, Jens Alfke j...@mooseyard.com написал(а):
On Aug 15, 2013, at 5:41 AM, Vlad Alekseev ippo...@me.com wrote:
dispatch_block_t block = ^{
printf(finished);
};
UICollectionViewFlowLayout *layout = (UICollectionViewFlowLayout
*)self.collectionView.collectionViewLayout;
[self.collectionView performBatchUpdates:^{
layout.minimumInteritemSpacing = 20;
} completion:^(BOOL finished) {
block();
}];
Yes, the collection view copies the completion block you pass it. But that
block is not ‘block’, it’s the inline block literal that calls ‘block’. That
gets copied, but when that is called it still tries to call the uncopied
‘block’, which fails.
—Jens
___
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: Block gets NULL-ified when animation completes
On Aug 15, 2013, at 9:49 AM, Jens Alfke wrote:
On Aug 15, 2013, at 5:41 AM, Vlad Alekseev ippo...@me.com wrote:
dispatch_block_t block = ^{
printf(finished);
};
UICollectionViewFlowLayout *layout = (UICollectionViewFlowLayout
*)self.collectionView.collectionViewLayout;
[self.collectionView performBatchUpdates:^{
layout.minimumInteritemSpacing = 20;
} completion:^(BOOL finished) {
block();
}];
As I said before, this is a bug in your code. ‘block’ needs to be copied
since it is going to be called after the calling function returns.
Yes, the collection view copies the completion block you pass it. But that
block is not ‘block’, it’s the inline block literal that calls ‘block’. That
gets copied, but when that is called it still tries to call the uncopied
‘block’, which fails.
When a block gets copied, it copies any blocks it has captured. So, the fact
that the completion block is copied by the framework code is sufficient.
https://developer.apple.com/library/ios/documentation/cocoa/Conceptual/Blocks/Articles/bxVariables.html#//apple_ref/doc/uid/TP40007502-CH6-SW7
Regards,
Ken
___
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: Find bar in a text view
Sounds like a bug that you should report via Bug Reporter. But as a workaround, you should be able to call -[NSTextView setIncrementalSearchingEnabled:NO] when the subview gets collapsed (then obviously set it back to YES when the text view is uncollapsed, though you will lose search results in doing so). -KP On Aug 15, 2013, at 4:59 AM, Shane Stanley sstan...@myriad-com.com.au wrote: I have text views in a split view, and I use find bars with them. I'd like to implement incremental searching. When I turn it on in IB it works, except that if I collapse a subview showing the grey overlay, the overlay remains on screen. As a workaround, the documentation says I can turn the overlay off I should set the incrementalSearchingShouldDimContentView property to NO. The problem is that the find bar is all pre-implemented by NSTextView, and I can't see how to address the NSTextFinder instance. Any suggestions, or do I need to implement my own NSTextFinder instance? -- Shane Stanley sstan...@myriad-com.com.au 'AppleScriptObjC Explored' www.macosxautomation.com/applescript/apps/ ___ 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/kperry%40apple.com This email sent to kpe...@apple.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
Auto layout semantics?
I wasted some time trying to use auto layout to maintain the layout of a form, to make sure that fields are horizontally resized with the form, while labels maintain their size. However, when two fields are sitting next to each other, having the same priority, only one of them resizes with the form. Is there any documentation around that specifies how layout constraints are resolved? Thanks, Izak --- Grinnikend door het leven... ___ 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: Auto layout semantics?
On Thu, Aug 15, 2013, at 09:33 AM, Izak van Langevelde wrote: I wasted some time trying to use auto layout to maintain the layout of a form, to make sure that fields are horizontally resized with the form, while labels maintain their size. However, when two fields are sitting next to each other, having the same priority, only one of them resizes with the form. Is there any documentation around that specifies how layout constraints are resolved? That's the canonical example of an ambiguous layout. You use priorities to tell the auto layout system which views to resize. Have you read the Cocoa Auto Layout Guide? http://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/AutolayoutPG/Articles/Introduction.html --Kyle Sluder ___ 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: Auto layout semantics?
On 15 Aug 2013, at 11:33 AM, Izak van Langevelde eezac...@xs4all.nl wrote: I wasted some time trying to use auto layout to maintain the layout of a form, to make sure that fields are horizontally resized with the form, while labels maintain their size. However, when two fields are sitting next to each other, having the same priority, only one of them resizes with the form. Is there any documentation around that specifies how layout constraints are resolved? There is a lot that describes the process of resolving constraints, starting with http://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/AutolayoutPG/Articles/Introduction.html. Assuming your have that information down, your problem may be that Xcode 4's Interface Builder is fighting you. Most of what you need to do can be reasoned-through from two principles: Constraints on a view have to be sufficient to specify its size and placement so there is no more than one solution; and consistent, so they yield no less than one solution. Interface Builder in Xcode 4 helpfully enforces sufficiency by automatically creating constraints according to the making s*** up algorithm*, and not letting you change or delete them. There's a menu at the lower-right that relieves the upstream and downstream effects so you can be free to adjust placements; and you can delete IB's constraints by first adding a sufficient constraint chain of your own. * (The responsible engineers did a respectable job, but the result is opaque and frustrating. I know Dev Tools has made this a top priority.) Do I understand correctly that you have a row in your form that looks like: |--Label1-Field1--Label2-Field2 --| ? (Not intended to be a constraint-specification format.) And you want Label1 and Label2 to be of fixed (identical?) size, and Field1 and Field2 to have variable (equal?) size according to the width of the superview? If I'm not correct, the rest is TL;DR. Caveat that I'm working off the top of my head on my lunch hour, and drawing suggestions from the same place Xc4 gets automatic constraints. This is what I'd try next. I'll comment only on the horizontal axis. I'm not going to comment on getting spacing and alignment from other elements in the view (like the rows above and below). All the horizontal-spacing constraints should be of constant size, and 1000 priority. The labels should have either numerically-constant widths, or you could turn up the priority on their horizontal compression resistance. The latter will mean that if a localization requires more or less room for the text, the label will expand accordingly but take up no more room than necessary. Consider an additional width constraint of ≥ some number. Don't allow any placement constraints that aren't between immediate neighbors. It's easy to pick those up (and until the whole horizontal chain is solved, IB may insist on imposing them), but you aren't finished until duplicate or extraneous spacing constraints are gone. (Frequently one has to vary from this rule-of-thumb, but it's what I start from.) That leaves the problem of the fields. If you are happy making them of equal size, your work is done; the whole chain is determined. If you know only minimum or maximum sizes, that isn't sufficient (and IB-Xc4 may force constraints of its own on you). If the min/max sizes are all you have, the chain is indeterminate, and when you resize the container, the change may be allocated to one, maybe to the other, there's no sure way to know in advance; whatever happens, the constraints you do have wouldn't be contradicted. I don't know of a graphical way to set non-equal distributions of width changes. (Meaning, I think there is none, but I'm too weaselly to commit to it.) I think — I've never done this, and I don't have time to try — you can do it in code. Create an NSLayoutConstraint from one field to the next, on NSLayoutAttributeWidth, relation equal, but the multiplier and constant set up so that the first width is related to the second by: width1 = multiplier * width2 + constant Once you work out the proportions, the whole chain will be determined, and it should do what you want. Definitely set a minimum width on the smaller field, or it could be compressed to or below zero. (An NSMutableLayoutConstraint would be _extremely_ helpful here. Radar in process.) — 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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
iOS UITableViewCell imageView
Anyone know how to properly set the borderWidth on a UITableViewCell's image.imageView layer? Setting the layer's borderWidth and borderColor work just fine on a UITableViewCell's layer, when setting them in tableView:cellForRowAtIndexPath, but the same code on the cell.imageView.layer has no effect at all. I've searched through StackOverflow and have found answers that all look similar, but all with no visual effect on the resulting image. In Xcode 4.3 on iOS 6.x This works fine to put very obvious borders around the cell: UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier]; cell.imageView.image = [UIImage imageNamed:@myImage.png]; CALayer *layer; //layer = cell.layer; // -- I work just fine //layer = cell.imageView.layer; // -- I do nothing [layer setMasksToBounds:YES]; [layer setCornerRadius:10.0f]; [layer setBorderWidth:10.0f]; If you uncomment the first layer line and run the app, there is a large black border around the cell, but if you uncomment the second and run there is no effect on the image at all. Any ideas what I'm missing here? Thanks in advance. - Alex Zavatone ___ 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
Menu item key equiv mods not correct
When adding some certain-mode-only menus, we scan the existing menus to temporarily remove key equivs that are also in the new menu. They're put back later. However, something isn't right when I ask for each menu item's modifiers. Our Edit menu has Select All, which is command-a. Another menu to the right of it has an item whose equiv is command-shift-a. Everything's hunky dory with those. Then we go to add the new menu, which also uses command-a. We first find the Select All menu which uses the same equiv, so we remove it. But then it also find the other item which uses command-shift-a. Here's the code that looks for matching equivs: if([item.keyEquivalent length] ([item.keyEquivalent compare:keyToMatch options:NSCaseInsensitiveSearch] == NSOrderedSame) item.keyEquivalentModifierMask == modsToMatch) Both values are very clearly 0x10, which is only NSCommandKeyMask. But where's the shift key bit? The menu item's mods should be 0x12. Any ideas about why it's wrong? -- Steve Mills office: 952-818-3871 home: 952-401-6255 cell: 612-803-6157 ___ 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: Menu item key equiv mods not correct
On Aug 15, 2013, at 2:31 PM, Steve Mills wrote: When adding some certain-mode-only menus, we scan the existing menus to temporarily remove key equivs that are also in the new menu. They're put back later. However, something isn't right when I ask for each menu item's modifiers. Our Edit menu has Select All, which is command-a. Another menu to the right of it has an item whose equiv is command-shift-a. Everything's hunky dory with those. Then we go to add the new menu, which also uses command-a. We first find the Select All menu which uses the same equiv, so we remove it. But then it also find the other item which uses command-shift-a. Here's the code that looks for matching equivs: if([item.keyEquivalent length] ([item.keyEquivalent compare:keyToMatch options:NSCaseInsensitiveSearch] == NSOrderedSame) item.keyEquivalentModifierMask == modsToMatch) Both values are very clearly 0x10, which is only NSCommandKeyMask. But where's the shift key bit? The menu item's mods should be 0x12. Any ideas about why it's wrong? Shifted key equivalents which use letter keys are usually represented with capital letters, not NSShiftKeyMask. You're using a case-insensitive match, so you're catching those. Use a case-sensitive match and you should be fine. Regards, Ken ___ 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
Fwd: GNUstep Kickstarter Project
Hi list, I've got this from the lead developer of GNUstep, maybe some of you are interested in this. cheers, Lars Anfang der weitergeleiteten E-Mail: Von: Gregory Casamento greg.casame...@gmail.com Datum: 12. August 2013 22:13:54 MESZ An: Discuss-gnustep Discuss discuss-gnus...@gnu.org Betreff: GNUstep Kickstarter Project Hey guys, I've launched a kickstarter project in the hopes of getting some time to work exclusively on GNUstep in order to try to address some of the issues we have surrounding API completeness, documentation issues, etc..., here it is: http://www.kickstarter.com/projects/203272607/gnustep-project Thanks, GC -- Gregory Casamento Open Logic Corporation, Principal Consultant yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell) http://www.gnustep.org http://heronsperch.blogspot.com ___ Discuss-gnustep mailing list discuss-gnus...@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep ___ 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: Menu item key equiv mods not correct
On Aug 15, 2013, at 14:39:56, Ken Thomases k...@codeweavers.com wrote: Shifted key equivalents which use letter keys are usually represented with capital letters, not NSShiftKeyMask. You're using a case-insensitive match, so you're catching those. Use a case-sensitive match and you should be fine. @#$#$%$! I hate that. Thanks again for saving the day, Ken. -- Steve Mills office: 952-818-3871 home: 952-401-6255 cell: 612-803-6157 ___ 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: Find bar in a text view
On 16/08/2013, at 2:27 AM, Kevin Perry kpe...@apple.com wrote: Sounds like a bug that you should report via Bug Reporter. Thanks, I'd done that (#14745599). It also happens if a text view is on a tab view and you change tabs, except it then also moves rather dramatically (in my case partly outside the window area). But as a workaround, you should be able to call -[NSTextView setIncrementalSearchingEnabled:NO] when the subview gets collapsed (then obviously set it back to YES when the text view is uncollapsed, though you will lose search results in doing so). That's a thought, thanks. -- Shane Stanley sstan...@myriad-com.com.au 'AppleScriptObjC Explored' www.macosxautomation.com/applescript/apps/ ___ 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: Uniquing data in Core Data
Can you make it a derived property? If each Managed object has a reference to the AppDelegate they can just return the comparison of their NSManagedObjectID to the one stored as the user default. Sandor Szatmari On Aug 15, 2013, at 1:07, Rick Mann rm...@latencyzero.com wrote: On Aug 14, 2013, at 21:14 , Jerry Krinock je...@ieee.org wrote: On 2013 Aug 14, at 20:46, Keary Suska cocoa-...@esoteritech.com wrote: A cleaner approach, IMHO, is to have a holder entity whose sole attribute is a to-one relationship to your other entity. Think of it as a singleton that always exist and maintains the particular managed object. Indeed Keary's idea is much better, and furthermore you may well already such an existing singleton entity nearby in that data model, which would be the logical place for this to-one relationship. Just add this relationship to that existing singleton entity. On Aug 14, 2013, at 20:46 , Keary Suska cocoa-...@esoteritech.com wrote: On Aug 14, 2013, at 6:28 PM, Rick Mann wrote: I have a boolean property on an Entity for which only one should ever be true. Is it really bad to implement a custom setter that loads every other instance in the MOC that's true and sets them all to false? My code is actually good about always clearing the current one before setting the new one, but when I'm debugging, I will copy data over from another device, and it can't clear the old one in this case. I am not sure if it bad, but it sure smells funny ;-) Anyway, the issue may be more of the data approach. It is likely that the boolean attribute shouldn't belong to the entity at all--i.e. that the attribute is really for needed by some other object or process and is not a function of the entity. A cleaner approach, IMHO, is to have a holder entity whose sole attribute is a to-one relationship to your other entity. Think of it as a singleton that always exist and maintains the particular managed object. It also requires no code at all to maintain uniqueness--simply assign the relationship. Well, I used to store the active instance as a property of my app (AppDelegate). I'd store the NSManagedObjectID as a user default. Unfortunately, I need to be able to sort on the boolean property, and on an NSFetchedResultsController at that, which won't sort on transient properties. Moreover, it seems extraordinarily clumsy to have another entity representing the app, and to only have a singleton of that. -- Rick ___ 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/admin.szatmari.net%40gmail.com This email sent to admin.szatmari@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
Re: Uniquing data in Core Data
Doesn't work for sorting in NSFetchedresultsController On Aug 15, 2013, at 16:34 , Sandor Szatmari admin.szatmari@gmail.com wrote: Can you make it a derived property? If each Managed object has a reference to the AppDelegate they can just return the comparison of their NSManagedObjectID to the one stored as the user default. Sandor Szatmari On Aug 15, 2013, at 1:07, Rick Mann rm...@latencyzero.com wrote: On Aug 14, 2013, at 21:14 , Jerry Krinock je...@ieee.org wrote: On 2013 Aug 14, at 20:46, Keary Suska cocoa-...@esoteritech.com wrote: A cleaner approach, IMHO, is to have a holder entity whose sole attribute is a to-one relationship to your other entity. Think of it as a singleton that always exist and maintains the particular managed object. Indeed Keary's idea is much better, and furthermore you may well already such an existing singleton entity nearby in that data model, which would be the logical place for this to-one relationship. Just add this relationship to that existing singleton entity. On Aug 14, 2013, at 20:46 , Keary Suska cocoa-...@esoteritech.com wrote: On Aug 14, 2013, at 6:28 PM, Rick Mann wrote: I have a boolean property on an Entity for which only one should ever be true. Is it really bad to implement a custom setter that loads every other instance in the MOC that's true and sets them all to false? My code is actually good about always clearing the current one before setting the new one, but when I'm debugging, I will copy data over from another device, and it can't clear the old one in this case. I am not sure if it bad, but it sure smells funny ;-) Anyway, the issue may be more of the data approach. It is likely that the boolean attribute shouldn't belong to the entity at all--i.e. that the attribute is really for needed by some other object or process and is not a function of the entity. A cleaner approach, IMHO, is to have a holder entity whose sole attribute is a to-one relationship to your other entity. Think of it as a singleton that always exist and maintains the particular managed object. It also requires no code at all to maintain uniqueness--simply assign the relationship. Well, I used to store the active instance as a property of my app (AppDelegate). I'd store the NSManagedObjectID as a user default. Unfortunately, I need to be able to sort on the boolean property, and on an NSFetchedResultsController at that, which won't sort on transient properties. Moreover, it seems extraordinarily clumsy to have another entity representing the app, and to only have a singleton of that. -- Rick ___ 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/admin.szatmari.net%40gmail.com This email sent to admin.szatmari@gmail.com -- Rick ___ 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: GNUstep Kickstarter Project
No, not really. On Thu, Aug 15, 2013 at 5:02 PM, Lars Sonchocky-Helldorf lars.sonchocky-helld...@hamburg.de wrote: Hi list, I've got this from the lead developer of GNUstep, maybe some of you are interested in this. cheers, Lars Anfang der weitergeleiteten E-Mail: Von: Gregory Casamento greg.casame...@gmail.com Datum: 12. August 2013 22:13:54 MESZ An: Discuss-gnustep Discuss discuss-gnus...@gnu.org Betreff: GNUstep Kickstarter Project Hey guys, I've launched a kickstarter project in the hopes of getting some time to work exclusively on GNUstep in order to try to address some of the issues we have surrounding API completeness, documentation issues, etc..., here it is: http://www.kickstarter.com/projects/203272607/gnustep-project Thanks, GC -- Gregory Casamento Open Logic Corporation, Principal Consultant yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell) http://www.gnustep.org http://heronsperch.blogspot.com ___ Discuss-gnustep mailing list discuss-gnus...@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep ___ 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/treaves%40silverfieldstech.com This email sent to trea...@silverfieldstech.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
Prioritizing UIScrollView gestures over buttons
I have a set of buttons that live above (not subviews of) a UIScrollView. I update their position based on feedback from the UIScrollView during pan and zoom. The problem is, the buttons are easy to tap accidentally when you're trying to pan or zoom. Is there a magic setting to let taps in the buttons first serve gestures in the UIScrollView? I can re-implement them as views with a tap gesture recognizer if that would help. -- Rick ___ 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
