On Jan 19, 2012, at 1:33 , Ken Thomases wrote:
On Jan 18, 2012, at 6:12 PM, Marcel Weiher wrote:
On Jan 14, 2012, at 18:37 , Kyle Sluder wrote:
Breaking this pattern should be a conscious decision.
I'd say that the opposite is true: in general you should avoid specific
model - view
Does the OP mean slowing down binding's updates instead of slowing down
bindings updates?
The subject doesn't make any sense to me.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to
Hi Kyle,
On Jan 14, 2012, at 18:37 , Kyle Sluder wrote:
On Jan 14, 2012, at 2:53 AM, Marcel Weiher marcel.wei...@gmail.com wrote:
You shouldn't push updates to the UI, the UI should query the model, and it
should do it at human speed, not at whatever speed the machine can manage
to change
On Jan 18, 2012, at 6:12 PM, Marcel Weiher wrote:
On Jan 14, 2012, at 18:37 , Kyle Sluder wrote:
The UI will register as a KVO observer, or as an NSNotification observer, or
perhaps the controller will just call -setObjectValue: directly.
In my experience and opinion most of these are
On Wed, Jan 18, 2012 at 4:33 PM, Ken Thomases k...@codeweavers.com wrote:
On Jan 18, 2012, at 6:12 PM, Marcel Weiher wrote:
On Jan 14, 2012, at 18:37 , Kyle Sluder wrote:
Breaking this pattern should be a conscious decision.
I'd say that the opposite is true: in general you should avoid
I'm not sure if this has already been suggested:
What if you don't update the UI unless the change is at least 1 sec or
1% or certain amount of bytes (whatever suits your needs better)?
Leo
On 1/15/12 12:33:31 AM, Andrew wrote:
Thank you all for the opinions. I left the code as-is in terms
Hi Andrew,
On Jan 13, 2012, at 6:57 , Andrew wrote:
The result of this is that the UI updates really frequently and the
estimated time to complete and the download rate jump around a lot. I
would love it if I could tell cocoa to only update the UI once per
second instead of immediately when
On Jan 14, 2012, at 2:53 AM, Marcel Weiher marcel.wei...@gmail.com wrote:
Hi Andrew,
On Jan 13, 2012, at 6:57 , Andrew wrote:
The result of this is that the UI updates really frequently and the
estimated time to complete and the download rate jump around a lot. I
would love it if I could
Thank you all for the opinions. I left the code as-is in terms of
binding, but changed my rate calculations to use a weighted running
average. After doing so, the estimated seconds tick by one at a time
for the most part, and the rate is more constant. This is a tool for
me and some co-workers, so
On Jan 12, 2012, at 10:57 PM, Andrew wrote:
I have a download controller with an NSMutableArray and an
NSArrayController hooked up to a NSTableView with a view based setup.
My array contains custom download objects. Each of those has a
NSURLDownload instance.
Basically, I am showing a
Why don't you just decouple your UI from the by-the-millisecond download
process? For example, you could update calculated values whenever the value of
bytesDownloaded changes but use a NSTimer to update the display of those values
maybe once or twice a second. The display is then sampling the
I have a download controller with an NSMutableArray and an
NSArrayController hooked up to a NSTableView with a view based setup.
My array contains custom download objects. Each of those has a
NSURLDownload instance.
Basically, I am showing a browser-download like interface with size
downloaded,
The result of this is that the UI updates really frequently and the
estimated time to complete and the download rate jump around a lot. I
would love it if I could tell cocoa to only update the UI once per
second instead of immediately when the property key changes.
I don't believe there is
13 matches
Mail list logo
