Date   

CFPasteboardCreateSandboxExtensionDataFromCFData

2551phil
 

Swifty question, macOS:

As part of its functionality, my sandboxed app allows users to search for files across the entire filesystem. In the results of the search (displayed in an NSTableview), I implement the double-click argument on the table to show the file in the Finder. 

I do this with

NSWorkspace.shared().selectFile(_, inFileViewerRootedAtPath: )

Everything works fine, save for the fact that Xcode’s console prints the following warning:

__CFPasteboardCreateSandboxExtensionDataFromCFData(CFDataRef) : failed to obtain sandbox extension data for url [file:///<path to file>]


I’ve done the usual searches, seen a couple of mentions of this before, but nothing really concrete as to either i. whether it’s benign and ii. how to avoid the warning. 

While it seems that the warning doesn’t affect functionality, I’m worried it’ll be a red flag for the App Store review. Any thoughts on how I can deal with this?


TIA


Phil
@sqwarq


Sizing NSCollectionViewItems to fit

Steve Mills
 

I'm doing the development of a small app on 10.10, so all the 10.11 additions to NSCollectionView aren't available. I have a window filled with an NSCollectionView in a scrollview, which contains 1 row and scrolls horizontally, and I'd like to resize the NSCollectionViewItems (which are subclassed) to proportionally fit the height of the collection view at the time of being inserted and when the window resizes.

I tried changing the bounds of the itemPrototype in a notification for the collection view's frame being changed, but that's probably not all that needs to happen. Any ideas?

Sent from iCloud's ridiculous UI, so, sorry about the formatting


Re: Sizing NSCollectionViewItems to fit

Jon Gotow
 

On Jun 27, 2017, at 2:07 PM, Steve Mills <sjmills@mac.com> wrote:

I'm doing the development of a small app on 10.10, so all the 10.11 additions to NSCollectionView aren't available. I have a window filled with an NSCollectionView in a scrollview, which contains 1 row and scrolls horizontally, and I'd like to resize the NSCollectionViewItems (which are subclassed) to proportionally fit the height of the collection view at the time of being inserted and when the window resizes.

I tried changing the bounds of the itemPrototype in a notification for the collection view's frame being changed, but that's probably not all that needs to happen. Any ideas?
Did you call -reloadData after resizing the itemPrototype? You have to get the collection view to regenerate all the views with the newly resized prototype.

- Jon


Re: Sizing NSCollectionViewItems to fit

Steve Mills
 

On Jun 27, 2017, at 03:36 PM, Jon Gotow <gotow@...> wrote:

Did you call -reloadData after resizing the itemPrototype? You have to get the collection view to regenerate all the views with the newly resized prototype.

Annoyingly, reloadData wasn't introduced until 10.11, so that's not going to work.

Sent from iCloud's ridiculous UI, so, sorry about the formatting

 


Re: Sizing NSCollectionViewItems to fit

Jon Gotow
 

On Jun 27, 2017, at 2:39 PM, Steve Mills <sjmills@mac.com> wrote:

Annoyingly, reloadData wasn't introduced until 10.11, so that's not going to work.
Oh right - well, there's the manual 'reloadData' method - set content to an empty array, then back to your content array :-/

- Jon


Re: Sizing NSCollectionViewItems to fit

Steve Mills
 

On Jun 27, 2017, at 03:07 PM, Steve Mills <sjmills@...> wrote:

I'm doing the development of a small app on 10.10, so all the 10.11 additions to NSCollectionView aren't available. I have a window filled with an NSCollectionView in a scrollview, which contains 1 row and scrolls horizontally, and I'd like to resize the NSCollectionViewItems (which are subclassed) to proportionally fit the height of the collection view at the time of being inserted and when the window resizes.

I tried changing the bounds of the itemPrototype in a notification for the collection view's frame being changed, but that's probably not all that needs to happen. Any ideas?

Got it working simply by changing the collectionView.maxItemSize to the size I want in the NSViewFrameDidChangeNotification callback. Whodathunk.

Sent from iCloud's ridiculous UI, so, sorry about the formatting

 


How to Correctly Add subviews considering auto layout

Dave
 

iOS - Landscape Only.

Hi,

I have a View Controller in a Storyboard that contains a hierarchy of Stack Views, the leafs are a Custom Class that inherits from UIView. The Custom Class 

LTWGameCellView : LTWDrawFrameView

LTWDrawFrameView is Custom Class has methods in it that draw a frame around the View - this works fine.

LTWGameCellView inherits from LTWDrawFrameView and add up to 2 UIImageView subviews to itself. The Images are resources in the project that are loaded at runtime and added to the LTWGameCellView. The idea is to draw a Frame Around but the Image, but also to inset the image a small amount.



I’m using auto layout and it works ok, except that I’m not sure I’m what I’m doing is correct taking into account auto layout - please see code below. The “setCellAsPlayedWithPieceImage:" is called when the a player plays a piece into the Cell.

I want the (smaller) image to be centered in the (square) DrawFrame View.

Firstly I’m unsure if self.bounds is the correct starting place for placing the image view and if I should be setting the frame anyway? Maybe I should be adding a constraint to the Image View before I add it as a subview?

The problem I am seeing is that on the first run, the board is not setup correctly in that the frames are different, if I re-restart a new game after the first time, all is well. This is *was* being called from the “viewWillAppear:" of the owing view controller (see code below), so I changed things so that “newGame” is called from “viewDidAppear:”, this works well BUT you see an annoying flicker when the View Controller first opens.

Any advice or help on this would be greatly appreciated.

All the Best
Dave

-(void) viewWillAppear:(BOOL) theAnimateFlag
{
[super viewWillAppear:theAnimateFlag];

[self newChaosCellViewDictionary];
//[self newGame];
}


-(void) viewDidAppear:(BOOL) theAnimateFlag
{
[super viewDidAppear:theAnimateFlag];

[self newGame];
}

These are the methods I am using to create the ImageViews and add them as a subview.

The "setImageForCellWithImageFilePath:” setup up an Image View and stores it as a property. Then, later on  “setCellAsNormal” is called to Add the subview, then later still, “setCellAsNormal'





-(void) setImageForCellWithImageFilePath:(NSString*) theImageFilePath
{
UIImage* myImage;
UIImageView* myImageView;
CGRect myImageFrameRect;
NSInteger myLineWidth;

//**
//** Setup the Line Width (also the Inset size of the Image
//**
myLineWidth = kLTWChaosCellViewFrameLineSize;

//**
//** Inset the Image Rectangle
//**
myImageFrameRect = self.bounds;
myImageFrameRect = CGRectInset(myImageFrameRect,myLineWidth,myLineWidth);

myImage = [[UIImage alloc] initWithContentsOfFile:theImageFilePath];
if (myImage == nil)
{
LTWAssertAlways(@"Cell Image Could Not be Found");
return;
}

//**
//** Create the Image View
//**
myImageView = [[UIImageView alloc] initWithImage:myImage];
[myImageView setFrame:myImageFrameRect];
[myImageView setBackgroundColor:[UIColor clearColor]];

self.pCellImageView = myImageView;

//**
//** Setup the Frame - Causes Redraw
//**
[self setFrameColor:[UIColor blackColor]];
[self setFrameLineWidth:myLineWidth];
[self setDrawFrame:YES];
}



-(void) setCellAsNormal
{
self.pCellKind = kLTWChaosBoardCellKindNormal;

[self setBackgroundColor:self.pCellUIColor];
[self removeAllSubviews];
[self addSubview:self.pCellImageView];
}



-(void) setCellAsPlayedWithPieceImage:(UIImage*) thePieceImage
{
UIImageView* myImageView;
CGRect myFrameRect;

myFrameRect = self.bounds;
myFrameRect = CGRectInset(myFrameRect,6,6);

myImageView = [[UIImageView alloc] initWithImage:thePieceImage];
[myImageView setFrame:myFrameRect];
[myImageView setBackgroundColor:[UIColor clearColor]];

//**
//** Add as Second Image View
//**
[self setBackgroundColor:self.pCellUIColor];
[self addSubview:myImageView];
}




_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@...)

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/dave%40looktowindward.com

This email sent to dave@...


FYI: Mike Ash analyzes objc_msgsend

 

Mike Ash has been offline for a while, but his Friday Q&A is back with a detailed line-by-line analysis of the objc_msgsend function on ARM64. This is the core Objective-C runtime function that sends messages / calls methods on objects — every bracketed expression or property access turns into a call to this function (and so do Swift calls to @objc classes.) It’s written in assembly code to make it as fast as possible, and it’s very clever but it’s not magic; Mike explains it very well. I’m always fascinated to find out how these kinds of things work.

—Jens


Alternative to Auto Layout?

Dave
 

Hi All,

Does anyone know of an alternative for Auto Layout.

I find myself wasting so much time with it as to be ridiculous, so I’d like to get away from it if possible.

I’m writing a Game for iPhone, iPad and Mac. I’ve decided to have 3 separate projects for these rather than lump it all into one giant project. The Game Engine will port with no compile problems onto all 3 platforms so all I need to do is the UI for the 3. I’m concentrating on the iPhone for now.

The game doesn’t really have a massive UI. There is a Game Setup screen (Window) and a Game Play screen. I’m only worrying about the Main Game Play Screen for now, this contains a left “Player” Area and a right Board area. The Player Area is 1/3 of the width of the screen (this App is landscape only) and the board takes up the other 2/3’s. The board was quite easy to get working with a bunch of nested Stack Views, but the rest of Ui is proving to be too hard to do with AU.

When I started this project, I decided to give AU a try (I’d previously tried to get on with it twice before) and had hoped that the tools would have improved enough to make it usable and practical to use, however, sadly this isn’t the case, so its better to back out now rather than further down the line.

So, how to lay this out without AU?

I’ve know how I've done this in the past, and adapting the technique in this case would mean:

1. Picking a Nominal device for the initial design, I’d pick iPhone 5s in this case, take the Size of the Root View 568, 320 which would be a constant in the App.
2. The App would read the size of the Root View and set a scaling factor.
3. The App would create and position the views using this scaling factor when it starts up.

I agree its not as flexible as using AU, but it a whole lot quicker and much more maintainable since you are not at the mercy of XCode/IB.

Any one have any other ideas of how to do this?

All the Best
Dave








which is to have a look at the Root View’s size and


Re: Alternative to Auto Layout?

Steve Mills
 

On Jul 4, 2017, at 06:36, Dave <dave@looktowindward.com> wrote:

Does anyone know of an alternative for Auto Layout.

I find myself wasting so much time with it as to be ridiculous, so I’d like to get away from it if possible.
No. Find a good guide that will really teach you how to use it correctly and you'll thank yourself for taking the small amount of time it takes.

So, how to lay this out without AU?
What's AU? Audio Units?

Steve via iPad


Re: Alternative to Auto Layout?

Steve Christensen
 

It sounds like a really easy task. Unless there is something else you haven't mentioned the basic idea is to have two views that sit side-by-side, where the ratio of widths is 1:2. If so then you end up with a view hierarchy like this:

controller_view
player_view
board_view

In IB, add two views to controller_view and position them so that their common edges touch and that the other edges are aligned with controller_view. Click on the "add new constraints" button and add constraints to enforce the edge positioning for player_view and then for board_view. Once you apply them you will notice that IB is flagging an error because there are not enough constraints to specify the widths of the two views. Ignore it.

Next, make sure that player_view and board_view are both selected, click on the "add new contraints" button again and click the "equal widths" checkbox, then apply the constraint. IB should now resize the two views so that they have equal widths. You're almost there.

Finally, making sure that just player_view is selected, edit the "equal height to: board_view" contraint and change the multiplier to 2. All done.

Now the views should track the actual screen size, keeping their respective widths in proportion to 1/3 and 2/3 of the screen width.

On Jul 4, 2017, at 4:36 AM, Dave <dave@looktowindward.com> wrote:

Hi All,

Does anyone know of an alternative for Auto Layout.

I find myself wasting so much time with it as to be ridiculous, so I’d like to get away from it if possible.

I’m writing a Game for iPhone, iPad and Mac. I’ve decided to have 3 separate projects for these rather than lump it all into one giant project. The Game Engine will port with no compile problems onto all 3 platforms so all I need to do is the UI for the 3. I’m concentrating on the iPhone for now.

The game doesn’t really have a massive UI. There is a Game Setup screen (Window) and a Game Play screen. I’m only worrying about the Main Game Play Screen for now, this contains a left “Player” Area and a right Board area. The Player Area is 1/3 of the width of the screen (this App is landscape only) and the board takes up the other 2/3’s. The board was quite easy to get working with a bunch of nested Stack Views, but the rest of Ui is proving to be too hard to do with AU.

When I started this project, I decided to give AU a try (I’d previously tried to get on with it twice before) and had hoped that the tools would have improved enough to make it usable and practical to use, however, sadly this isn’t the case, so its better to back out now rather than further down the line.

So, how to lay this out without AU?

I’ve know how I've done this in the past, and adapting the technique in this case would mean:

1. Picking a Nominal device for the initial design, I’d pick iPhone 5s in this case, take the Size of the Root View 568, 320 which would be a constant in the App.
2. The App would read the size of the Root View and set a scaling factor.
3. The App would create and position the views using this scaling factor when it starts up.

I agree its not as flexible as using AU, but it a whole lot quicker and much more maintainable since you are not at the mercy of XCode/IB.

Any one have any other ideas of how to do this?

All the Best
Dave


Re: Alternative to Auto Layout?

Dave
 

On 4 Jul 2017, at 14:52, Steve Mills <sjmills@mac.com> wrote:

On Jul 4, 2017, at 06:36, Dave <dave@looktowindward.com> wrote:

Does anyone know of an alternative for Auto Layout.

I find myself wasting so much time with it as to be ridiculous, so I’d like to get away from it if possible.
No. Find a good guide that will really teach you how to use it correctly and you'll thank yourself for taking the small amount of time it takes.
There isn’t one that I can find and there’s no help available just people telling me to find a good guide! If there was a good guide I’d use it - there isn’t one! So the best thing to do is no stop using it now, before it gets too entrenched. I’ve already done this in a number of Apps, and I’ll do the same here unless anyone has anything else I could look at that does something similar.

I’d advise anyone thinking of adopting Auto Layout to not waste their time, if XCode/IB were any good you might stand a fighting chance, but as it is you are in for a hard and long battle before you realise you are better off without it.


So, how to lay this out without AU?
What's AU? Audio Units?
Apple mail, correcting AL!

All the Best
Dav


Re: Alternative to Auto Layout?

Dave
 

Hi,

As I said, the board view is working ok with Auto Layout and also the Frame of the Player View is also working, but that’s the easy bit!

I want to display the following information:

Game: 999                Round: 999

Player:  XXXXXXXXXXXXXXXX

Score: 999                  Total: 999

   Piece Picked  Piece Played
 
<16x16> <16x16>   <16x16> <16>

                    My Pieces
[H Scroll View of Pieces] (Views containing images)

               Opponents Pieces

[H Scroll View of Pieces] (Views containing images)


I’ve sort of got this working with Auto Layout but its so complex and if I want to do the slightest change or worse still add to components of left view, I have to change loads of constraints and then if you are lucky it might work, most of the time it send something else off to the wild-beyond and screws up the initial value. 

I want something I can easily change which using manual layout is easy. 

Apart from anything else, I reckon there are at least 100 constraints just to do the above, I can’t see how this can be efficient, especially as manual layout is sooooo fast.

Can anyone see anything wrong of doing it the way I proposed? e.g. Reading the Root View of the Root View Controller to find it size and then scaling accordingly?

In IB, add two views to controller_view and position them so that their common edges touch and that the other edges are aligned with controller_view. Click on the "add new constraints" button and add constraints to enforce the edge positioning for player_view and then for board_view. Once you apply them you will notice that IB is flagging an error because there are not enough constraints to specify the widths of the two views. Ignore it.

I’ve not bothered with separate View Controller, I have one Game Controller, which controls both views, the reason for this is that the Game VC is a delegate of the Game Engine, and makes calls to it, in this case it needs access to both Views…...

All the Best
Dave



On 4 Jul 2017, at 17:33, Steve Christensen <punster@...> wrote:

It sounds like a really easy task. Unless there is something else you haven't mentioned the basic idea is to have two views that sit side-by-side, where the ratio of widths is 1:2. If so then you end up with a view hierarchy like this:

controller_view
player_view
board_view

In IB, add two views to controller_view and position them so that their common edges touch and that the other edges are aligned with controller_view. Click on the "add new constraints" button and add constraints to enforce the edge positioning for player_view and then for board_view. Once you apply them you will notice that IB is flagging an error because there are not enough constraints to specify the widths of the two views. Ignore it.

Next, make sure that player_view and board_view are both selected, click on the "add new contraints" button again and click the "equal widths" checkbox, then apply the constraint. IB should now resize the two views so that they have equal widths. You're almost there.

Finally, making sure that just player_view is selected, edit the "equal height to: board_view" contraint and change the multiplier to 2. All done.

Now the views should track the actual screen size, keeping their respective widths in proportion to 1/3 and 2/3 of the screen width.


On Jul 4, 2017, at 4:36 AM, Dave <dave@...> wrote:

Hi All,

Does anyone know of an alternative for Auto Layout.

I find myself wasting so much time with it as to be ridiculous, so I’d like to get away from it if possible.

I’m writing a Game for iPhone, iPad and Mac. I’ve decided to have 3 separate projects for these rather than lump it all into one giant project. The Game Engine will port with no compile problems onto all 3 platforms so all I need to do is the UI for the 3. I’m concentrating on the iPhone for now.

The game doesn’t really have a massive UI. There is a Game Setup screen (Window) and a Game Play screen. I’m only worrying about the Main Game Play Screen for now, this contains a left “Player” Area and a right Board area. The Player Area is 1/3 of the width of the screen (this App is landscape only) and the board takes up the other 2/3’s. The board was quite easy to get working with a bunch of nested Stack Views, but the rest of Ui is proving to be too hard to do with AU.

When I started this project, I decided to give AU a try (I’d previously tried to get on with it twice before) and had hoped that the tools would have improved enough to make it usable and practical to use, however, sadly this isn’t the case, so its better to back out now rather than further down the line.

So, how to lay this out without AU?

I’ve know how I've done this in the past, and adapting the technique in this case would mean:

1. Picking a Nominal device for the initial design, I’d pick iPhone 5s in this case, take the Size of the Root View 568, 320 which would be a constant in the App.
2. The App would read the size of the Root View and set a scaling factor.
3. The App would create and position the views using this scaling factor when it starts up.

I agree its not as flexible as using AU, but it a whole lot quicker and much more maintainable since you are not at the mercy of XCode/IB.

Any one have any other ideas of how to do this?

All the Best
Dave




Re: Alternative to Auto Layout?

 


On Jul 4, 2017, at 4:36 AM, Dave <dave@...> wrote:

Does anyone know of an alternative for Auto Layout.
I find myself wasting so much time with it as to be ridiculous, so I’d like to get away from it if possible.

That’s been my opinion of auto-layout too … in theory it should be awesome, but configuring it is ridiculously complex. Every iteration of IB seems to make some of the process easier, but adds more bells and whistles, keeping the workload the same.

There are some alternative UI layout/rendering frameworks … I took a brief look at Texture last weekend and it looks nice, but has its own learning curve. Facebook's ComponentKit looks similar. Both are iOS only though.

(I found both of those through the Awesome iOS directory. There is an Awesome-MacOS as well, but unfortunately it’s focused more on end-user apps, not APIs.)

—Jens


Re: Alternative to Auto Layout?

 


On Jul 4, 2017, at 5:52 AM, Steve Mills <sjmills@...> wrote:

No. Find a good guide that will really teach you how to use it correctly and you'll thank yourself for taking the small amount of time it takes.

Great. Where’s that good guide? Xcode’s own documentation is so sparse as to be useless. The 3rd party books I’ve seen are massive doorstops aimed at newbies that spend 990 pages on the basics of Cocoa programming and 10 pages on stuff I don’t know about IB. They also do everything in step-by-step tutorial form, which I find nearly useless for learning from, because it shows me how to do one specific thing without explaining the principles or all the possibilities.

What I want is something akin to the best of the O’Reilly “Nutshell” books, which explain and document things clearly without too much hand-holding and without bloating the page-count with endless screenshots.

—Jens


Re: Alternative to Auto Layout?

David Young
 

On Tue, Jul 04, 2017 at 01:04:04PM -0700, Jens Alfke wrote:

On Jul 4, 2017, at 4:36 AM, Dave <dave@looktowindward.com> wrote:

Does anyone know of an alternative for Auto Layout.
I find myself wasting so much time with it as to be ridiculous, so I’d like to get away from it if possible.
That’s been my opinion of auto-layout too … in theory it should be awesome, but configuring it is ridiculously complex. Every iteration of IB seems to make some of the process easier, but adds more bells and whistles, keeping the workload the same.
Jens, Dave,

I agree that auto-layout is a bit touchy. If it's any help, I think
that under the hood it is solving a problem in "linear programming,"
https://en.wikipedia.org/wiki/Linear_programming . I have had some
modest success by writing out my inequalities explicitly, and then
fiddling with the auto-layout API and/or IB until I achieved the
layout I wanted. It's been a while, but ISTR that IB would reset my
constraints for reasons that I did not understand or appreciate.

The polygon in the "pictorial representation" of a linear program hints
at the potential power of auto-layout. You can write inequalities that
approximate a circle or other shape, and then use them to constrain an
NSView's x,y-position or height & width. That comes in handy.

Dave

--
David Young
dyoung@pobox.com Urbana, IL (217) 721-9981


boxes & glue layout?

David Young
 

BTW, frequently I wish for the boxes & glue (& penalties) layout model
that Plass & Knuth famously used for typesetting (TeX and all that). I
believe the default layout manager for NSTextView uses that model. If
I'm not mistaken, there is no way to modify the strength of the glue
or the penalties without essentially re-implementing the Plass-Knuth
algorithm? Or has a set of text attributes for setting those parametes
eluded my research?

Dave

--
David Young
dyoung@pobox.com Urbana, IL (217) 721-9981


Scroll View Problems

Dave
 

Hi All,

Do I *need* to add constraints to a Scroll View or the Views inside a Scroll View?

I’m trying to avoid applying any constraints in a View, I’ve started again using the old fashioned way of doing things, e.g. “Auto Resizing”. This works really well of everything I need but when I try to add a scroll view, I get errors saying that it needs constants for the View inside the Scroll View and Needs Constraints for X Position and has “Ambiguous Scrollable Content Height.

Can anyone tell me how to do make a simple Scroll View work these days?

If I add constraints, it then moans about the other views needing constraints, if I add them, it will go wrong again. I’m trying to get a half way house, where auto layout is used to manage the two main game Views, Left Area 1/3 Screen and Right Area 2/3’s of the Screen.

I can do ok with everything I need except a Scroll View? Is what I am trying to do impossible? If I stop using Auto Layout altogether, will Scroll Views work?

Thanks for any help - I’m really having a hard time getting the simplest UI working.

All the Best
Dave


Re: Scroll View Problems

Dave
 

Sorry should have said, XCode 8.3.3. and iOS.

On 5 Jul 2017, at 18:29, Dave <dave@looktowindward.com> wrote:

Hi All,

Do I *need* to add constraints to a Scroll View or the Views inside a Scroll View?

I’m trying to avoid applying any constraints in a View, I’ve started again using the old fashioned way of doing things, e.g. “Auto Resizing”. This works really well of everything I need but when I try to add a scroll view, I get errors saying that it needs constants for the View inside the Scroll View and Needs Constraints for X Position and has “Ambiguous Scrollable Content Height.

Can anyone tell me how to do make a simple Scroll View work these days?

If I add constraints, it then moans about the other views needing constraints, if I add them, it will go wrong again. I’m trying to get a half way house, where auto layout is used to manage the two main game Views, Left Area 1/3 Screen and Right Area 2/3’s of the Screen.

I can do ok with everything I need except a Scroll View? Is what I am trying to do impossible? If I stop using Auto Layout altogether, will Scroll Views work?

Thanks for any help - I’m really having a hard time getting the simplest UI working.

All the Best
Dave




Re: Alternative to Auto Layout?

Alex Zavatone
 

I’ve heard people speak well of Masonry, though I have no experience with it.

- Alex Zavatone

On Jul 4, 2017, at 4:05 PM, David Young <dyoung+cocoa@pobox.com> wrote:

On Tue, Jul 04, 2017 at 01:04:04PM -0700, Jens Alfke wrote:

On Jul 4, 2017, at 4:36 AM, Dave <dave@looktowindward.com> wrote:

Does anyone know of an alternative for Auto Layout.
I find myself wasting so much time with it as to be ridiculous, so I’d like to get away from it if possible.
That’s been my opinion of auto-layout too … in theory it should be awesome, but configuring it is ridiculously complex. Every iteration of IB seems to make some of the process easier, but adds more bells and whistles, keeping the workload the same.
Jens, Dave,

I agree that auto-layout is a bit touchy. If it's any help, I think
that under the hood it is solving a problem in "linear programming,"
https://en.wikipedia.org/wiki/Linear_programming . I have had some
modest success by writing out my inequalities explicitly, and then
fiddling with the auto-layout API and/or IB until I achieved the
layout I wanted. It's been a while, but ISTR that IB would reset my
constraints for reasons that I did not understand or appreciate.

The polygon in the "pictorial representation" of a linear program hints
at the potential power of auto-layout. You can write inequalities that
approximate a circle or other shape, and then use them to constrain an
NSView's x,y-position or height & width. That comes in handy.

Dave

--
David Young
dyoung@pobox.com Urbana, IL (217) 721-9981


1 - 20 of 1427