[TIMOB-578] image view (stretchable image with left cap)
| GitHub Issue | n/a |
|---|---|
| Type | Bug |
| Priority | Medium |
| Status | Closed |
| Resolution | Fixed |
| Resolution Date | 2011-04-17T01:53:34.000+0000 |
| Affected Version/s | n/a |
| Fix Version/s | Release 1.4.0 |
| Components | iOS |
| Labels | n/a |
| Reporter | Nolan Wright |
| Assignee | Blain Hamon |
| Created | 2011-04-15T02:32:20.000+0000 |
| Updated | 2011-04-17T01:53:34.000+0000 |
Description
http://helpdesk.appcelerator.net/tickets/1474">http://helpdesk.appcelerator.net/tickets/1474
blain, let's discuss this one.
Attachments
| File | Date | Size |
|---|---|---|
| app.js | 2011-04-15T02:32:20.000+0000 | 905 |
| screen-shot-2010-04-16-at-25328-pm.png | 2011-04-15T02:32:20.000+0000 | 152887 |
| variable-behav.jpg | 2011-04-15T02:32:21.000+0000 | 45569 |
This could be related to this too:
https://appcelerator.lighthouseapp.com/projects/32238/tickets/563-imageview-scaling-issues"> https://appcelerator.lighthouseapp.com/projects/32238/tickets/563-i...
Possible solution is a boolean property on the imageView class, 'stretchImage'.
When true, we'll have the imageView loadStretchableImmediateImage instead.
That would be great. Can you also include properties for the leftCapWidth and topCapHeight so they can be customized (very useful in my case).
Currently image views do not use stretchable images so this does not affect them. Stretchable image views should be considered a new feature and a separate ticket should be made for them (and they should be easy to implement with the new infrastructure).
However as per the original ticket, backgrounds are now stretchable. The 'backgroundLeftCap' and 'backgroundTopCap' are TiDimensions, where 'auto' and '0' mean the same thing (the image stretches in the middle only). Otherwise, PLEASE be careful when using capping: Keep in mind that the left end cap == right end cap and similarly for top/bottom. This means that if the source image you're capping isn't symmetrical in terms of pixels, there may be issues such as where a stretched out pixel leads suddenly into a smooth bump at the very end of the image on the right cap. One example of this is the 'chat' image contained in KitchenSink. You can view this behavior by uncommenting the relevant lines in textfield_therest.js and playing around with the values a little.
(from [acbf58ff82857ec52dea89fb771d70d078f166fe]) Closes #578: Stretchable images (backgrounds) are now cappable. http://github.com/appcelerator/titanium_mobile/commit/acbf58ff82857ec52dea89fb771d70d078f166fe"> http://github.com/appcelerator/titanium_mobile/commit/acbf58ff82857...
Excellent, thanks guys!
Stephen, should this also work with labels? Have a demo working with a textfield, but not a label.
Unfortunately, it appears not. Backgrounds on labels and most other UI elements are set via a method which does not preserve capping. Currently only text fields and buttons allow capping; labels appear not to. One way you may wish to get around the label issue is to create an inactive text field if it's important for look & feel.
This is an important documentation issue, and should be noted. There is lots of infrastructure in place to allow capping, but (on a technical note) CGImages are pure bitmap content, not instructions on how that content is to be interpreted. Keeping all the code in place for now so that if an eventual solution is determined or an API change is made, we can take advantage of it.
Appreciate the explanation and insight. Thanks again for tackling this ticket, it's very helpful.
backgroundPadding* renders unexpectedly with 1.3. Has this functionality changed?
Some things may have changed in the last update to fix how padding presents itself, and avoid issues with resetting background bounds.
It's now a documented feature visible in the KitchenSink Controls -> Labels test, so you can see if things have changed for yourself. Please let me know if you have any more questions, or sample code you want me to look at.
I modified the LabelTest project I shared previously to mimic the KitchenSink demo. Where, the label is created first, then then the backgroundImage and padding are set. I launched the app 3 times in succession and got 3 different results (see image).
When I modified the label constructor to include the backgroundImage and padding, I repeatedly got result #3.
Reopening and prioritizing this, since it could be a serious issue.
(from [1fba03bb40a13c3ae4ac0d4346526d062f2d8a90]) Closes #578: padding fixed (again). Because padding breaks easily and doesn't respect 'auto', it will be removed when stretchable image views are implemented (since labels can just be embedded in views then). http://github.com/appcelerator/titanium_mobile/commit/1fba03bb40a13c3ae4ac0d4346526d062f2d8a90"> http://github.com/appcelerator/titanium_mobile/commit/1fba03bb40a13...