Re: UIView underlying rects for drawRect

[Roland King]

You thought CGContext had it, I thought CALayer had it, neither of them appear 
to have it! 

AFAICT UIView is clearing the entire rectangle before drawing, so that idea 
doesn’t work either. That was a good way to confirm I was on the wrong road so 
thanks. 

So I implemented the code to capture setNeedsDisplayInRect(), drawRect() etc 
and ensure only one contiguous rectangle goes to the setNeedsDisplayInRect at a 
time, if there’s another one it waits until drawRect() finishes and then queues 
that one up. The results were good until they weren’t and I’m really at a loss 
to explain some of the oddities I saw. It was never going to be stable enough 
for real use so that idea got tossed. 

Current workaround it not to take things off the back, it’s history, I don’t 
really care, and the code moves the view along anyway so it quickly gets 
clipped and every few minutes the view is moved to a new chunk of data (it’s 
like a horizontal scroll view where only 1.5 screens wide of data is shown at a 
time which are incrementally drawn and then moved to a new chunk every few 
minutes with one single redraw). 

I think a better plan for this whole thing is to use a CALayer with a 
persistent bitmap for the graph I’m drawing. 

Currently I’m seeing a new point come in, working out what that is in view 
coordinates, calling setNeedsDisplayinRect() on that, then in drawRect I’m 
converting back to time coordinates, padding out each side so I definitely 
redraw the whole area cleared including the fuzzy edges of lines a point or two 
over on the display, then drawing. This is probably nowhere near as efficient 
as possible. 

If I use a CALayer with a bitmap I can put a point on the bitmap asynchronously 
as soon as it comes in, one point, or one tiny line segment from the previous 
point, I can do my own clearing when they expire and then all I have to do is 
arrange the bitmap to be blitted onto the CALayer’s content on a regular basis 
for update and sort out some full redraw stuff on bounds change stuff. 

What’s the right way to synchronise the update of the content property of a 
CALayer? I could do it every time I add a point, but that sounds a bit 
unnecessary. Is this where I use CADisplayLink? Is there a recommended format 
for the bitmap which eases the work the CPU/GPU has to do to transfer it to and 
from the layer? 8 bit with alpha is all I really need for the plot but if 
that’s going to trigger a huge conversion every time it’s run through 
CGBitmapContextCreateImage() and stuffed on the layer I’ll use something else. 

Sigh .. I feel a few hours of pain coming up. 



> On 5 Dec 2015, at 18:59, Mike Abdullah  wrote:
> 
> I thought CGContext had API to tell you the rects being drawn, but can’t see 
> that now, so I think I imagined it!
> 
> I’d say your next port of call is to ascertain whether the system is smart 
> enough to be only drawing the required area or not. There are debugging tools 
> to show you the portions of the screen being updated — does that suggest the 
> entire view is being redrawn, or just the ends?
> 
> Mike.
> 
>> On 5 Dec 2015, at 03:02, Roland King  wrote:
>> 
>> NSView has a method getRectsBeingDrawn:count: which gives you the actual 
>> rects being drawn in a drawRect: call. Is there something equivalent for a 
>> UIView? Does UIView even do as I believe NSView does and only invalidate 
>> just the areas passed to setNeedsDisplayInRect:, meaning those are the only 
>> areas you actually need to redraw, or does it blow away the entire 
>> containing rectangle so you must repaint the entire area?  
>> 
>> I have a time-series view which only invalidates a tiny sliver of view which 
>> changed and only draws that in drawRect:. However when the series gets long 
>> enough it trims the left hand end, so two tiny slivers of view are 
>> invalidated, one at each end, drawRect: coalesces them into one rect the 
>> entire size of the window and the whole series redraws on every iteration. I 
>> spotted this when I left the simulator running for an hour and the fans 
>> suddenly started spinning up. 
>> 
>> I can work around it by overriding setNeedsDisplayInRect: and queuing up 
>> non-contiguous updates, releasing them only when drawRect has been called, 
>> but it would be nice not to have to. I suspect I’m SOL on this one. 
>> ___
>> 
>> 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/mabdullah%40karelia.com
>> 
>> This email sent to mabdul...@karelia.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

Re: debugging questions on NSScroll view with NSSpllit view

[Ken Thomases]

Hi,

On Dec 5, 2015, at 3:16 PM, yu...@aim.com wrote:
> 
> I am trying to develop a Finder app like the mac Finder.  I am using NSSplit 
> view adding one vertical panel at a time dynamically in the code.
> basically, trying to simulate file directories drill down.  I am also having 
> an NSScroll View to contain the NSSplit view as its document view so that i 
> can use the horizontal scroll bar to scroll the nssplit view horizontally.
> 
> My problem is, as the nssplit view grows one panel at a time and eventually 
> exceed the width of the document view, the horizontal scroll bar does NOT 
> appear when I try to use the mouse to scroll horizontally.  Each panel in the 
> split view is a NSTableView.  
> 
> So, any hints on how to debug this ? I just want to start from somewhere and 
> debug into it.  

First, there's a built-in control for a view like the Finder's Columns view: 
NSBrowser.  It's fairly old and crufty, but it might be easiest to start with 
that.
https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Browser/Browser.html

Second, if you want to keep working on the approach you're using, you need to 
tell us if you're using auto layout or not.  If you are, what constraints, if 
any, have you established between the split view and the enclosing scroll 
view's clip view?

In general, how did you set up the view hierarchy?  Did you build it 
programmatically or in Interface Builder?  Can you provide a text diagram of 
the hierarchy?

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

debugging questions on NSScroll view with NSSpllit view

[yuleo]

Hi,
I am new to cocoa app development.  I have a  question about debugging NSScroll 
view.


I am trying to develop a Finder app like the mac Finder.  I am using NSSplit 
view adding one vertical panel at a time dynamically in the code.
basically, trying to simulate file directories drill down.  I am also having an 
NSScroll View to contain the NSSplit view as its document view so that i can 
use the horizontal scroll bar to scroll the nssplit view horizontally.


My problem is, as the nssplit view grows one panel at a time and eventually 
exceed the width of the document view, the horizontal scroll bar does NOT 
appear when I try to use the mouse to scroll horizontally.  Each panel in the 
split view is a NSTableView.  


So, any hints on how to debug this ? I just want to start from somewhere and 
debug into it.  


Appreciate any help, pointers !


thanks!
leo
___

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: NSDocument and NSViewControllers

[Rick Mann]

> On Dec 5, 2015, at 12:40 , Quincey Morris 
>  wrote:
> 
> On Dec 5, 2015, at 12:20 , Rick Mann  wrote:
>> 
>> I'll probably make the document a delegate of the view controller so it can 
>> be informed of changes to the model.
> 
> This may not apply to your app, but what I usually end up doing in an app of 
> any complexity is have (essentially) two data models. The “real” one belongs 
> to the document. Then there’s a “derived” data model (usually in the window 
> controller in the past, but possibly in the new, enhanced view controllers in 
> the future) which rearranges the document data model suitably for the 
> particular UI that the particular window UI finds convenient.
> 
> This is kind of duplicate effort (though not duplicate data, mostly, because 
> the “derived” data model really is only a wrapper around the real one), but 
> it tends to simplify the UI code a lot. For example, if the real data model 
> is flat but the UI displays the data hierarchically, it may be easier to have 
> an outline view connected to a hierarchical data structure. Or if data model 
> values need to be transformed into displayable strings in customizable ways, 
> it can be done in the derived data model.

Not a bad way to look at it. I'll see what makes sense as I go forward. This is 
a utility app for use inside my company, so it's inevitably going to grow 
organically. I can just foresee many of the aspects right now.

> 
> Or (and this can be a fairly important issue) undo groupings are really 
> structured by the UI, even though undo actions are associated with the 
> document. It often makes more sense to have the window controller decide how 
> to package (and how to name) undoable sequences, rather than leaving it to 
> the granularity of document model property updates.

Yeah, I think you're right about this.

-- 
Rick Mann
rm...@latencyzero.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: NSDocument and NSViewControllers

[Quincey Morris]

On Dec 5, 2015, at 12:20 , Rick Mann  wrote:
> 
> I'll probably make the document a delegate of the view controller so it can 
> be informed of changes to the model.

This may not apply to your app, but what I usually end up doing in an app of 
any complexity is have (essentially) two data models. The “real” one belongs to 
the document. Then there’s a “derived” data model (usually in the window 
controller in the past, but possibly in the new, enhanced view controllers in 
the future) which rearranges the document data model suitably for the 
particular UI that the particular window UI finds convenient.

This is kind of duplicate effort (though not duplicate data, mostly, because 
the “derived” data model really is only a wrapper around the real one), but it 
tends to simplify the UI code a lot. For example, if the real data model is 
flat but the UI displays the data hierarchically, it may be easier to have an 
outline view connected to a hierarchical data structure. Or if data model 
values need to be transformed into displayable strings in customizable ways, it 
can be done in the derived data model.

Or (and this can be a fairly important issue) undo groupings are really 
structured by the UI, even though undo actions are associated with the 
document. It often makes more sense to have the window controller decide how to 
package (and how to name) undoable sequences, rather than leaving it to the 
granularity of document model property updates.

___

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: NSDocument and NSViewControllers

[Rick Mann]

> On Dec 5, 2015, at 05:24 , Jerry Krinock  wrote:
> 
> 
>> On 2015 Dec 04, at 16:32, Rick Mann  wrote:
>> 
>> I have an NSViewController subclass and SCNView subclass. I can get at the 
>> document from the NSViewController subclass via a rather cumbersome "let doc 
>> = self.view.window?.windowController?.document as? ModelDocument”
> 
> I just happened to have done that yesterday afternoon.  It seemed like the 
> most logical approach to me.  “Going to the source”, even via a circuitous 
> key path, is usually more robust than adding properties for convenience.
> 
> Just make sure you can guarantee that the window and view have been loaded 
> previously in your situation, or you’ll get nil.  I’ve also used that as a 
> key path in Cocoa Bindings.  In that case, it’s usually OK to return nil 
> initially.

Depending on how this shapes up, I think I'm going to try to go the opposite 
route. That is, there will be a top-level view controller subclass that knows 
how to deal with one aspect of the document data. I will try to package up that 
aspect in a model object(s), and hand that to the view controller when its 
window gets created. The ideas is that the NSDocument is a client of the view 
controller, not the other way around. I'll probably make the document a 
delegate of the view controller so it can be informed of changes to the model.

This approach makes it easier to re-use the view controller in another app.

I think.


-- 
Rick Mann
rm...@latencyzero.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: ARC and IBOutlet - strong vs weak......

[Clark Cox]

> On Dec 4, 2015, at 12:05, Mike Throckmorton  
> wrote:
> 
> Quincey Morris Friday, December 4, 2015 10:04 AM
> 
>> That sounds like a definitive answer. So you’re asking us because … why?
> 
> Definitive for the leading question, but not the secondary:
> 
>> If strong, do I need to set the outlets to nil in the corresponding dealloc 
>> method?
> 
> I had tested this and it appeared as if I did not need to nil out the 
> reference at dealloc (this makes sense) but is it an on purpose behaviour 
> that is supported by the ARC implementation or is it some side effect that 
> may go away?
> 
> Most likely the former, but who likes to leave potential down the road a** 
> biters lying around.

Strong instance variables are automatically released on deallocation. There is 
no need to set them to nil in dealloc (in fact, if all your dealloc is doing is 
setting instance variables to nil, I would recommend not having a dealloc 
method at all).
___

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: NSDocument and NSViewControllers

[Jerry Krinock]

> On 2015 Dec 04, at 16:32, Rick Mann  wrote:
> 
> I have an NSViewController subclass and SCNView subclass. I can get at the 
> document from the NSViewController subclass via a rather cumbersome "let doc 
> = self.view.window?.windowController?.document as? ModelDocument”

I just happened to have done that yesterday afternoon.  It seemed like the most 
logical approach to me.  “Going to the source”, even via a circuitous key path, 
is usually more robust than adding properties for convenience.

Just make sure you can guarantee that the window and view have been loaded 
previously in your situation, or you’ll get nil.  I’ve also used that as a key 
path in Cocoa Bindings.  In that case, it’s usually OK to return nil initially.
___

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: Swift screensavers in Ubuntu?

[dangerwillrobinsondanger]

They open sourced a heck of a lot though. 
There's enough there to likely build a web server in no time for example. Or 
modules for one. 

Sent from my iPhone

> On Dec 5, 2015, at 8:45 AM, SevenBits  wrote:
> 
>> On Friday, December 4, 2015, Juanjo Conti  wrote:
>> 
>> Now that Swift is open source and runs on Ubuntu, do you think a Swift Mac
>> OS X screensaver could run as a screensaver in Ubuntu? What about a GUI
>> used to config the screensaver?
> 
> 
> What Apple open sourced was Swift the language, not Swift "the amazing
> thing you can make apps in now". Cocoa isn't included in the open source
> version, neither is most features you need to make it do applications.
> 
> While there will likely be some effort by someone to make some sort of
> bridge, Apple will certainly never release it or support it.
> 
> 
>> 
>> Yes, I'm asking if our screensaver https://screensaver.ninja/ could run in
>> Ubuntu :)
>> 
>> --
>> 
>> Juanjo Conti http://goog_2023646312>@carouselapps.com
>> >>
>> 
>> Software Engineer - Carousel Apps 
>> 
>> --
>> Carousel Apps Limited, registered in England & Wales with registered number
>> 7689440 and registered office 20-22 Wenlock Road, London, N1 7GU, United
>> Kingdom. Any communication sent by or on behalf of Carousel Apps or any of
>> its subsidiary, holding or affiliated companies or entities is confidential
>> and may be privileged or otherwise protected. If you receive it in error
>> please inform us and then delete it from your system. You should not copy
>> it or disclose its contents to anyone. Messages sent to and from Carousel
>> Apps may be monitored to ensure compliance with our internal policies and
>> to protect our business. Emails are not secure and cannot be guaranteed to
>> be error free. Anyone who communicates with us by email is taken to accept
>> these risks.
>> ___
>> 
>> 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/sevenbitstech%40gmail.com
>> 
>> This email sent to sevenbitst...@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/dangerwillrobinsondanger%40gmail.com
> 
> This email sent to dangerwillrobinsondan...@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: UIView underlying rects for drawRect

[Mike Abdullah]

I thought CGContext had API to tell you the rects being drawn, but can’t see 
that now, so I think I imagined it!

I’d say your next port of call is to ascertain whether the system is smart 
enough to be only drawing the required area or not. There are debugging tools 
to show you the portions of the screen being updated — does that suggest the 
entire view is being redrawn, or just the ends?

Mike.

> On 5 Dec 2015, at 03:02, Roland King  wrote:
> 
> NSView has a method getRectsBeingDrawn:count: which gives you the actual 
> rects being drawn in a drawRect: call. Is there something equivalent for a 
> UIView? Does UIView even do as I believe NSView does and only invalidate just 
> the areas passed to setNeedsDisplayInRect:, meaning those are the only areas 
> you actually need to redraw, or does it blow away the entire containing 
> rectangle so you must repaint the entire area?  
> 
> I have a time-series view which only invalidates a tiny sliver of view which 
> changed and only draws that in drawRect:. However when the series gets long 
> enough it trims the left hand end, so two tiny slivers of view are 
> invalidated, one at each end, drawRect: coalesces them into one rect the 
> entire size of the window and the whole series redraws on every iteration. I 
> spotted this when I left the simulator running for an hour and the fans 
> suddenly started spinning up. 
> 
> I can work around it by overriding setNeedsDisplayInRect: and queuing up 
> non-contiguous updates, releasing them only when drawRect has been called, 
> but it would be nice not to have to. I suspect I’m SOL on this one. 
> ___
> 
> 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/mabdullah%40karelia.com
> 
> This email sent to mabdul...@karelia.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