Date   

Re: BundleDisplayName

Quincey Morris
 

On Jul 9, 2017, at 07:45 , Gerriet M. Denkmann <g@...> wrote:

It never reads Base.lproj, even if the system language = Localization native development region = CFBundleDevelopmentRegion

The problem is that Xcode (obviously unaware of this Finder peculiarity) does NOT allow English as an additional localisation (because the development region already is English; so English speaking computers should just use Base.lproj).

What can be done?

I’m not sure I understand completely, but I think you’re missing one point.

As with the base localization, which (as you say) means that Xcode treats it as the “localization” for the development language, and you omit the actual localization for that language (English in your example), the Finder AFAIK uses the “unlocalized” bundle file name as the “base” file name. (Because it’s a bundle, it’s actually a directory name, but the principle is the same.)

If you the developer are on an English system, you can change the “base” file name any time you want, after the app bundle is created, by renaming it in the Finder. I do this all the time for my apps, and the final “base” name is nowhere in my Xcode project settings. Again AFAIK, this has *no* downstream consequences for localized non-English systems — as you’ve seen, the original name is irrelevant when the Finder actually applies localization to the name.

If you want to create the app with the desired English name during archiving, rather than renaming it later, then you must change build settings. AFAIK the one that controls the bundle’s file name is “Product Name”. The default value of this setting is “$(TARGET_NAME)”. If you don’t want the target name, you can put anything you want in there, minus the extension.

So, I assume that if you put the desired English name of your app in the Product Name setting, you’ll get the results you want in all localizations.


Re: BundleDisplayName

Gerriet M. Denkmann
 

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

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?
Finder (at least in macOS 12.5) seems to work like this:

When an app.bundle is copied into some folder (and only then), it reads TheApp.app/Contents/Resources/<system language>.lproj/InfoPlist.strings and uses the value of CFBundleDisplayName to display the app’s name.

It never reads Base.lproj, even if the system language = Localization native development region = CFBundleDevelopmentRegion

The problem is that Xcode (obviously unaware of this Finder peculiarity) does NOT allow English as an additional localisation (because the development region already is English; so English speaking computers should just use Base.lproj).

What can be done?

Gerriet.


Re: How to write better Swift

Quincey Morris
 

On Jul 8, 2017, at 17:15 , Jens Alfke <jens@...> wrote:

You can implement a property observer instead.

(Also to others suggesting will/didSet)

That doesn’t solve Gerriet’s problem. You can’t *prevent* setting the backing store without writing an actual setter. Similarly, if you want to constrain a value (e.g. keep an Int value >= 1), you can do it in didSet, but only at the cost of two writes to the backing store (which may have side effects).


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



1441 - 1460 of 1478