Re: Strange toolbar/view/resize cursor interaction
invalidateShadow: was a nice idea; just tried it and it didn't help. I only add the toolbar once; after that it's toggling visibility status. I'm just initially adding the toolbar programmatically instead of in the nib because I ran into some problems doing that in my Cocoa/Carbon hybrid app. Once I get the entire app ported to Cocoa, I expect to be able to switch to having my toolbar in the nib, but trying to test when parts of the window content can't be clicked is tricky in the meantime. :) Eric Shepherd Gmail: the.she...@gmail.com Twitter: sheppy On Sat, Apr 19, 2014 at 2:20 AM, Ken Thomases wrote: > On Apr 19, 2014, at 12:52 AM, Eric Shepherd wrote: > > > On Thu, Apr 17, 2014 at 8:55 AM, Eric Shepherd > wrote: > > > >> I'm having an odd problem with my Mac OS X application here. I have a > >> window containing an NSOpenGLView, into which I programmatically insert > a > >> toolbar when the window is opened. > >> > >> Upon doing so, I find that as I move the mouse down through my window, > it > >> turns into the "resize cursor" quite some distance above the bottom > edge of > >> the window, and the cursor's hotspot jumps abruptly to that bottom edge > of > >> the window. > >> > >> It appears that the distance of this jump is the same as the height of > the > >> toolbar, and toggling the toolbar off clears the problem up (while off, > the > >> cursor acts correctly, turning into the resize cursor at the edge of the > >> window, and once the toolbar is on again, the cursor also behaves > properly). > > > Still stumped by this one. I've read about every method that has "resize" > > or "toolbar" in its name, among others, without finding anything. :) > > This is a bit of a long shot, but try invoking -[NSWindow > invalidateShadow] after adding the toolbar. > > Also, is there a reason you're adding and removing the toolbar rather than > toggling its visibility using -toggleToolbarShown:? > > 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: Strange toolbar/view/resize cursor interaction
On Apr 19, 2014, at 12:52 AM, Eric Shepherd wrote: > On Thu, Apr 17, 2014 at 8:55 AM, Eric Shepherd wrote: > >> I'm having an odd problem with my Mac OS X application here. I have a >> window containing an NSOpenGLView, into which I programmatically insert a >> toolbar when the window is opened. >> >> Upon doing so, I find that as I move the mouse down through my window, it >> turns into the "resize cursor" quite some distance above the bottom edge of >> the window, and the cursor's hotspot jumps abruptly to that bottom edge of >> the window. >> >> It appears that the distance of this jump is the same as the height of the >> toolbar, and toggling the toolbar off clears the problem up (while off, the >> cursor acts correctly, turning into the resize cursor at the edge of the >> window, and once the toolbar is on again, the cursor also behaves properly). > Still stumped by this one. I've read about every method that has "resize" > or "toolbar" in its name, among others, without finding anything. :) This is a bit of a long shot, but try invoking -[NSWindow invalidateShadow] after adding the toolbar. Also, is there a reason you're adding and removing the toolbar rather than toggling its visibility using -toggleToolbarShown:? 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: Strange toolbar/view/resize cursor interaction
Still stumped by this one. I've read about every method that has "resize" or "toolbar" in its name, among others, without finding anything. :) Eric Shepherd Gmail: the.she...@gmail.com Twitter: sheppy On Thu, Apr 17, 2014 at 8:55 AM, Eric Shepherd wrote: > I'm having an odd problem with my Mac OS X application here. I have a > window containing an NSOpenGLView, into which I programmatically insert a > toolbar when the window is opened. > > Upon doing so, I find that as I move the mouse down through my window, it > turns into the "resize cursor" quite some distance above the bottom edge of > the window, and the cursor's hotspot jumps abruptly to that bottom edge of > the window. > > It appears that the distance of this jump is the same as the height of the > toolbar, and toggling the toolbar off clears the problem up (while off, the > cursor acts correctly, turning into the resize cursor at the edge of the > window, and once the toolbar is on again, the cursor also behaves properly). > > Anyone know what I'm missing here? This is very weird, and I've been > beating myself against it for a while now. > > Thanks, > > Eric Shepherd > Gmail: the.she...@gmail.com > Twitter: sheppy > ___ 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: cocoapods: Problem with loading nib for a NSWindowController
On Apr 18, 2014, at 14:14 , Gerd Knops wrote: > Dangerous (and entirely wrong) assumption. I know perfectly well that Mac HFS+ can be made case sensitive, so perhaps I should have worded it better: “…even *when* the Mac file system is case insensitive.” However, both you and Fritz missed my real point, which is that it *may* be (I have a *vague* recollection of this coming up before) that nib loading might fail if the the string passed to ‘initWithNibName:’ doesn’t match the case of the actual file name, regardless of the case sensitivity of the file system. Perhaps I misremember, but IAC the point is to check for any case-sensitivity issues which might amount to a misspelled string. ___ 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
Detecting screen capture in progress
How can I detect when a screen shot selection (cmd-shift-4) is in progress? I have a custom window that I’m trying to make behave like a menu (it comes out of a status item). Part of this behavior is dismissing it when the user clicks on something else, which I detect using a CGEventTap. One case where I *don’t* want a click to dismiss is when it’s the start of a screen shot selection. Is there any way to detect this? ___ 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: cocoapods: Problem with loading nib for a NSWindowController
Oh, also, HFS+ is case-sensitive in iOS, lacking NSWindowController though it be. (Is it HFS+? I’m too eager to get out the door for me to check.) — F On 18 Apr 2014, at 5:30 PM, Fritz Anderson wrote: > To be less Hermetic… case-sensitivity has been an option in HFS+ installation > for many, many years. > > I think you’d be ill-advised to pick it, as I am confident that there is a > large codebase that inadvertently depends on case-insensitivity. (That is, > the developer sometimes opened "Polish.dat", and sometimes "polish.dat".) You > have to have very particular circumstances, or be of a certain personal > disposition, to want to do it anyway. > > — 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
Re: cocoapods: Problem with loading nib for a NSWindowController
To be less Hermetic… case-sensitivity has been an option in HFS+ installation for many, many years. I think you’d be ill-advised to pick it, as I am confident that there is a large codebase that inadvertently depends on case-insensitivity. (That is, the developer sometimes opened "Polish.dat", and sometimes "polish.dat".) You have to have very particular circumstances, or be of a certain personal disposition, to want to do it anyway. — F On 18 Apr 2014, at 4:14 PM, Gerd Knops wrote: > Dangerous (and entirely wrong) assumption. > > On Apr 18, 2014, at 12:07 PM, Quincey Morris > wrote: > >> — Check the capitalization of your XIB file name. It’s possible that case >> matters to nib loading, even though the Mac file system is case insensitive. >> > ___ 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: cocoapods: Problem with loading nib for a NSWindowController
Dangerous (and entirely wrong) assumption. On Apr 18, 2014, at 12:07 PM, Quincey Morris wrote: > — Check the capitalization of your XIB file name. It’s possible that case > matters to nib loading, even though the Mac file system is case insensitive. > ___ 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: cocoapods: Problem with loading nib for a NSWindowController
On Apr 18, 2014, at 06:32 , Colas wrote: > —> in my real project, I have an error : > -[MyCBDLockManager loadWindow]: failed to load window nib file > 'MyCBDLockManager’. In regards to CocoaPods issues, this list isn’t the place to ask. In regards to nib-loading issues: — Check the capitalization of your XIB file name. It’s possible that case matters to nib loading, even though the Mac file system is case insensitive. — Check the target membership of your XIB file. If it’s not marked as belonging to the target, it won’t get copied into the app. — Check whether the nib file is in the built app. You can use “Reveal In Finder” with the app’s entry in the Products section of the navigator, then use “Show Package Contents” to look inside the app and see if the nib file is in the Resources subfolder where it should be. If it’s none of the above, there may be a problem with the nib file itself (for example, not containing a window at all). I’d expect an exception to be thrown for these kinds of errors, but perhaps not. ___ 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
cocoapods: Problem with loading nib for a NSWindowController
Dear cocoa-dev,
I have troubles including resource in my pod.
I wanted to know if you have some advice to give.
Here is my situation
1) I have a pod with a .xib file (I wrote the pod)
Here is the podspec :
Pod::Spec.new do |s|
s.name = "MyCBD_BSManagedDocument"
s.requires_arc = true
s.osx.platform = :osx, '10.7'
s.subspec 'MyCBD_BSManagedDocument' do |ss|
ss.source_files = 'Classes/MyCBD_BSManagedDocument/**/*.{h,m}'
end
s.subspec 'Auxiliary classes' do |ss|
ss.subspec 'MyCBDLockManager' do |sss|
sss.source_files = 'Classes/Auxiliary classes/MyCBDLockManager/**/*.{h,m}'
sss.resource_bundle = {'MyCBDLockManager' => 'Classes/Auxiliary
classes/MyCBDLockManager/MyCBDLockManager.xib'}
end
ss.subspec 'MyCBDSafeguardManager' do |sss|
sss.source_files = 'Classes/Auxiliary
classes/MyCBDSafeguardManager/**/*.{h,m}'
end
end
s.resource = "Classes/help_MyCBD_BSManagedDocument.rtf"
s.dependency 'BSManagedDocument', '~>0.3.2'
s.dependency 'CBDFoundationToolKit', '~>0.0.6'
end
2) In this pod, I have a subclass of NSWindowController
There is this method
- (id)initForDocument:(MyCBD_BSManagedDocument *)document
{
self = [super initWithWindowNibName:@"MyCBDLockManager"] ;
if (self)
{
self.theDocument = document ;
[self setMinimalDurationTo:defaultMinimalDuration] ;
}
return self;
}
3) My problem
—> in my toy-project that uses this pod, I don’t have any problem
—> in my real project, I have an error :
-[MyCBDLockManager loadWindow]: failed to load window nib file
'MyCBDLockManager’.
Thanks,
Colas
___
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: Layout-triggered animation
Hi Julian,
The jittering is probably a result of misusing the animator proxy! The animator
proxy is used when you want to directly change properties, for example the
frame of a view, or the alpha value. When you use autolayout, the frame will be
set by the view's layout method, which does not use the animator. Therefore you
must capture the change using setAllowsImplicitAnimation.
When you perform an animation in autolayout, make sure that the views are layed
out before the animation starts. You must call -layoutSubtreeIfNeeded twice.
Try the following:
-(void) expand {
[view.superview layoutSubtreeIfNeeded];
[NSAnimationContext beginGrouping];
[[NSAnimationContext currentContext] setAllowsImplicitAnimation: YES];
[[NSAnimationContext currentContext] setDuration:2];
[NSAnimationContext currentContext].timingFunction = [CAMediaTimingFunction
functionWithName:kCAMediaTimingFunctionLinear];
[view removeConstraint:collapseConstraint];
[view.superview layoutSubtreeIfNeeded];
[NSAnimationContext endGrouping];
}
See also the section "Animating Changes Made by Auto Layout" on the following
page, which has a better example:
https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/AutolayoutPG/AutoLayoutbyExample/AutoLayoutbyExample.html
Furthermore, adding/removing constraints in autolayout is an expensive
operation. The only cheap operation is to change the constant of a constraint.
Maybe it would be possible to do this in your case? Since the constraint you
are removing limits the height, maybe just setting the constraint's constant to
a high value would be faster?
Best wishes,
Jakob
Am 14.04.2014 um 23:42 schrieb Julian :
> I'm animating frame changes from autolayout. Code to trigger the expand is
> shown here. I added QuartzCore.framework to my link libraries, and checked
> layer backing for the window's view.
>
> -(void) expand {
>[NSAnimationContext beginGrouping];
>[[NSAnimationContext currentContext] setAllowsImplicitAnimation: YES];
>[[NSAnimationContext currentContext] setDuration:2];
>[NSAnimationContext currentContext].timingFunction =
> [CAMediaTimingFunction functionWithName:kCAMediaTimingFunctionLinear];
>
>[[view animator] removeConstraint:collapseConstraint];
>
>[[view animator].superview layoutSubtreeIfNeeded];
>[NSAnimationContext endGrouping];
> }
>
> The collapseConstraint is a constraint that limits the view to a short
> height, however there is another constraint that establishes the height at
> its natural height, with a lower priority. collapseConstraint trumps it,
> until it's removed, then boom! layout expands it and moves down the views
> below.
>
> 2 questions:
>
> 1. How do I avoid using -setAllowsImplicitAnimation:? From the
> documentation, it sounded like using the animator proxy automatically
> handled implicit animations, yet if I remove that line, there are no
> animations.
>
> 2. I added a recording of this expand animation, and the collapse
> animation, on youtube here. http://youtu.be/fSu0EqE9mnM
>
> There is significant vertical jitter in the animation of the expanding
> view. For example, the horizontal line, which is an NSBox subview at the
> top edge of the expanding view, flickers in/out of visibility. The other
> lines inside the views that are getting shifted down don't have this
> problem. What might cause this? Perhaps some views inside are changing
> height as the frame changes?
___
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
NSComboBox and sorted list
Hello, I have a typical CoreData application which display my entities in an NSTableView with an NSArrayController and a panel to edit the selected item. I have an entity Book with a NSString attribute type displayed in an NSComboBox. I want the drop down list of the combo box to display the previously chosen types. I have an NSArrayController bind with the Book entity and the managed object context. I can make it works by binding the NSComboBox : Content (or Content Values) -> bookarraycontroller.arrangedobjec...@distinctunionofobjects.type Value -> BookArrayController.selection.type Until this point all is well, but I want the list to be sorted. So I think I have to add a NSArrayController which will maintain the sorted list of types. I try this : TypeListArrayController : Content Array -> bookarraycontroller.arrangedobjec...@distinctunionofobjects.type NSComboBox : Content -> TypeListArrayController.arrangedObjects Value -> BookArrayController.selection.type But with this setting, when I open my document (when the window is displayed) it takes a long time. More than 10min when at first it takes 1s. I check by stopping in the debugger, the stack frame is more than 38000 with huge recursivity. Is there a solution with NSArrayController and binding or I have to implement a data source for the combo box manually ? Frédéric ___ 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
