Re: wits end with nsview and nsrectfill()
Hi After trying out everything, I finally found how to remove that difference in background color. I couldn’t find any rationale in this patch effect, so I turned the outline selection highlight to none (regular, i.e. plain white also works). So if you take a view-based outline view (or maybe table view as well) and fill a table column’s view’s background with NSRectFill() or any other and add as sub view a transparent text field, upon refresh the text field and the rest of the background will differ in color as long as selection highlight is set to “Source List”. As if source list color superimposes on the area other than the text field. But I still can’t understand the nitty gritty of this. But in this solution, the outline view loses source list style color in its appearance. Also I found that setting the background color does not lead to this patch. Is there anyway I can still get the same source list style color in its appearance and not have this patch? If setting background color is the solution, how to get source list color without applying it? Any ideas? Wishes, Navneet On 04-Dec-2014, at 8:13 pm, Navneet Kumar navnee...@me.com wrote: Hi, The problem is not there if I create a new project and add a text field as subview to a custom view with a background color. There is no difference in color in text field and rest of the area. And also this wasn’t there a couple of months ago, and not using git or subversion, I am not able to locate what I did to get to the current problem. Any ideas what could be happening? Can I get clear on some things?: 1. If a view is send the msg -display, is the msg sent to all its subviews without exception? 2. Could it be that so many views when trying to display (in the main thread of course), could block some views from refreshing altogether? If I could get a few pointers, I might get to the bottom of this problem. Best, Navneet On 01-Dec-2014, at 11:28 am, Navneet Kumar navnee...@me.com wrote: Thanks for the responses. The problem is still there. I don’t need to dynamically add or remove views and was following the wrong way to setup view hierarchy in drawRect:. I have changed it to the following order: initWithFrame: then -(void)setupSubViews in all related classes. So in app delegate I call initWithFrame: and then immediately setupSubViews. The entire view comes to front a lot later. The view hierarchy is complex, starting with a view based outline view, then child of a root node has box views (2 in a row). Every box has this bottom view which has this problem. I’m adding a non-selectable, non-editable text field with setDrawsBackground set to NO, as a subview to this bottom view. In drawRect:, I’m just using NSRectFill() with: NSColor *bgColor = [[NSColor blackColor]blendedColorWithFraction:0.25 ofColor:[NSColor whiteColor]]; [bgColor set]; NSRectFill([self bounds]); And initially the background is same in text field and rest of the area. but on refresh, the rest of the area becomes darker, which shouldn’t be as NSRectFill() is supposed to draw opaquely. Thanks, Navneet On 30-Nov-2014, at 11:24 pm, Kyle Sluder k...@ksluder.com wrote: On Nov 30, 2014, at 9:30 AM, Navneet Kumar navnee...@me.com wrote: Hi, I have a custom view in which I am setting the background using NSRectFill() in drawRect:. You’re aware that this function is only really suitable for drawing opaque colors, yes? If you NSRectFill() with a transparent color, it will not blend that color with the existing backing store. Instead, it will replace all pixels in that rect with transparent ones, obliterating any drawing performed by ancestor views in the hierarchy. I am also adding a text field as subview in this method. This is not allowed. -drawRect: is for drawing, not mutating your view hierarchy. If you want to position/install views at the last possible second before the drawing pass, use -viewWillDraw. But you have not offered any reasons why you need to dynamically add or remove views at all, much less in tandem with the drawing pass. --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/navneet_6%40me.com This email sent to navnee...@me.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/navneet_6%40me.com This email sent to navnee...@me.com
Re: wits end with nsview and nsrectfill()
On Dec 13, 2014, at 10:20 AM, Navneet Kumar navnee...@me.com wrote: So if you take a view-based outline view (or maybe table view as well) and fill a table column’s view’s background with NSRectFill() or any other and add as sub view a transparent text field, upon refresh the text field and the rest of the background will differ in color as long as selection highlight is set to “Source List”. As if source list color superimposes on the area other than the text field. I believe the Source List setting means that an NSVisualEffectView lies behind the text field. The only documentation I have been able to find about NSVisualEffectView is (1) in the AppKit release note for Yosemite (which apparently is still only available for Developer Preview 5) and (2) in the NSVisualEffectView reference document. In one of those documents, there is some discussion of what you have to do to avoid unwanted color changes in text fields with NSVisualEffectView in back. -- Bill Cheeseman - b...@cheeseman.name ___ 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: wits end with nsview and nsrectfill()
On 13 Dec 2014, at 16:45, Bill Cheeseman wjcheese...@gmail.com wrote: On Dec 13, 2014, at 10:20 AM, Navneet Kumar navnee...@me.com wrote: So if you take a view-based outline view (or maybe table view as well) and fill a table column’s view’s background with NSRectFill() or any other and add as sub view a transparent text field, upon refresh the text field and the rest of the background will differ in color as long as selection highlight is set to “Source List”. As if source list color superimposes on the area other than the text field. I believe the Source List setting means that an NSVisualEffectView lies behind the text field. The only documentation I have been able to find about NSVisualEffectView is (1) in the AppKit release note for Yosemite (which apparently is still only available for Developer Preview 5) and (2) in the NSVisualEffectView reference document. In one of those documents, there is some discussion of what you have to do to avoid unwanted color changes in text fields with NSVisualEffectView in back. I think you override -(BOOL) allowsVibrancy to return NO to turn off the NSVisualEffectView’s … err … effect. Cheers, -- Uli Kusterer “The Witnesses of TeachText are everywhere...” http://zathras.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: wits end with nsview and nsrectfill()
On Dec 13, 2014, at 3:08 PM, Uli Kusterer witness.of.teacht...@gmx.net wrote: I believe the Source List setting means that an NSVisualEffectView lies behind the text field. The only documentation I have been able to find about NSVisualEffectView is (1) in the AppKit release note for Yosemite (which apparently is still only available for Developer Preview 5) and (2) in the NSVisualEffectView reference document. In one of those documents, there is some discussion of what you have to do to avoid unwanted color changes in text fields with NSVisualEffectView in back. I think you override -(BOOL) allowsVibrancy to return NO to turn off the NSVisualEffectView’s … err … effect. I've found a number of circumstances where that doesn't seem to work, but it's hard to tell just what's going on because the documentation is so skimpy. I am unable to get much that is helpful out of the two WWDC 2014 sessions on advanced Yosemite UI, either. -- Bill Cheeseman - b...@cheeseman.name ___ 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: wits end with nsview and nsrectfill()
On 14 Dec 2014, at 2:20 am, Navneet Kumar navnee...@me.com wrote: So if you take a view-based outline view (or maybe table view as well) and fill a table column’s view’s background with NSRectFill() or any other and add as sub view a transparent text field, upon refresh the text field and the rest of the background will differ in color as long as selection highlight is set to “Source List”. As if source list color superimposes on the area other than the text field. But I still can’t understand the nitty gritty of this. Wait. In your original posting you wrote this: I have a custom view in which I am setting the background using NSRectFill() in drawRect:. I am also adding a text field as subview in this method. The textfield is non-selectable, non-editable and is not set to draw background. So you were talking about an NSTableView or NSOutlineView all along, NOT a custom view? You can't write custom view and really mean table/outline view, then expect a coherent response. The two are not in any way equivalent. Expecially in Yosemite where all sorts of gratutious non-useful effects have been imposed on us to waste processor cycles and give us other pointless headaches. If you are filling the background of a table column using NSRectFill then you should simply stop doing that. The view handles its own background drawing. You are only responsible for setting up the content of the row vews, and if one of those is a custom view (NOT the row view itself, which is assumed to be merely a transparent host for the other views within it), then you can paint the background, allowing for the new flags and features you need to deal with in Yosemite. --Graham ___ 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: wits end with nsview and nsrectfill()
On 30 Nov 2014, at 18:30, Navneet Kumar navnee...@me.com wrote: I have a custom view in which I am setting the background using NSRectFill() What is the current compositing mode set on the current graphics context? Have you tried using NSRectFillUsingOperation() and passing NSCompositeCopy to make sure you didn't somehow screw up the current compositing operation setting? in drawRect:. I am also adding a text field as subview in this method. The textfield is non-selectable, non-editable and is not set to draw background. *never* change the view hierarchy in drawRect:. That may work by accident, if you get lucky, but as, while you are inside drawRect:, your parent view is iterating over its subviews, you'll be screwing its state up. It might crash, it might draw one view twice, or seem to skip one. When the view comes to front, the background is same, but when it refreshes, the area apart from the text field becomes a bit darker and the text field area shows the original background, this creates a contrast which I want to get rid of. -- Uli ___ 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: wits end with nsview and nsrectfill()
On 05 Dec 2014, at 13:30, Uli Kusterer witness.of.teacht...@gmx.net wrote: On 30 Nov 2014, at 18:30, Navneet Kumar navnee...@me.com wrote: I have a custom view in which I am setting the background using NSRectFill() What is the current compositing mode set on the current graphics context? Have you tried using NSRectFillUsingOperation() and passing NSCompositeCopy to make sure you didn't somehow screw up the current compositing operation setting? Nevermind. I could'a swrong NSRectFill uses the current compositing operation, but I just checked the docs again and it's documented to use NSCompositeCopy. So unless you're trying to draw transparently, that's not the issue. ___ 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: wits end with nsview and nsrectfill()
Hi, The problem is not there if I create a new project and add a text field as subview to a custom view with a background color. There is no difference in color in text field and rest of the area. And also this wasn’t there a couple of months ago, and not using git or subversion, I am not able to locate what I did to get to the current problem. Any ideas what could be happening? Can I get clear on some things?: 1. If a view is send the msg -display, is the msg sent to all its subviews without exception? 2. Could it be that so many views when trying to display (in the main thread of course), could block some views from refreshing altogether? If I could get a few pointers, I might get to the bottom of this problem. Best, Navneet On 01-Dec-2014, at 11:28 am, Navneet Kumar navnee...@me.com wrote: Thanks for the responses. The problem is still there. I don’t need to dynamically add or remove views and was following the wrong way to setup view hierarchy in drawRect:. I have changed it to the following order: initWithFrame: then -(void)setupSubViews in all related classes. So in app delegate I call initWithFrame: and then immediately setupSubViews. The entire view comes to front a lot later. The view hierarchy is complex, starting with a view based outline view, then child of a root node has box views (2 in a row). Every box has this bottom view which has this problem. I’m adding a non-selectable, non-editable text field with setDrawsBackground set to NO, as a subview to this bottom view. In drawRect:, I’m just using NSRectFill() with: NSColor *bgColor = [[NSColor blackColor]blendedColorWithFraction:0.25 ofColor:[NSColor whiteColor]]; [bgColor set]; NSRectFill([self bounds]); And initially the background is same in text field and rest of the area. but on refresh, the rest of the area becomes darker, which shouldn’t be as NSRectFill() is supposed to draw opaquely. Thanks, Navneet On 30-Nov-2014, at 11:24 pm, Kyle Sluder k...@ksluder.com wrote: On Nov 30, 2014, at 9:30 AM, Navneet Kumar navnee...@me.com wrote: Hi, I have a custom view in which I am setting the background using NSRectFill() in drawRect:. You’re aware that this function is only really suitable for drawing opaque colors, yes? If you NSRectFill() with a transparent color, it will not blend that color with the existing backing store. Instead, it will replace all pixels in that rect with transparent ones, obliterating any drawing performed by ancestor views in the hierarchy. I am also adding a text field as subview in this method. This is not allowed. -drawRect: is for drawing, not mutating your view hierarchy. If you want to position/install views at the last possible second before the drawing pass, use -viewWillDraw. But you have not offered any reasons why you need to dynamically add or remove views at all, much less in tandem with the drawing pass. --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/navneet_6%40me.com This email sent to navnee...@me.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: wits end with nsview and nsrectfill()
On 5 Dec 2014, at 1:43 am, Navneet Kumar navnee...@me.com wrote: 1. If a view is send the msg -display, is the msg sent to all its subviews without exception? 2. Could it be that so many views when trying to display (in the main thread of course), could block some views from refreshing altogether? If I could get a few pointers, I might get to the bottom of this problem. Are *you* sending the -display message? Why? It's very unusual to do that. The normal way to update a view is to mark as needing display with -setNeedsDisplay:, then the main loop causes redisplay as part of its normal functioning. Note that many types of view subclass, such as controls (including text fields) invoke -setNeedsDisplay: as part of setting a new value, so you only need to do this for custom view subclasses or other special requirements. Unlike -display, it's harmless to over invoke -setNeedsDisplay, as there will still only be one redisplay per main cycle. If your code is calling -display directly, then it's probable that views are getting repainted too much, and that's often a problem for anything containing text or transparent backgrounds, because pixels get painted over more than once, darkening them. Sounds like what you could be seeing. TL; DR: if you're invoking -display, you're doing it wrong™ --Graham ___ 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
wits end with nsview and nsrectfill()
Hi, I have a custom view in which I am setting the background using NSRectFill() in drawRect:. I am also adding a text field as subview in this method. The textfield is non-selectable, non-editable and is not set to draw background. When the view comes to front, the background is same, but when it refreshes, the area apart from the text field becomes a bit darker and the text field area shows the original background, this creates a contrast which I want to get rid of. The view is set to return YES to isOpaque. I have tried a lot of things but to no avail. I have tried CGContext approach to fill rect. I also tried setting the color before NSRectFill() to a opaque color as well. The problem is gone if I removeFromSuperview and create the custom view again and again on each drawRect: of the super view. But this consumes a lot of CPU. An image showing the contrast is attached herewith. Please help. Best, Navneet ___ 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: wits end with nsview and nsrectfill()
On 30 Nov 2014, at 17:30, Navneet Kumar navnee...@me.com wrote: Hi, I have a custom view in which I am setting the background using NSRectFill() in drawRect:. I am also adding a text field as subview in this method. I suspect there-in you have your problem. -drawRect: is for drawing. Do not modify the view hierarchy from within it. ___ 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: wits end with nsview and nsrectfill()
Why aren't you creating the subview in -initWithFrame: or in a nib/storyboard? The purpose of -drawRect: is solely to [re-]draw the contents of one view, not build a view hierarchy. I expect that modifying the view hierarchy while in the middle of a drawing cycle is leaving views in an inconsistent state. On Nov 30, 2014, at 9:30 AM, Navneet Kumar navnee...@me.com wrote: I have a custom view in which I am setting the background using NSRectFill() in drawRect:. I am also adding a text field as subview in this method. The textfield is non-selectable, non-editable and is not set to draw background. When the view comes to front, the background is same, but when it refreshes, the area apart from the text field becomes a bit darker and the text field area shows the original background, this creates a contrast which I want to get rid of. The view is set to return YES to isOpaque. I have tried a lot of things but to no avail. I have tried CGContext approach to fill rect. I also tried setting the color before NSRectFill() to a opaque color as well. The problem is gone if I removeFromSuperview and create the custom view again and again on each drawRect: of the super view. But this consumes a lot of CPU. An image showing the contrast is attached herewith. Please help. Best, Navneet ___ 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: wits end with nsview and nsrectfill()
Thank you Steve and Mike. I'll try it tomorrow and post the result here. Wishes, Navneet Sent from my iPhone On 30-Nov-2014, at 11:13 pm, Steve Christensen puns...@mac.com wrote: Why aren't you creating the subview in -initWithFrame: or in a nib/storyboard? The purpose of -drawRect: is solely to [re-]draw the contents of one view, not build a view hierarchy. I expect that modifying the view hierarchy while in the middle of a drawing cycle is leaving views in an inconsistent state. On Nov 30, 2014, at 9:30 AM, Navneet Kumar navnee...@me.com wrote: I have a custom view in which I am setting the background using NSRectFill() in drawRect:. I am also adding a text field as subview in this method. The textfield is non-selectable, non-editable and is not set to draw background. When the view comes to front, the background is same, but when it refreshes, the area apart from the text field becomes a bit darker and the text field area shows the original background, this creates a contrast which I want to get rid of. The view is set to return YES to isOpaque. I have tried a lot of things but to no avail. I have tried CGContext approach to fill rect. I also tried setting the color before NSRectFill() to a opaque color as well. The problem is gone if I removeFromSuperview and create the custom view again and again on each drawRect: of the super view. But this consumes a lot of CPU. An image showing the contrast is attached herewith. Please help. Best, Navneet ___ 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: wits end with nsview and nsrectfill()
On Nov 30, 2014, at 9:30 AM, Navneet Kumar navnee...@me.com wrote: Hi, I have a custom view in which I am setting the background using NSRectFill() in drawRect:. You’re aware that this function is only really suitable for drawing opaque colors, yes? If you NSRectFill() with a transparent color, it will not blend that color with the existing backing store. Instead, it will replace all pixels in that rect with transparent ones, obliterating any drawing performed by ancestor views in the hierarchy. I am also adding a text field as subview in this method. This is not allowed. -drawRect: is for drawing, not mutating your view hierarchy. If you want to position/install views at the last possible second before the drawing pass, use -viewWillDraw. But you have not offered any reasons why you need to dynamically add or remove views at all, much less in tandem with the drawing pass. --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: wits end with nsview and nsrectfill()
Thanks for the responses. The problem is still there. I don’t need to dynamically add or remove views and was following the wrong way to setup view hierarchy in drawRect:. I have changed it to the following order: initWithFrame: then -(void)setupSubViews in all related classes. So in app delegate I call initWithFrame: and then immediately setupSubViews. The entire view comes to front a lot later. The view hierarchy is complex, starting with a view based outline view, then child of a root node has box views (2 in a row). Every box has this bottom view which has this problem. I’m adding a non-selectable, non-editable text field with setDrawsBackground set to NO, as a subview to this bottom view. In drawRect:, I’m just using NSRectFill() with: NSColor *bgColor = [[NSColor blackColor]blendedColorWithFraction:0.25 ofColor:[NSColor whiteColor]]; [bgColor set]; NSRectFill([self bounds]); And initially the background is same in text field and rest of the area. but on refresh, the rest of the area becomes darker, which shouldn’t be as NSRectFill() is supposed to draw opaquely. Thanks, Navneet On 30-Nov-2014, at 11:24 pm, Kyle Sluder k...@ksluder.com wrote: On Nov 30, 2014, at 9:30 AM, Navneet Kumar navnee...@me.com wrote: Hi, I have a custom view in which I am setting the background using NSRectFill() in drawRect:. You’re aware that this function is only really suitable for drawing opaque colors, yes? If you NSRectFill() with a transparent color, it will not blend that color with the existing backing store. Instead, it will replace all pixels in that rect with transparent ones, obliterating any drawing performed by ancestor views in the hierarchy. I am also adding a text field as subview in this method. This is not allowed. -drawRect: is for drawing, not mutating your view hierarchy. If you want to position/install views at the last possible second before the drawing pass, use -viewWillDraw. But you have not offered any reasons why you need to dynamically add or remove views at all, much less in tandem with the drawing pass. --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
