Date   

Re: How to write better Swift

Fritz Anderson
 

I'm missing something, possibly because the example code is abbreviated. Is this not equivalent?

var status: StatusEnum = .uninitialized {
// Sorry, "magic number" literals
// make my teeth itch
didSet {
guard status != oldValue else { return }
switch status {
// etc.
}
}
}

    — F

On Jul 8, 2017, at 12:12 PM, Quincey Morris <quinceymorris@...> wrote:

On Jul 8, 2017, at 06:08 , Gerriet M. Denkmann <g@...> wrote:

is this “privateStatus” really necessary?

This has been bugging me a lot lately. I don’t know a way of avoiding the need for an extra property, and if there is, I’d be glad to hear about it too.

In a way, it’s harmless, but I find it clutters up a sequence of property declarations with what is basically boilerplate.

I’ve been thinking about possible alternatives:

1. (Roughly) Let references to the property name inside computed getters and setters to refer to the backing store, turning a computed property back into a [sort of] stored property.

2. Put the declaration of the private property inside the real property:

var status: Int
{
var privateStatus: Int
get{ return privateStatus }
set(new)
{
if new == privateStatus {return}

… do something here …

privateStatus = new
}
}

The second one is functionally identical to the original code (so it doesn’t need any new compiler design), except for the scoping of the private property name.


Re: How to write better Swift

bartramf@...
 

How about using the ‘didset’ observer?
 
class SomeClass
{
var status: Int {
didset(oldValue)
{
guard oldValue != status else { return }
… do something here …
}
}
}


Re: How to write better Swift

 

You can implement a property observer instead. Here’s an example from the Swift book:

class StepCounter {
var totalSteps: Int = 0 {
willSet(newTotalSteps) {
print("About to set totalSteps to \(newTotalSteps)")
}
didSet {
if totalSteps > oldValue {
print("Added \(totalSteps - oldValue) steps")
}
}
}
}

—Jens


Re: How to write better Swift

Quincey Morris
 

On Jul 8, 2017, at 06:08 , Gerriet M. Denkmann <g@...> wrote:

is this “privateStatus” really necessary?

This has been bugging me a lot lately. I don’t know a way of avoiding the need for an extra property, and if there is, I’d be glad to hear about it too.

In a way, it’s harmless, but I find it clutters up a sequence of property declarations with what is basically boilerplate.

I’ve been thinking about possible alternatives:

1. (Roughly) Let references to the property name inside computed getters and setters to refer to the backing store, turning a computed property back into a [sort of] stored property.

2. Put the declaration of the private property inside the real property:

var status: Int
{
var privateStatus: Int
get{ return privateStatus }
set(new)
{
if new == privateStatus {return}

… do something here …

privateStatus = new
}
}

The second one is functionally identical to the original code (so it doesn’t need any new compiler design), except for the scoping of the private property name.


How to write better Swift

Gerriet M. Denkmann
 

This works (Xcode Version 8.3.2 (8E2002)):

class SomeClass
{
private var privateStatus: Int

var status: Int
{
get{ return privateStatus }
set(new)
{
if new == privateStatus {return}

… do something here …

privateStatus = new
}
}
}

But is this “privateStatus” really necessary?
If not, how can it be avoided?

Gerriet.


BundleDisplayName

Gerriet M. Denkmann
 

macOS 12.5, Xcode Version 8.3.2 (8E2002)

App with Base Internationalisation; Development Language = English, localised for German.

Target = “TargetName” (probably same as PRODUCT_NAME)

Both InfoPlist.strings (Base) and InfoPlist.strings (German) have:
CFBundleDisplayName = “RealName”;

Activity Monitor shows: “RealName”; as do both:
[NSBundle mainBundle].localizedInfoDictionary[@“CFBundleDisplayName”] and
[NSRunningApplication currentApplication].localizedName.

But Finder shows “TargetName” (if system language = English).

When I log in as a user with system language = German, Finder shows: “RealName” as it should.

I find this very confusing and not quite what I expected.

How can I persuade Finder to always use the value from InfoPlist.strings regardless of system language?

Gerriet.


Re: Swift name manglings

Gerriet M. Denkmann
 

On 8 Jul 2017, at 01:16, Quincey Morris <quinceymorris@...> wrote:

On Jul 7, 2017, at 11:10 , Jens Alfke <jens@...> wrote:

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.
There’s an “Inherit From Target” checkbox in recent Xcodes, in the Identity inspector under the module name field. I would expect that, if checked, to cause the module name change to be picked up automatically.
I always wondered what this checkbox is good for.
You are right: when this is checked for all custom classes in IB then the app runs as expected.

As Jens mentioned I could “could update [the module names] manually in the IB inspector”, but using this checkbox is more future proof.

Thanks a lot for your help!

Kind regards,

Gerriet.


Re: Swift name manglings

Quincey Morris
 

On Jul 7, 2017, at 11:10 , Jens Alfke <jens@...> wrote:

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.

There’s an “Inherit From Target” checkbox in recent Xcodes, in the Identity inspector under the module name field. I would expect that, if checked, to cause the module name change to be picked up automatically.

It may be that this project was created before that checkbox existed, hence the need to change the module name manually. If not, if it’s checked but the module didn’t change automatically, it sounds like it needs a bug report.


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@...>:

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@...> wrote:

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

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.
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@... 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@...> 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@... 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@...> 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@... Urbana, IL (217) 721-9981

1441 - 1460 of 1475