Date   

Re: Swift name manglings

 


On Jul 7, 2017, at 10:31 AM, Gerriet M. Denkmann <g@...> wrote:

Unknown class ‘_TtC4<OldName>10<SomeClass>’, using ‘NSObject’ instead. Encountered in Interface Builder file at path…

Changing the target name changes the product name and module name (by default unless you explicitly specify them.)
The references to your Swift classes in IB still have the old module name in them. You could update them manually in the IB inspector.

—Jens


Swift name manglings

Gerriet M. Denkmann
 

macOS 12.5, Xcode Version 8.3.2 (8E2002), a Cocoa Swift project.

Worked fine; then I changed the name of the Target from “OldName” to "NewName".

Now nothing works. I get told:

Unknown class ‘_TtC4<OldName>10<SomeClass>’, using ‘NSObject’ instead. Encountered in Interface Builder file at path…

I tried cleaning the build folder - but still.

So I had to change the Target back to OldName.

How can one tell Xcode (or the compiler) to redo the name-mangling?

Gerriet.


Re: Alternative to Auto Layout?

Dave
 

I tried that, but the problem is that, you need a lot of sub-StackViews and text is spread across them, when a resize occurs, the font sizes etc. stop being uniform, e.g. The text:

Game: 123    Round: 321  

“Game" would be in one size font and “Round” another and the same for the value fields, you can solve this to some extent by tweaking properties, but what you end up with it a) Not as good as if you did it yourself, b) Hard to understand (try coming back to a UI design a couple of weeks later and trying to figure the constraints!), and c) difficult to change.

Not only that, its so slow with AL, it takes seconds on my system to switch between different screen sizes (e.g. iPhone 5 to iPhone 7+).

Anyway, I’ve stoped using AL now and am glad I did.

All the Best
Dave

On 5 Jul 2017, at 20:27, Andreas Mayer <andreas@...> wrote:


Am 04.07.2017 um 21:37 schrieb Dave <dave@...>:

I want to display the following information:

This looks like something that can be almost completely solved just by using stack views (NSStackView, UIStackView).

May be worth a try.


- Andreas




Life without Auto Layout

Dave
 

Hi All,

I spent all of yesterday and the first part of today purging Auto Layout from my Main Game View Controller and I’m soooooo happy I did it - my XCode life is so much better! Things happen quickly again, using Auto Layout, it would takes 3 to 4 seconds to switch between the different screen sizes, e.g. iPhone 5 to 7+, now its instant.

In the end I added a “ManualLayout” Storyboard and switched off Auto Layout. I actually managed to make it work using the old style auto-resizing, so I didn’t even have to setup the frame rectangles although that would be easy to do. I now have so much control over my layout, the board looks better, because I could fine-tine the positioning which was a complete nightmare using AL and in the end I gave trying, settling for a less attractive board.

Its a shame, Auto Layout should be sooooo good, but a combo of XCode, lack of good documentation means that its just not practical to use it. In the case of this game it didn’t offer that much compared to the work involved, it really shouldn’t take 3+ days to make something that can scale from iPhone 5 to iPhone 7+………..

I think I’ve figured out how to do a portrait version too (something I would dream of doing in AL), basically I’ll just make my existing View Controller a Base Class and add a couple of subclasses for Portrait and Landscape.

Thanks to everyone that tried to help, especially Jens, who gave me the push I needed to get rid of it!

Much Happier Today!

All the Best
Dave


Re: Alternative to Auto Layout?

Andreas Mayer
 

Am 04.07.2017 um 21:37 schrieb Dave <dave@looktowindward.com>:

I want to display the following information:
This looks like something that can be almost completely solved just by using stack views (NSStackView, UIStackView).

May be worth a try.


- Andreas


Re: Scroll View Problems

Luther Baker
 

I believe this is still relevant ...


Hopefully you find that helpful.

-Luther


On Wed, Jul 5, 2017 at 11:34 AM, Dave <dave@...> wrote:
Sorry should have said, XCode 8.3.3. and iOS.

> On 5 Jul 2017, at 18:29, Dave <dave@...> 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?

 


On Jul 5, 2017, at 5:56 AM, Alex Zavatone <zav@...> wrote:

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

“Why, I wouldn’t become a Mason now if you went down on your lousy stinking knees and begged me!”
—John Cleese, “The Architect Sketch”

No seriously, I hadn’t heard of this before, but it looks very promising; thanks! Supports macOS too...
The Swift-ified version is called SnapKit:

—Jens


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



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




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


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


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


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?

 


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?

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?

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?

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?

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


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


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

1401 - 1420 of 1427