Re: [OT] Sync vs ASync Server Comms

[Dave]

On 22 Feb 2013, at 18:18, Quincey Morris wrote:


On Feb 22, 2013, at 08:32 , Dave  wrote:

As long as you are not running on the main thread there is no real  
difference between a Sync or ASync operation as far as any of the  
issues you mention above are concerned.


You're correct that, at some level, using synchronous methods on a  
background thread is an equivalent to using async methods on the  
main thread (or any other thread, for that matter).


The question is you have two black box methods that do the same  
thing, one has Sync in it's name the other has ASync in it's name.  
Given everything else is equal (which is is in this case), which  
one would you choose and why?


The main advantage of synchronous methods on a background thread is  
simplicity and/or conciseness of the code. In some cases, that can  
be a big enough "win" to choose this approach over the other.


Yes, I agree, as soon as it starts to get complicated, ASync Delegate  
callbacks start to get out of control and you're left with a giant  
mess if you are not careful!


Comparatively, the main advantage of async methods is their modest  
resource requirements, which means they may scale better. For  
example, you could likely perform thousands of (individually slow)  
network accesses simultaneously this way, while you really wouldn't  
want to create thousands of threads to do the same thing with sync  
calls. (That's an artificial and impractical example, of course.)


However, there's a whole boatload of disadvantages to using the  
sync calls which are purely situational, and can only be evaluated  
in a particular app design context. For example:


-- Very often, your background thread will need to trigger updates  
to the UI, and it must "switch" to the main thread to do this. That  
may introduce asynchronous behavior into the background thread,  
which in turn may subvert its entire approach.


True, but there are ways to avoid this.



-- Threads blocked in a synchronous method can't cancel themselves  
or respond to environmental changes like memory pressure until they  
return.


True, but you can set a time-out running and if you keep track of  
which processes are "waiting" you can wake them up and have them  
cancel themselves.


-- Since blocks were introduced, the frameworks have rapidly  
embraced blocks-based asynchronous patterns. That means that some  
of the most recent, capable and convenient APIs are async-only.


The problem with using Blocks is that on every implementation, I seen  
so much identical code that has been cut and pasted. The way around  
this is to have the Code Block call a common method, but this then  
spreads the code out again. Ironically (or maybe not so), ASync code  
with code blocks makes it much easier to convert the ASync Method  
into a a Sync method though.


-- An interesting example I came across recently is AVFoundation,  
where there is API for loading asset object properties  
asynchronously. The documentation notes that you can do it  
synchronously in a background thread in OS X if you want, but you  
should not try doing that on iOS because you're likely to have your  
app killed by the OS for being non-responsive.


So, there's something of a trend -- currently -- towards  
asynchronicity. My suggestion would be to use the synchronous  
background approach if/when that truly simplifies the  
implementation, but when your task becomes more complex switch over  
to the better supported async approach.


Yes and as I said, you can a turn an ASync method into Sync easily  
enough if you want to.


All the Best
Dave









___

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

Programmatic Core Data Migration

[tshanno]

I'm at an early stage of developing my application and up to this point 
whenever I've made a changes to the core data model, I've simply trashed the 
old one and reimported default data.  However I'm now at a point where I'd like 
to begin using the thing and, as a result, I want to keep the old data and use 
core data versioning and migration.  I can't imagine that lightweight migration 
won't be fine for whatever changes I make from here on out.

Many will think it foolish, I suppose, but I generated my object model 
completely programmatically.  That is, I didn't use interface builder.  
Unfortunately, as far as I can tell, the information and instructions in the 
Core Data Model Versioning and Data Migration Programming Guide seem to assume 
that you did use interface builder and, therefore, suggest you create a new 
version of the model using Editor ->  Add Model Version.  I could do this but, 
of course, I'd simply have two blank graphs.  :)

So it isn't entirely clear to me what I should do here.  Should I simply simply 
alter the version I have in my code, add the necessary options for lightweight 
migration?  Xcode will therefore have the new version in code and the old 
version indirectly in the form of the old persistent store.  Is that all it 
needs?

Thanks for any help here.

Tom S.
___

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: [OT] Sync vs ASync Server Comms

[Uli Kusterer]

Generally, using 4 exclamation marks in a sentence (or three question marks, 
come to think of it) is considered "yelling".

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de

On Feb 22, 2013, at 8:32 AM, Dave  wrote:
> Of course there are threading "issues" Having delegates doesn't stop that

On Feb 24, 2013, at 1:26 PM, Dave  wrote:
> Who's yelling??? Not me and I've re-read what I wrote and I can't see 
> anything "rude", and I wasn't really asking for advice, I was starting a 
> discussion, that's why I put [OT] in the subject field.


___

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: [OT] Sync vs ASync Server Comms

[Steve Sisak]

At 12:26 PM + 2/24/13, Dave wrote:
I think I see what you mean, but I'd argue that there are still 
"threading" issues, the OS will create the Background Threads and 
take care of calling you back on the main thread, I agree, and, if 
that's all you were doing, it might be said to have "No Threading 
Issues", but, for instance, if the first ASync call, needs data to 
use on a later call, then there may well be "Threading Issues". 
Example 1:


Kick off ASync Operation A to get DataA.
Kick off ASync Operation B to get DataB.
Kick off ASync Operation C using DataA and DataB - You need to 
"worry" about "threading" (or at least the consequences of threading 
at this point).


Just to be pedantic, that's a dependency issue but, since the async 
operations always complete on the main thread (or the thread you told 
them to), you don't have to worry about being interrupted while 
manipulation the results.


In the case above, you issue operations A and B, cache the results as 
they come back, and as soon as you have both, kick off operation C.


...or you can just use NSOperation, set up your dependencies, and let 
the OS do it:


Created A, B, C, make C dependent on A, B, submit all of them to an 
NSOperationQueue and wait for C to complete (or put your completion 
code on a block dependent on C -- NSBlockOperation makes this really 
easy.


See the Concurrency Programming Guide:



Note that most of this discussion is covered in it.

In fact, I'd argue that using Sync on a user created Background 
thread would after a very small learning curve, actually result in 
less "Threading" issues but may well suffer performance wise. For 
instance in pseudo code, Example 1 would look something like:


You have something which looks like a "simple learning" curve until 
you start getting in uncomfortable places.


For a good example of async operations, look at the LinkedImageFetcher sample:

http://developer.apple.com/library/mac/#samplecode/LinkedImageFetcher/Listings/Read_Me_About_LinkedImageFetcher_txt.html

If you want to see how hard the threading issues really are, read the 
comments in QWatchedOperationQueue.m -- fortunately, you don't have 
to write this, you can just use it.


Also, you don't have to do everything on the main thread -- I 
frequently use a (single) background server thread which sits in a 
runloop and do everything but the UI from there.


This keeps both you UI and engine responsive.

HTH,

-Steve


___

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: [OT] Sync vs ASync Server Comms

[Dave]

On 25 Feb 2013, at 13:57, Steve Sisak wrote:


At 12:26 PM + 2/24/13, Dave wrote:
I think I see what you mean, but I'd argue that there are still  
"threading" issues, the OS will create the Background Threads and  
take care of calling you back on the main thread, I agree, and, if  
that's all you were doing, it might be said to have "No Threading  
Issues", but, for instance, if the first ASync call, needs data to  
use on a later call, then there may well be "Threading Issues".  
Example 1:


Kick off ASync Operation A to get DataA.
Kick off ASync Operation B to get DataB.
Kick off ASync Operation C using DataA and DataB - You need to  
"worry" about "threading" (or at least the consequences of  
threading at this point).


Just to be pedantic, that's a dependency issue but, since the async  
operations always complete on the main thread (or the thread you  
told them to), you don't have to worry about being interrupted  
while manipulation the results.


In the case above, you issue operations A and B, cache the results  
as they come back, and as soon as you have both, kick off operation C.


...or you can just use NSOperation, set up your dependencies, and  
let the OS do it:


Created A, B, C, make C dependent on A, B, submit all of them to an  
NSOperationQueue and wait for C to complete (or put your completion  
code on a block dependent on C -- NSBlockOperation makes this  
really easy.


This was just a simplistic example, unfortunately in real life it's  
not possible to use an Operation Queue effectively for what needs to  
be done, and, anyway, the code is much harder to read and maintain to  
use one.


In fact, I'd argue that using Sync on a user created Background  
thread would after a very small learning curve, actually result in  
less "Threading" issues but may well suffer performance wise. For  
instance in pseudo code, Example 1 would look something like:


You have something which looks like a "simple learning" curve until  
you start getting in uncomfortable places.


Agreed. but that is true of anything, I am comfortable with Multi- 
Threading so it's not really an issue for me.


Also, you don't have to do everything on the main thread -- I  
frequently use a (single) background server thread which sits in a  
runloop and do everything but the UI from there.


This keeps both you UI and engine responsive.


Yes, that's basically the same conclusion I came to, but if do this,  
it negates a lot of the initial simplicity of using that approach,  
so, at that point it's a toss up on which method is preferable.


Cheers
Dave

___

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: [OT] Sync vs ASync Server Comms

[Kyle Sluder]

On Mon, Feb 25, 2013, at 07:18 AM, Dave wrote:
> Agreed. but that is true of anything, I am comfortable with Multi- 
> Threading so it's not really an issue for me.

Someone who's truly comfortable with multithreading would be relishing
the opportunity to not use it.

--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: Programmatic Core Data Migration

[Michael Swan]

Tom,
The data store doesn't have a copy of the model in it, it just has hashes that 
are used to quickly compare the store to the data model trying to open it. In 
order for migration to work you will need to have both the old and new data 
models. In lightweight migrations Core Data uses the two versions to work out 
the differences between them and in the heavier styles it actually builds the 
old stack and carries the data over to the new stack a piece at a time.  

As you move forward with your application you will need to keep every data 
model in it from any version you release so that Core Data can get from any 
older version of the model to whatever is the current version. Depending on how 
often up change the model building all of those models each time your app 
launches may turn into a non-trivial amount of time down the road.

Hope this helps,
Mike Swan
http://www.theMikeSwan.com



"The Ego is the little self that pretends to be the only self and speaks so 
loudly that the still, small voice of the Greater Self, whose whisperings come 
from within the Soul, are rarely heard - unless we learn to listen."



On Feb 25, 2013, at 8:36 AM, cocoa-dev-requ...@lists.apple.com wrote:

> Message: 9
> Date: Mon, 25 Feb 2013 07:27:03 -0600
> From: tshanno 
> To: Cocoa Dev List 
> Subject: Programmatic Core Data Migration
> Message-ID: 
> Content-Type: text/plain; charset=us-ascii
> 
> I'm at an early stage of developing my application and up to this point 
> whenever I've made a changes to the core data model, I've simply trashed the 
> old one and reimported default data.  However I'm now at a point where I'd 
> like to begin using the thing and, as a result, I want to keep the old data 
> and use core data versioning and migration.  I can't imagine that lightweight 
> migration won't be fine for whatever changes I make from here on out.
> 
> Many will think it foolish, I suppose, but I generated my object model 
> completely programmatically.  That is, I didn't use interface builder.  
> Unfortunately, as far as I can tell, the information and instructions in the 
> Core Data Model Versioning and Data Migration Programming Guide seem to 
> assume that you did use interface builder and, therefore, suggest you create 
> a new version of the model using Editor ->  Add Model Version.  I could do 
> this but, of course, I'd simply have two blank graphs. :)
> 
> So it isn't entirely clear to me what I should do here.  Should I simply 
> simply alter the version I have in my code, add the necessary options for 
> lightweight migration?  Xcode will therefore have the new version in code and 
> the old version indirectly in the form of the old persistent store.  Is that 
> all it needs?
> 
> Thanks for any help here.
> 
> Tom S.

___

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: Tracking object references

[Matt Neuburg]

On Feb 22, 2013, at 11:08 AM, Ken Thomases wrote:

> Well, I'm sorry that you're frustrated but many aspects of development 
> require the application of human intelligence and can't be automated.  This 
> is one of them.  If you actually go through the exercise of reviewing an 
> object's retain/release history and matching up the retains and releases, 
> you'll pretty quickly see that it's a difficult problem requiring an 
> understanding of the code at a pretty high level.

I do agree, and I'm sorry that I allowed my frustration to show. Recall that 
this came up because someone (Mike?) said that Instruments showed something 
that in fact it does not show, which proves my point: one wishes it did, and 
one projects those wishes onto Instruments, but the reality is otherwise. It 
was this difference between the desire and the reality that provoked my 
response. I've spent hours with a pencil and paper writing down all the info 
that each call stack shows me, trying to match up retains and releases; this 
seems a very crude interface and a poor use of my time, and I can't believe 
that Instruments couldn't do *something* to help me, even if were just a better 
GUI. And when there's a memory management bug in the framework (yes, this *can* 
still happen, even under ARC), my pencil-and-paper method can fail to track 
down the issue. m.

--
matt neuburg, phd = m...@tidbits.com, http://www.apeth.net/matt/
pantes anthropoi tou eidenai oregontai phusei
Programming iOS 5! http://shop.oreilly.com/product/0636920023562.do
RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html
TidBITS, Mac news and reviews since 1990, http://www.tidbits.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

Documents not opening from Finder

[Steve Mills]

I'm seeing a situation where, after successfully opening, NOT printing, and 
then closing a document x number of times via Finder's Print command, our app 
will stop receiving requests to open the same or any other document. I've added 
an override for initWithContentsOfURL:ofType:error: just to see if it's getting 
there, and it is not. Normally we only override init, initWithType:error, and 
readFromURL:ofType:error:. In fact, we stop getting even the 
readFromURL:ofType:error: message if I go through our app's standard Cocoa Open 
menu item; I choose a file and nothing happens. Same with init and 
initWithType:error.

Any ideas about what could be getting messed up? We subclass 
NSApplicationDelegate, NSDocument, and NSWindowController, but nothing else in 
the chain like NSDocumentController.

--
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: [OT] Sync vs ASync Server Comms

[Steve Sisak]

At 3:18 PM + 2/25/13, Dave wrote:

On 25 Feb 2013, at 13:57, Steve Sisak wrote:
Created A, B, C, make C dependent on A, B, submit all of them to an 
NSOperationQueue and wait for C to complete (or put your completion 
code on a block dependent on C -- NSBlockOperation makes this 
really easy.


This was just a simplistic example, unfortunately in real life it's 
not possible to use an Operation Queue effectively for what needs to 
be done, and, anyway, the code is much harder to read and maintain 
to use one.


Why? I use them for some very high performance stuff.

Also, you don't have to do everything on the main thread -- I 
frequently use a (single) background server thread which sits in a 
runloop and do everything but the UI from there.


This keeps both you UI and engine responsive.


Yes, that's basically the same conclusion I came to, but if do this, 
it negates a lot of the initial simplicity of using that approach, 
so, at that point it's a toss up on which method is preferable.


The current trend is away from threads and toward asynchronous programming.

That's orthogonal to whether your tasks are run on a single 
(XXRunLoop) or multiple (GCD) threads -- the advantage of GCD is that 
the system gets do decide how many worker threads to fire up based on 
the number of cores available, system load, and who's blocked.


NSOperationQueue adds dependencies -- you can do similar things with 
blocks and dispatch_groups.


If you don't like NSOperationQueue, go bare metal and use GCD directly.

I suggested NSOperationQueue because it's exactly the right tool for 
your example.


WAYRTTD?

-Steve
___

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: [OT] Sync vs ASync Server Comms

[Kyle Sluder]

On Mon, Feb 25, 2013, at 02:45 PM, Steve Sisak wrote:
> 
> The current trend is away from threads and toward asynchronous
> programming.
> 
> That's orthogonal to whether your tasks are run on a single 
> (XXRunLoop) or multiple (GCD) threads -- the advantage of GCD is that 
> the system gets do decide how many worker threads to fire up based on 
> the number of cores available, system load, and who's blocked.

They're orthogonal, but they don't compose well.

1. You cannot assume anything about the thread on which a block runs
after being submitted to a GCD queue (other than the main queue). So no
runloop-dependent technologies for you. That means you cannot call
asynchronous Cocoa APIs from an async queue.

2. Blocking queues is _extremely_ dangerous, to the point where you
mustn't do it. At best, you'll cause GCD to spin up extra worker threads
unnecessarily. At worst, you'll cause deadlock as you exhaust your
thread pool. This means you cannot call synchronous (blocking) Cocoa
APIs from an async queue.

Long story short: do not mix GCD queues and long-term communications
APIs.

--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

Programmatic autolayout problem

[Rick Mann]

This is the first time I'm trying to programmatically use autolayout, and I 
can't seem to do a simple thing.

I'm creating a bunch of views using an NSViewController subclass for each, and 
adding them to a window (the window created from the default Cocoa App 
template).

I programmatically build a view layout string that looks like this:

|[view0][view1]

as well as individual constraints that look like:

V:|[view]

That is, I just want my views to stack left-to-right (ideally, right-to-left on 
RTL systems), with no space between them. Prior to this, I resize the window to 
be just big enough for all the views.

Inside each view are a couple of NSTextFields, laid out in IB. What I want to 
do in IB is something like:

|-5-[text1]-5-[text2]-5-|

And have the parent view compress all the way down to that, such that the text 
is never truncated. But what I'm ending up with are these frames:

containing view: {{0, 20}, {93, 0}}
text1: {{2, -17}, {34, 17}}
text2: {{35, -17}, {56, 17}}

Note that the containing view height is 0, and the y-coordinate for the labels 
is -17; so, nothing's visible.

Prior to auto layout, it looks like:

containing view: {{0, 0}, {95, 20}}
text1: {{2, 3}, {34, 17}}
text2: {{35, 3}, {58, 17}}

Which is how it's laid out in IB.

Can anyone please tell me how to set up the constraints in IB so that the view 
is as small as it can be, without truncating text or going to 0?

A separate question: Is it possible to get the window to expand to just hug the 
stacked views?

-- 
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: Programmatic autolayout problem

[Kyle Sluder]

On Feb 25, 2013, at 8:33 PM, Rick Mann  wrote:

> This is the first time I'm trying to programmatically use autolayout, and I 
> can't seem to do a simple thing.
> 
> I'm creating a bunch of views using an NSViewController subclass for each, 
> and adding them to a window (the window created from the default Cocoa App 
> template).

Specifically, you are adding them to the window's content view, correct? I'll 
assume so.

> 
> I programmatically build a view layout string that looks like this:
> 
>|[view0][view1]

This leaves the right border undefined. Without sufficient internal constraints 
on your views (either explicit constraints or ones created by virtue of content 
hugging), this means their widths will also be undefined.

> 
> as well as individual constraints that look like:
> 
>V:|[view]

This leaves the bottom border undefined. And as above, barring sufficient 
internal constraints the heights of these views will be undefined.

> 
> That is, I just want my views to stack left-to-right (ideally, right-to-left 
> on RTL systems), with no space between them. Prior to this, I resize the 
> window to be just big enough for all the views.

If your views constraints fully specify their widths and heights, this step is 
unnecessary.

Do you intend for your views to completely define their own sizes, or do you 
want them to react to the size of the window? Your post seems to imply the 
former.

> 
> Inside each view are a couple of NSTextFields, laid out in IB. What I want to 
> do in IB is something like:
> 
>|-5-[text1]-5-[text2]-5-|
> 
> And have the parent view compress all the way down to that, such that the 
> text is never truncated.

This leaves the height of the view unspecified.

> But what I'm ending up with are these frames:
> 
> containing view: {{0, 20}, {93, 0}}
> text1: {{2, -17}, {34, 17}}
> text2: {{35, -17}, {56, 17}}
> 
> Note that the containing view height is 0, and the y-coordinate for the 
> labels is -17; so, nothing's visible.

Because the height of your view is unspecified, auto layout picked one of the 
infinite values of height that satisfied the system: 0.


> 
> Prior to auto layout, it looks like:
> 
> containing view: {{0, 0}, {95, 20}}
> text1: {{2, 3}, {34, 17}}
> text2: {{35, 3}, {58, 17}}
> 
> Which is how it's laid out in IB.
> 
> Can anyone please tell me how to set up the constraints in IB so that the 
> view is as small as it can be, without truncating text or going to 0?

I'd start with a diagram of how you want your window to look. Then draw struts 
between all the views. Remove unnecessary ones. That'll give you an 
approximation for the set of constraints you need to install.


> A separate question: Is it possible to get the window to expand to just hug 
> the stacked views?

When your constraints are set up correctly, this will happen automatically, as 
long as the constraints producing that size have priorities greater than 500 
(NSLayoutConstraintPriorityThatCanResizeWindow or some such).

--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: Programmatic autolayout problem

[Rick Mann]

Thanks, Kyle!

On Feb 25, 2013, at 21:55 , Kyle Sluder  wrote:

> Specifically, you are adding them to the window's content view, correct? I'll 
> assume so.

Yes, that's correct.

>> 
>> I programmatically build a view layout string that looks like this:
>> 
>>   |[view0][view1]
> 
> This leaves the right border undefined. Without sufficient internal 
> constraints on your views (either explicit constraints or ones created by 
> virtue of content hugging), this means their widths will also be undefined.

Now that I know the window will, in fact, resize, I can make that to be 
|[view0][view1]|

>> as well as individual constraints that look like:
>> 
>>   V:|[view]
> 
> This leaves the bottom border undefined. And as above, barring sufficient 
> internal constraints the heights of these views will be undefined.

Similarly, I can make that V:|[view]|

>> That is, I just want my views to stack left-to-right (ideally, right-to-left 
>> on RTL systems), with no space between them. Prior to this, I resize the 
>> window to be just big enough for all the views.
> 
> If your views constraints fully specify their widths and heights, this step 
> is unnecessary.
> 
> Do you intend for your views to completely define their own sizes, or do you 
> want them to react to the size of the window? Your post seems to imply the 
> former.

Correct. My view contains two NSTextFields. I want their own content hugging 
and compression to define their size, and the additional spacing I put in there 
to define the containing view's size.

>> Inside each view are a couple of NSTextFields, laid out in IB. What I want 
>> to do in IB is something like:
>> 
>>   |-5-[text1]-5-[text2]-5-|
>> 
>> And have the parent view compress all the way down to that, such that the 
>> text is never truncated.
> 
> This leaves the height of the view unspecified.

Sorry, I didn't add that IB also put in default constraints for the vertical, 
although I may not have added one at the bottom:

|-y1-[view](not sure if there's anything else here)

>> But what I'm ending up with are these frames:
>> 
>> containing view: {{0, 20}, {93, 0}}
>> text1: {{2, -17}, {34, 17}}
>> text2: {{35, -17}, {56, 17}}
>> 
>> Note that the containing view height is 0, and the y-coordinate for the 
>> labels is -17; so, nothing's visible.
> 
> Because the height of your view is unspecified, auto layout picked one of the 
> infinite values of height that satisfied the system: 0.

I thought IB's default constraints would prevent this, but the missing 
constraints in IB allowed it.

> 
> 
>> 
>> Prior to auto layout, it looks like:
>> 
>> containing view: {{0, 0}, {95, 20}}
>> text1: {{2, 3}, {34, 17}}
>> text2: {{35, 3}, {58, 17}}
>> 
>> Which is how it's laid out in IB.
>> 
>> Can anyone please tell me how to set up the constraints in IB so that the 
>> view is as small as it can be, without truncating text or going to 0?
> 
> I'd start with a diagram of how you want your window to look. Then draw 
> struts between all the views. Remove unnecessary ones. That'll give you an 
> approximation for the set of constraints you need to install.
> 
> 
>> A separate question: Is it possible to get the window to expand to just hug 
>> the stacked views?
> 
> When your constraints are set up correctly, this will happen automatically, 
> as long as the constraints producing that size have priorities greater than 
> 500 (NSLayoutConstraintPriorityThatCanResizeWindow or some such).

Thanks, good to know.

IB defaults a lot of hugging/compression constraints to 250. Do I need to 
increase those to 501 or more, as well?

-- 
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: Programmatic autolayout problem

[Kyle Sluder]

On Mon, Feb 25, 2013, at 10:04 PM, Rick Mann wrote:
> IB defaults a lot of hugging/compression constraints to 250. Do I need to
> increase those to 501 or more, as well?

Yes for the hugging constraints. Otherwise the window size will win as
the user drags to resize the window.

Think of window drag-resizing as installing a temporary constraint that
follows the mouse at priority 500. Think of content hugging as
installing an equality constraint with a constant equal to the view's
intrinsicContentSize in the given dimension, operating at the priority
you specify. If the content hugging priorities of your text fields have
higher priority than the window-resizing constraint, the hugging
constraints will win and the window frame will stay put.

Note that the window itself won't notice this outside of a drag
operation, so it will still put up the drag-to-resize cursor when the
mouse gets near the window edge. If you know you want the window to stay
a fixed size, you'll probably want to turn off the Resizable flag for
your window. Auto layout should still resize the window appropriately.

(Content compression resistance is different from content hugging
because compression resistance is an inequality, whereas hugging is an
equality. Inequalities have infinite solutions, so it's easier to
accidentally underspecify your constraint system once you start
incorporating them.)

--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: Programmatic autolayout problem

[Rick Mann]

On Feb 25, 2013, at 22:38 , Kyle Sluder  wrote:

> Yes for the hugging constraints. Otherwise the window size will win as
> the user drags to resize the window.
> 
> Think of window drag-resizing as installing a temporary constraint that
> follows the mouse at priority 500. Think of content hugging as
> installing an equality constraint with a constant equal to the view's
> intrinsicContentSize in the given dimension, operating at the priority
> you specify. If the content hugging priorities of your text fields have
> higher priority than the window-resizing constraint, the hugging
> constraints will win and the window frame will stay put.
> 
> Note that the window itself won't notice this outside of a drag
> operation, so it will still put up the drag-to-resize cursor when the
> mouse gets near the window edge. If you know you want the window to stay
> a fixed size, you'll probably want to turn off the Resizable flag for
> your window. Auto layout should still resize the window appropriately.
> 
> (Content compression resistance is different from content hugging
> because compression resistance is an inequality, whereas hugging is an
> equality. Inequalities have infinite solutions, so it's easier to
> accidentally underspecify your constraint system once you start
> incorporating them.)

Gotcha.

Well, it's closer to working, but still not correct. If I don't pre-size the 
window, it never gets resized, even though all the constraints are above 500. 
Vertically it seems to be perfectly hugging my labels (verified by changing the 
font size in IB without re-adjusting the views in IB). But horizontally it's 
still not hugging. It looks like the labels aren't shrinking horizontally 
enough.

The fixes space between the two labels also isn't the 5 it's specified to be.

Frame: {{288, 0}, {96, 16}}
view1: {{2, 1}, {34, 14}}
view2: {{35, 1}, {59, 14}}

Seems to be -1, for some reason.

-- 
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: Programmatic autolayout problem

[Kyle Sluder]

On Mon, Feb 25, 2013, at 10:46 PM, Rick Mann wrote:
> Well, it's closer to working, but still not correct. If I don't pre-size
> the window, it never gets resized, even though all the constraints are
> above 500. Vertically it seems to be perfectly hugging my labels
> (verified by changing the font size in IB without re-adjusting the views
> in IB). But horizontally it's still not hugging. It looks like the labels
> aren't shrinking horizontally enough.
> 
> The fixes space between the two labels also isn't the 5 it's specified to
> be.
> 
> Frame: {{288, 0}, {96, 16}}
> view1: {{2, 1}, {34, 14}}
> view2: {{35, 1}, {59, 14}}
> 
> Seems to be -1, for some reason.

You must still have an underspecified system of constraints in the
horizontal direction. Unfortunately, your description of your constraint
system lacks sufficient detail for debugging, which is already difficult
to do in textual form.

Graphics really are the best. You can use -[NSView
constraintsAffectingLayoutForOrientation:] to get an array of all(*) the
constraints determining a view's layout in that direction. Pass that
array to -[NSWindow visualizeConstraints:] and you get a big pink debug
window attached to your own, and all the constraints you passed will be
drawn on top of your window. If your layout is ambiguous, there will be
an "Exercise Ambiguity" button you can click to help you figure out
what's missing.

(*) It's not guaranteed to return all the constraints. But I've yet to
see it fail to return a constraint.

--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: Programmatic autolayout problem

[Rick Mann]

On Feb 25, 2013, at 23:03 , Kyle Sluder  wrote:

> You must still have an underspecified system of constraints in the
> horizontal direction. Unfortunately, your description of your constraint
> system lacks sufficient detail for debugging, which is already difficult
> to do in textual form.

I lied. The window is resizing properly. When I commented out the explicit 
resize code, I accidentally commented out the code that installs the individual 
views!

> Graphics really are the best. You can use -[NSView
> constraintsAffectingLayoutForOrientation:] to get an array of all(*) the
> constraints determining a view's layout in that direction. Pass that
> array to -[NSWindow visualizeConstraints:] and you get a big pink debug
> window attached to your own, and all the constraints you passed will be
> drawn on top of your window. If your layout is ambiguous, there will be
> an "Exercise Ambiguity" button you can click to help you figure out
> what's missing.
> 
> (*) It's not guaranteed to return all the constraints. But I've yet to
> see it fail to return a constraint.

I'll try this. It's still not compressing horizontally. Thanks!

-- 
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: Programmatic autolayout problem

[Rick Mann]

On Feb 25, 2013, at 23:03 , Kyle Sluder  wrote:

> You must still have an underspecified system of constraints in the
> horizontal direction. Unfortunately, your description of your constraint
> system lacks sufficient detail for debugging, which is already difficult
> to do in textual form.
> 
> Graphics really are the best. You can use -[NSView
> constraintsAffectingLayoutForOrientation:] to get an array of all(*) the
> constraints determining a view's layout in that direction. Pass that
> array to -[NSWindow visualizeConstraints:] and you get a big pink debug
> window attached to your own, and all the constraints you passed will be
> drawn on top of your window. If your layout is ambiguous, there will be
> an "Exercise Ambiguity" button you can click to help you figure out
> what's missing.

Sometimes IB puts in a gray width constraint in the NSTextField, and sometimes 
it gets rid of it. I don't know if that's a fixed width, or if that represents 
the hugged width of the default text in the field. I have:

|[text1]-1-[text2]-5-|

And it put in a width for text1 but not text2.

-- 
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: Programmatic autolayout problem

[Kyle Sluder]

On Feb 25, 2013, at 11:34 PM, Rick Mann  wrote:

> 
> On Feb 25, 2013, at 23:03 , Kyle Sluder  wrote:
> 
>> You must still have an underspecified system of constraints in the
>> horizontal direction. Unfortunately, your description of your constraint
>> system lacks sufficient detail for debugging, which is already difficult
>> to do in textual form.
>> 
>> Graphics really are the best. You can use -[NSView
>> constraintsAffectingLayoutForOrientation:] to get an array of all(*) the
>> constraints determining a view's layout in that direction. Pass that
>> array to -[NSWindow visualizeConstraints:] and you get a big pink debug
>> window attached to your own, and all the constraints you passed will be
>> drawn on top of your window. If your layout is ambiguous, there will be
>> an "Exercise Ambiguity" button you can click to help you figure out
>> what's missing.
> 
> Sometimes IB puts in a gray width constraint in the NSTextField, and 
> sometimes it gets rid of it. I don't know if that's a fixed width, or if that 
> represents the hugged width of the default text in the field. I have:
> 
>|[text1]-1-[text2]-5-|
> 
> And it put in a width for text1 but not text2.

You'll never see the constraints created for content hugging or compression 
resistance.

IB refuses to let your interface be underspecified. If you remove a constraint 
necessary to fully specify your interface, it will tend to install fixed-size 
constraints that reflect your views' current frames.

In the nib containing your subviews, is "translates autoresizing mask into 
constraints" turned off for your root view (that is, the superview of your text 
fields)? This needs to be on during design time to stifle IB's incredibly 
annoying behavior of inserting constraints to avoid underspecified interfaces. 
Right before you insert the subviews into the window's view hierarchy, turn off 
this property programmatically.

--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: Programmatic autolayout problem

[Rick Mann]

On Feb 25, 2013, at 23:44 , Kyle Sluder  wrote:

> You'll never see the constraints created for content hugging or compression 
> resistance.
> 
> IB refuses to let your interface be underspecified. If you remove a 
> constraint necessary to fully specify your interface, it will tend to install 
> fixed-size constraints that reflect your views' current frames.
> 
> In the nib containing your subviews, is "translates autoresizing mask into 
> constraints" turned off for your root view (that is, the superview of your 
> text fields)? This needs to be on during design time to stifle IB's 
> incredibly annoying behavior of inserting constraints to avoid underspecified 
> interfaces. Right before you insert the subviews into the window's view 
> hierarchy, turn off this property programmatically.

Heh, I was just about to write you a note complaining about how IB inserts 
constraints all the time. It really screws things up. I think I've finally 
figured out how a gray disabled width constraint can be removed. Add sufficient 
constraints, then size that thing to fit.

IB really needs to just flag the thing as unconstrained, and give me a button 
to "insert necessary constraints," but not do it automatically. It's nearly 
impossible to see the constraints as displayed graphically, and adding before 
removing just makes it that much harder.

Anyway, I think I finally have it correctly specified. Thanks for all your 
help, Kyle.


-- 
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: Programmatic autolayout problem

[Kyle Sluder]

On Feb 25, 2013, at 11:47 PM, Rick Mann  wrote:

> 
> On Feb 25, 2013, at 23:44 , Kyle Sluder  wrote:
> 
>> You'll never see the constraints created for content hugging or compression 
>> resistance.
>> 
>> IB refuses to let your interface be underspecified. If you remove a 
>> constraint necessary to fully specify your interface, it will tend to 
>> install fixed-size constraints that reflect your views' current frames.
>> 
>> In the nib containing your subviews, is "translates autoresizing mask into 
>> constraints" turned off for your root view (that is, the superview of your 
>> text fields)? This needs to be on during design time to stifle IB's 
>> incredibly annoying behavior of inserting constraints to avoid 
>> underspecified interfaces. Right before you insert the subviews into the 
>> window's view hierarchy, turn off this property programmatically.
> 
> Heh, I was just about to write you a note complaining about how IB inserts 
> constraints all the time. It really screws things up. I think I've finally 
> figured out how a gray disabled width constraint can be removed. Add 
> sufficient constraints, then size that thing to fit.

Yes, sizing to fit is important for getting rid of spurious constraints. ;-) 
Good job figuring that out. I forgot to mention it.

> 
> IB really needs to just flag the thing as unconstrained, and give me a button 
> to "insert necessary constraints," but not do it automatically. It's nearly 
> impossible to see the constraints as displayed graphically, and adding before 
> removing just makes it that much harder.

Yes it does! Please dupe rdar://problem/12986107.

> 
> Anyway, I think I finally have it correctly specified. Thanks for all your 
> help, Kyle.

Awesome! Best of luck.

--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