SPTextField auto-size interest?

[tconkling]

Hi Daniel,

I'm interested in adding auto-sizing support to SPTextField. Is this something you'd be interested in? If not, would you be amenable to a patch that makes SPTextField's internals protected instead of private, so that it can be subclassed? The functionality I want to add requires a new member variable, so it can't easily be added in a category.

[PrimaryFeather]

Hi Tim, thanks for the suggestion and the pull request!

Hm, I'm not 100% sure about this yet. I know that this is useful in some situations, but it adds a lot of code for a rather minor feature. I think there's an alternative solution that can be achieved with just a few changes, and is actually not harder to use.

A text field that is much bigger than its contents actually does not take up any more resources; it's just the hit area that is affected. So a user could at first give the text field the maximum size he allows it to have (that would be your 'autosizeMaxWidth/Height'):

SPTextField* tf = [[SPTextField alloc]] initWithWidth:200 height:1000 text:@"blah"];

Now Sparrow arranges the characters, and we know through the "textBounds" rectangle how big the actual text is. Then we could offer a simple method like this

[tf autoSize];

which would resize the textfield so that it just takes up the size of the contents.

What do you think? This would be achievable with just one simple new method, and -- if I'm not overlooking something -- be just as useful.

[tconkling]

I like the fire-and-forget nature of just setting an autoSize property on the TextField, and knowing that if I change the text (e.g. in a textual meter or counter) it'll continue to update its size as expected.

But I definitely hear you about the "lots of code" concern - the only thing I don't like about this proposed API is that it requires you to fiddle with the width and height every time you change the text.

What about encapsulating all three of those steps in a single method call:

[tf autoSizeWithMaxWidth:height:]

(with two convenience functions - autoSizeWithMaxWidth: and autoSize that just pass FLT_MAX for the missing params to autoSizeWithMaxWidth:height:)

If this works for you, I can have a patch that implements it later today.

[tconkling]

Also, are you opposed to allowing SPTextField to be subclassed? I'd like to make its properties protected instead of private, and move its internal method declarations into a separate SPTextField_Internal.h (or whatever) header. This would make it easier to implement, e.g., a StyledTextField class that allows mixing and matching of fonts, colors, etc in the same text field.

[PrimaryFeather]

That would be another possibility, not bad!

But I've got one more idea:

When you want to autosize a text field, for what reason do you do it? Is it because of the hit area it takes up on the screen? Because if it is, there's even a simpler way: adding a property that tells the TextField to let the actual textbounds rectangle act as the hit test rectangle (instead of the bounds of the textfield).

Then you'd have the "fire-and-forget" nature you want!

[tconkling]

The primary reason I autosize textfields is to assist with layout. If a TextField's bounds are unexpectedly huge, it throws off the bounds of every ancestor of that TextField, which is a problem if you're laying out complex displayObject hierarchies in relation to other displayObjects on the screen.

[PrimaryFeather]

Ah, I see! OK, that's of course a nasty problem, and my suggestion from above does not help there.

As for subclassing: I'm normally very careful about making class members protected, but the text field API has proved to be extremely stable in the past, so it should not be a problem here. So, by all means: please send me a pull request with the required changes!

Concerning the auto size feature: I'll think about it again and come back to you on that, ok? Sorry for my being overly-suspicious about that addition! ;-)

[tconkling]

If you merge Pull Request #1067 (which exposes SPTextField's internals), I think I can just add this functionality as a Category, without needing it in Sparrow.

[PrimaryFeather]

That would be great, Tim! I will add that feature in a while, but I need to play around with the code myself before doing that (and don't have enough time at the moment to do so). I hope you're fine with making it a category for now!

Thanks again!

[tconkling]

Sure, no problem. Thanks for merging the other pull request!

[PrimaryFeather]

You're welcome! Sorry for the delay ;-)