Re: Split view priority

2016-04-22 Thread Quincey Morris 
On Apr 22, 2016, at 18:56 , Ken Thomases  wrote:
> 
> After that, what is the design-time size of the left split view and the 
> window?  You should set them to the default configuration.  The window will 
> stay that way so long as there are no constraints of priority 500 
> (NSLayoutPriorityWindowSizeStayPut) or greater that force it to another size 
> (or the user resizes it manually, of course).

Thanks for your help. With your hint to look at design widths, I think I 
figured it out. The problem was the extra container view in the hierarchy (B, 
below). The actual hierarchy looked like this, with each lettered item being 
its own scene in the storyboard, with its own controller:

> A. Window content view (1000 design width) -> B. Container view -> C. Split 
> view (left + right)

> C. Split view (left) -> D. Source list (outline view): width >= 70 @1000, 
> width >= 300 @249

> C. Split view (right) -> E. Tab view -> F. Tab item view -> G. Table view: 
> width >= 700 @1000

The problem was that container view B had a design width smaller than 1000, 
under the assumption that it wouldn’t matter what it was, but it did. Changing 
that design width to 1000 made everything work correctly.

What’s confusing is that the split view, the tab view and the tab item view all 
have random design widths that don’t seem to matter, which is what led me to 
believe that none of the design widths mattered. Turns out, when they matter, 
they matter, when they don’t, they don’t.

(The reason the container view is a scene with a view controller is that, in a 
storyboard, if you place a split view in a subview, you don’t get a 
NSSplitViewController for it. Instead, you have to put a container view in the 
subview, and do an ‘embed’ segue to the split view scene.)

___

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: Split view priority

2016-04-22 Thread Quincey Morris 
On Apr 22, 2016, at 18:56 , Ken Thomases  wrote:
> 
> First, the split view holding priorities should generally be less than 490.  
> That's NSLayoutPriorityDragThatCannotResizeWindow.  If they are greater than 
> that, then they'll potentially override the window's size.

Sorry, I misspoke, or rather misremembered. The holding priorities are 251 and 
250.

> After that, what is the design-time size of the left split view and the 
> window?  You should set them to the default configuration.  The window will 
> stay that way so long as there are no constraints of priority 500 
> (NSLayoutPriorityWindowSizeStayPut) or greater that force it to another size 
> (or the user resizes it manually, of course).

At design time, they are 300 and 1000, as for the default configuration, but 
the window doesn’t stay that way.

I think I’ll try to recreate this in a test project that I can post. The real 
thing makes it too hard to be certain what I’ve changed and what I haven’t.

___

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: Split view priority

2016-04-22 Thread Ken Thomases 
On Apr 22, 2016, at 7:15 PM, Quincey Morris 
 wrote:
> 
> I have a window that contains a split view of 2 split items. The item on the 
> left is a source list whose width constraint is '>= 70’ @priority 1000. The 
> item on the right is a view whose width constraint is '>= 700’ @priority 
> 1000. The window itself has no minimum size specified in IB or any other way.
> 
> What I want is for the left split to start out at width 300, and the right 
> split to start out at width 700. That is, the left split is larger than its 
> minimum size, while the right split is at its minimum size. Then, resizing 
> the window should resize the right split only, as far as possible, 
> compressing the left split down from 300 only when the window gets smaller 
> than its original size. I can achieve that by setting the left split’s 
> holding priority to 751, vs. 750 for the right split. That “preference” for 
> resizing the right split item works.
> 
> The problem is, the window is always 770 (70 + 700) wide when it opens, not 
> the desired 1000 (300 + 700). There is no state restoration ATM, so that’s 
> not a factor. IOW, the window is opening at its minimum possible width.

First, the split view holding priorities should generally be less than 490.  
That's NSLayoutPriorityDragThatCannotResizeWindow.  If they are greater than 
that, then they'll potentially override the window's size.

After that, what is the design-time size of the left split view and the window? 
 You should set them to the default configuration.  The window will stay that 
way so long as there are no constraints of priority 500 
(NSLayoutPriorityWindowSizeStayPut) or greater that force it to another size 
(or the user resizes it manually, of course).

Regards,
Ken


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: BOOL parameter passed as nil object

2016-04-22 Thread Ken Thomases 
On Apr 22, 2016, at 6:19 PM, Quincey Morris 
 wrote:
> 
> On Apr 22, 2016, at 16:12 , Carl Hoefs  wrote:
>> 
>> Yes, CFRunLoopPerformBlock: works well!
> 
> But it sounded like you *didn’t* want to prevent the block from running. In 
> that case, dispatch_async would be all you’d need. (AFAIK, it doesn’t 
> interact with run loops, which means the block will always run.)
> 
> OTOH, if you were trying to *prevent* your block from running until the run 
> loop exited a mode, then I guess CFRunLoopPerformBlock is what you’d want.

The main dispatch queue is processed in the common run loop modes.  It is not 
correct that "it doesn’t interact with run loops, which means the block will 
always run".  If running in the common modes is what you want to achieve, 
there's no need to use CFRunLoopPerformBlock().  You'd only need to use that if 
you want it to run in some other mode(s).

Also, if you use CFRunLoopPerformBlock(), you generally want to call 
CFRunLoopWakeUp() immediately after.  See the docs for the former.

Regards,
Ken


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: HIThemeGetTextDimensions problems

2016-04-22 Thread Graham Cox 

> On 23 Apr 2016, at 6:04 AM, Tom Doan  wrote:
> 
> Is there a more modern and well-behaved alternative to this?


-[NSString sizeWithAttributes:…];


—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

Split view priority

2016-04-22 Thread Quincey Morris 
I have a window that contains a split view of 2 split items. The item on the 
left is a source list whose width constraint is '>= 70’ @priority 1000. The 
item on the right is a view whose width constraint is '>= 700’ @priority 1000. 
The window itself has no minimum size specified in IB or any other way.

What I want is for the left split to start out at width 300, and the right 
split to start out at width 700. That is, the left split is larger than its 
minimum size, while the right split is at its minimum size. Then, resizing the 
window should resize the right split only, as far as possible, compressing the 
left split down from 300 only when the window gets smaller than its original 
size. I can achieve that by setting the left split’s holding priority to 751, 
vs. 750 for the right split. That “preference” for resizing the right split 
item works.

The problem is, the window is always 770 (70 + 700) wide when it opens, not the 
desired 1000 (300 + 700). There is no state restoration ATM, so that’s not a 
factor. IOW, the window is opening at its minimum possible width.

OK, so I said the width 300 on the left was what I “want”, but so far I didn’t 
do anything to achieve that. Now, if I add a width constraint ‘>= 300’ to the 
source list on the left, and set its priority to 251 or below, I get the same 
behavior (initial width 70). If I set its priority to 252 or above, the window 
opens at the desired size (1000), but the left split item can no longer be 
resized smaller than 300. The original width constraint ‘>=70’ @priority 1000 
is still there.

What do I have to do to get the window to open at a width other than its 
minimum? I’m not sure if this is something I need to do to the split view, or 
possibly if it’s something I need to do to the window.

(My window architecture is slightly simplified in this description. There’s 
actually a nested controller/view combination between the window and the split 
view, but AFAIK I don’t have any constraints anywhere else that will affect the 
window size.)



___

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: BOOL parameter passed as nil object

2016-04-22 Thread Quincey Morris 
On Apr 22, 2016, at 16:12 , Carl Hoefs  wrote:
> 
> Yes, CFRunLoopPerformBlock: works well!

But it sounded like you *didn’t* want to prevent the block from running. In 
that case, dispatch_async would be all you’d need. (AFAIK, it doesn’t interact 
with run loops, which means the block will always run.)

OTOH, if you were trying to *prevent* your block from running until the run 
loop exited a mode, then I guess CFRunLoopPerformBlock is what you’d want.

___

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: BOOL parameter passed as nil object

2016-04-22 Thread Carl Hoefs 
Yes, CFRunLoopPerformBlock: works well!
Thanks,
-Carl

> On Apr 22, 2016, at 4:09 PM, Clark Cox  wrote:
> 
> If you really need the block to run in specific runloop modes, you can use 
> CFRunLoopPerformBlock:
> 
> 
> 
> CFRunLoopPerformBlock(CFRunLoopGetMain(), kCFRunLoopCommonModes, ^{
>   //Code to be performed on main thread
> });
> 
> 
>> On Apr 22, 2016, at 16:00, Carl Hoefs  wrote:
>> 
>> On Apr 22, 2016, at 2:57 PM, Quincey Morris 
>>  wrote:
>>> 
>>> If you must use performSelector, then you can write your own glue method 
>>> that takes an object parameter and invokes the API that takes the scalar 
>>> parameter.
>> 
>> -performSelectorOnMainThread:withObject:waitUntilDone:modes: can handle 
>> NSRunLoopCommonModes, such as to ensure an animation continues to run in all 
>> run loop common modes. Does the block+GCD+dispatch_async approach support 
>> this, or is this a case where -performSelector: should be used?
>> 
>> -Carl
>> 
>> 
>> ___
>> 
>> 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/clarkcox3%40gmail.com
>> 
>> This email sent to clarkc...@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: BOOL parameter passed as nil object

2016-04-22 Thread Clark Cox 
If you really need the block to run in specific runloop modes, you can use 
CFRunLoopPerformBlock:



CFRunLoopPerformBlock(CFRunLoopGetMain(), kCFRunLoopCommonModes, ^{
//Code to be performed on main thread
});


> On Apr 22, 2016, at 16:00, Carl Hoefs  wrote:
> 
> On Apr 22, 2016, at 2:57 PM, Quincey Morris 
>  wrote:
>> 
>> If you must use performSelector, then you can write your own glue method 
>> that takes an object parameter and invokes the API that takes the scalar 
>> parameter.
> 
> -performSelectorOnMainThread:withObject:waitUntilDone:modes: can handle 
> NSRunLoopCommonModes, such as to ensure an animation continues to run in all 
> run loop common modes. Does the block+GCD+dispatch_async approach support 
> this, or is this a case where -performSelector: should be used?
> 
> -Carl
> 
> 
> ___
> 
> 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/clarkcox3%40gmail.com
> 
> This email sent to clarkc...@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: BOOL parameter passed as nil object

2016-04-22 Thread Carl Hoefs 
On Apr 22, 2016, at 2:57 PM, Quincey Morris 
 wrote:
> 
> If you must use performSelector, then you can write your own glue method that 
> takes an object parameter and invokes the API that takes the scalar parameter.

-performSelectorOnMainThread:withObject:waitUntilDone:modes: can handle 
NSRunLoopCommonModes, such as to ensure an animation continues to run in all 
run loop common modes. Does the block+GCD+dispatch_async approach support this, 
or is this a case where -performSelector: should be used?

-Carl


___

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: BOOL parameter passed as nil object

2016-04-22 Thread Carl Hoefs 

> On Apr 22, 2016, at 2:57 PM, Quincey Morris 
>  wrote:
> 
> The recommended way to have them performed on the main thread is to use a 
> block and GCD dispatch_async (dispatch_get_main_queue (), …).

Ahh, that's clean. Implemented and working! That saves me a lot of effort.
Thanks!
-Carl

___

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: BOOL parameter passed as nil object

2016-04-22 Thread Quincey Morris 
On Apr 22, 2016, at 14:48 , Carl Hoefs  wrote:
> 
>  does this mean that there is no inherent way to handle the 1000s of 
> Foundation and AppKit method signatures which don't specify an object but a 
> value parameter? There is no recommended way to have them performed on the 
> main thread? 

The recommended way to have them performed on the main thread is to use a block 
and GCD dispatch_async (dispatch_get_main_queue (), …).

The recommended way to use performSelector these days is, in effect, not to use 
it. There are situations where it doesn’t satisfy the ARC memory management 
safety guarantees. In almost all cases, the GCD+block solution is simpler and 
better.

If you must use performSelector, then you can write your own glue method that 
takes an object parameter and invokes the API that takes the scalar parameter.



___

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: BOOL parameter passed as nil object

2016-04-22 Thread Carl Hoefs 

> On Apr 19, 2016, at 1:50 PM, John McCall  wrote:
> 
> We strongly encourage you not to worry about any of this and just always call 
> methods using the right method signature.

Sorry to beat a dead horse, but does this mean that there is no inherent way to 
handle the 1000s of Foundation and AppKit method signatures which don't specify 
an object but a value parameter? There is no recommended way to have them 
performed on the main thread? 
-Carl

___

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

HIThemeGetTextDimensions problems

2016-04-22 Thread Tom Doan 
While doing some cleanup of memory problems on our software, I 
discovered that HIThemeGetTextDimensions seemed to be leaking memory. 
(At minimum, it seemed to be allocating a CFString and a CFDictionary and 
never fully releasing them). This seems to be an old Carbon-era function 
which is poorly documented and has been a probably even before I found 
that it was leaking. (We have a multi-threaded application and it seems it 
doesn't work properly unless run on the main thread, which never made any 
real sense). Is there a more modern and well-behaved alternative to this? I 
can't seem to find one.


(Code in which it's used)

-(IBAction) textsize:(id) view
{
CGFloat cgwidth;
HIThemeTextInfo textinfo;
textinfo.version = 1;
textinfo.state   = kThemeStateActive;
textinfo.fontID  = kThemeSystemFont;
textinfo.horizontalFlushness = kHIThemeTextHorizontalFlushLeft;
textinfo.verticalFlushness   = kHIThemeTextVerticalFlushCenter;
textinfo.options = 0;
textinfo.truncationPosition  = kHIThemeTextTruncationNone;
textinfo.truncationMaxLines  = 1;
HIThemeGetTextDimensions(itsString,0,,,NULL,NULL);
itsWidth = cgwidth;
}

Best regards,

Tom Doan
Estima
---
1560 Sherman Ave #1029
Evanston, IL 60201
USA

___

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: Pinning a Window to a Window

2016-04-22 Thread Uli Kusterer 
On 22 Apr 2016, at 15:23, Dave  wrote:
> Is there any way of “pinning” one of my App’s windows so it is always in 
> front of a window owned by another application? I’m using a Floating Window 
> style at the moment, which works ok, but the window floats in fronts of 
> everything. I’d like my window to always be just in front of the target 
> window. Is this possible?

 Not really. That said, there are numerous answers depending on your concrete 
circumstances, like:

- Who owns the other application (are you developer of both, or are they 
willing to help, or do they offer plugin mechanisms), or is it maybe a 
particular application (e.g. Finder keeps the desktop background in a separate 
window from the one holding the icons, so you can sneak a window in between, 
and also offers Finder Sync extension API).
- What your window does. (Sometimes it looks like you need your own UI, when 
really just using a Service that adds a contextual menu item can get your 
functionality in the other app and make it look built-in to the user)
- Whether you want in the app store. If not, you could theoretically inject 
your own code into another app and then add your own views or windows (but this 
has a lot of potential to break the other app, so isn't very popular and very 
hard to get right)

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://stacksmith.org





___

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: Pinning a Window to a Window

2016-04-22 Thread dangerwillrobinsondanger 
The only way you will be able to track a window owned by another process is via 
the AX (accessibility) APIs.
This comes with a caveat that users have to opt in to allow your app to control 
their computer. 
There is an API to request it. 
And one to see if you have it. 
If you have it, then you can look for the target app and window and create an 
observer object that can register to observe various AX properties and register 
callbacks for them. 
It's a tough API. 
All Core Foundation style C. 
But it enables some cool tricks.  
Sent from my iPhone

> On Apr 22, 2016, at 10:23 PM, Dave  wrote:
> 
> Hi All, 
> 
> Is there any way of “pinning” one of my App’s windows so it is always in 
> front of a window owned by another application? I’m using a Floating Window 
> style at the moment, which works ok, but the window floats in fronts of 
> everything. I’d like my window to always be just in front of the target 
> window. Is this possible?
> 
> Thanks in advance for any ideas.
> 
> 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/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

Pinning a Window to a Window

2016-04-22 Thread Dave 
Hi All, 

Is there any way of “pinning” one of my App’s windows so it is always in front 
of a window owned by another application? I’m using a Floating Window style at 
the moment, which works ok, but the window floats in fronts of everything. I’d 
like my window to always be just in front of the target window. Is this 
possible?

Thanks in advance for any ideas.

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

Re: Thoughts on autolayout

2016-04-22 Thread Roland King 
I’ve never had to do anything like step 4. I’ve certainly added or changed 
constraints and fetched up a load of red boxes but never does it take more than 
a little bit of consideration to work out which constraints to remove or 
change. 

Basically - it just isn’t that hard. 

> On 22 Apr 2016, at 17:09, Stephane Sudre  wrote:
> 
> I tend to believe that it's because of step 4 that some developers
> (#include me) still do not like auto layout. Because even with a very
> simple view, you can waste a lot of time with this step.
> 
> On Thu, Apr 21, 2016 at 9:49 PM, Bill Cheeseman  wrote:
>> 
>>> On Apr 21, 2016, at 3:19 PM, Charles Srstka  
>>> wrote:
>>> 
>>> Am I the only one who likes autolayout?
>> 
>> 
>> No, I like it, too. I developed an approach that I'm comfortable with, and 
>> if I stick to it I can get the job done quickly. Of course, trying to 
>> accomplish something I haven't done before requires a little more thought, 
>> but I find that I can figure it out pretty quickly. It almost comes natural 
>> now.
>> 
>> I use IB exclusively. My approach goes like this, on a one-window-at-a-time 
>> or one-view-at-a-time basis:
>> 
>> 1. Drag all the views and controls onto the canvas and drop them more or 
>> less where I want them to end up. Don't waste any time trying to align them 
>> or make them the right size exactly -- just get position and size 
>> approximately right and move on. Leave it looking a little ragged. Above 
>> all, don't create any constraints yet.
>> 
>> 2. Write enough of the application code to get a sense whether the layout 
>> needs to be changed. Change it as needed, but again don't waste any time 
>> getting it exactly right and don't create any constraints yet.
>> 
>> 3. When the design feels like its ready to be frozen, create the 
>> constraints. DO NOT move the controls and views into the exact place they 
>> belong and then add constraints -- instead, do it the other way around: 
>> create the constraints first and then tell the controls and views to obey 
>> them. It will be much easier to see that they all moved into the right 
>> place, because they will all move a relatively short distance. More on this 
>> step below.
>> 
>> 4. Every time you tell a window or view to obey new constraints, watch very 
>> carefully. If the controls and views move or resize in unexpected ways, or 
>> disappear completely, immediately choose undo to get back to where you were 
>> (with all the controls and views in approximately the right locations). Then 
>> figure out which constraint you left out or got wrong, and fix it. 
>> Repeatedly undo and fix as needed.
>> 
>> 5. When you think you're done, lock the constraints down and do a lot of 
>> window resizing, divider dragging, and so on to test them.
>> 
>> More on step 3. I create constraints the way I read: start at the top left 
>> corner, move item by item to the right, then move down one "row" and start 
>> at the left again, and so on until I reach the bottom right corner. This 
>> leads to some useful consistencies to help my brain figure out why something 
>> went wrong. (a) For example, it is often only the leftmost button in the top 
>> "row" of controls that needs a top constraint to the superview; the other 
>> buttons in that "row" will have their vertical dimension controlled by 
>> baseline or center alignment, or something similar. (b) Horizontal 
>> constraints are easily made complete, because I account for each piece one 
>> step at a time from left to right: leading constraint, width constraint, 
>> trailing constraint, etc. (c) I don't worry about hugging priorities and the 
>> like until all else fails, because the default priorities are designed to be 
>> right for most situations.
>> 
>> --
>> 
>> Bill Cheeseman - wjcheese...@comcast.net
>> 
>> ___
>> 
>> 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/dev.iceberg%40gmail.com
>> 
>> This email sent to dev.iceb...@gmail.com
> 
> 
> 
> -- 
> Packaging Resources - http://s.sudre.free.fr/Packaging.html
> 
> ___
> 
> 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/rols%40rols.org
> 
> This email sent to r...@rols.org


___

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

Re: Thoughts on autolayout

2016-04-22 Thread Stephane Sudre 
I tend to believe that it's because of step 4 that some developers
(#include me) still do not like auto layout. Because even with a very
simple view, you can waste a lot of time with this step.

On Thu, Apr 21, 2016 at 9:49 PM, Bill Cheeseman  wrote:
>
>> On Apr 21, 2016, at 3:19 PM, Charles Srstka  wrote:
>>
>> Am I the only one who likes autolayout?
>
>
> No, I like it, too. I developed an approach that I'm comfortable with, and if 
> I stick to it I can get the job done quickly. Of course, trying to accomplish 
> something I haven't done before requires a little more thought, but I find 
> that I can figure it out pretty quickly. It almost comes natural now.
>
> I use IB exclusively. My approach goes like this, on a one-window-at-a-time 
> or one-view-at-a-time basis:
>
> 1. Drag all the views and controls onto the canvas and drop them more or less 
> where I want them to end up. Don't waste any time trying to align them or 
> make them the right size exactly -- just get position and size approximately 
> right and move on. Leave it looking a little ragged. Above all, don't create 
> any constraints yet.
>
> 2. Write enough of the application code to get a sense whether the layout 
> needs to be changed. Change it as needed, but again don't waste any time 
> getting it exactly right and don't create any constraints yet.
>
> 3. When the design feels like its ready to be frozen, create the constraints. 
> DO NOT move the controls and views into the exact place they belong and then 
> add constraints -- instead, do it the other way around: create the 
> constraints first and then tell the controls and views to obey them. It will 
> be much easier to see that they all moved into the right place, because they 
> will all move a relatively short distance. More on this step below.
>
> 4. Every time you tell a window or view to obey new constraints, watch very 
> carefully. If the controls and views move or resize in unexpected ways, or 
> disappear completely, immediately choose undo to get back to where you were 
> (with all the controls and views in approximately the right locations). Then 
> figure out which constraint you left out or got wrong, and fix it. Repeatedly 
> undo and fix as needed.
>
> 5. When you think you're done, lock the constraints down and do a lot of 
> window resizing, divider dragging, and so on to test them.
>
> More on step 3. I create constraints the way I read: start at the top left 
> corner, move item by item to the right, then move down one "row" and start at 
> the left again, and so on until I reach the bottom right corner. This leads 
> to some useful consistencies to help my brain figure out why something went 
> wrong. (a) For example, it is often only the leftmost button in the top "row" 
> of controls that needs a top constraint to the superview; the other buttons 
> in that "row" will have their vertical dimension controlled by baseline or 
> center alignment, or something similar. (b) Horizontal constraints are easily 
> made complete, because I account for each piece one step at a time from left 
> to right: leading constraint, width constraint, trailing constraint, etc. (c) 
> I don't worry about hugging priorities and the like until all else fails, 
> because the default priorities are designed to be right for most situations.
>
> --
>
> Bill Cheeseman - wjcheese...@comcast.net
>
> ___
>
> 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/dev.iceberg%40gmail.com
>
> This email sent to dev.iceb...@gmail.com



-- 
Packaging Resources - http://s.sudre.free.fr/Packaging.html

___

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