Open GoogleCodeExporter opened 8 years ago
Heh, the clear method from UIForm was from the previous version, sorry, maybe I
swapped windows or something and thought it was the newer one.
Original comment by neverbi...@gmail.com
on 7 Aug 2012 at 3:52
I made a patch with several changes:
https://gist.github.com/3294732
- Added some of the changes commented above.
- Commented some lines in layout as looking at the code it seems the behaviour
is already applied several lines below (childAttributes.position(child,
_inGroup && !_row);).
- Fixed some issues with parseLabel. defaultTextFormat setter doesn't format
already set text, and checking @height for fixWidth doesn't seem right.
- I added an updateAfterEvent() call in page transitions... I use it for
smoother transitions, but because of performance you may want to remove it.
- Several changes to UIScrollVertical, first, why the addChildAt(0)? it causes
the content to stay behind behind other components, for example background
images. Also, changed width and height usage to widthH and heightV, it seems
right, as it is also used in the UI and in my case it improved its usage inside
other containers.
- Added x, y, right and bottom properties when placing controls inside a frame
container. This allows for anchoring, and placing controls in random positions
without relying to code. Just using the UI XML.
I don't know if my changes cause any regression, I made a few tests and didn't
see any. The app I'm working on saw several improvements thanks to these
changes, like code reduction and dynamic placement of some controls without
relying to more complex column or row layouts.
Original comment by neverbi...@gmail.com
on 8 Aug 2012 at 12:41
"it seems right, as it is also used in the UI and" meant "it seems right, as it
is also used in the constructor and"
Original comment by neverbi...@gmail.com
on 8 Aug 2012 at 12:43
Here is another patch to apply over the previous one:
https://gist.github.com/3344754
- Fixed some copy & paste errors.
- Looking at the code it seems attributes.height and attributes.width should be
used for the size of control containers, if it isn't so, it looks OK to me.
Seeing widthH and heightH are read-only maybe it would be more logical the
other way around tho. Changed UIList and UIGroupedList accordingly, made some
tests, and some cases where previous code resulted in wrongly sized lists now
look OK.
- Changed how Attributes.parse() works, I think it is a bit clearer and
consistent with the rest of the code this way, also, it fixes a problem with
gapH and gapV in my previous patch.
- There is a line in original MadComponents code that looks like a copy & paste
error:
_rendererAttributes.height=attributes.width - 2*attributes.paddingH;
I ran some regression tests, and didn't see any problem with my changes, but
who knows...
Original comment by neverbi...@gmail.com
on 13 Aug 2012 at 11:20
On the line that looks like a copy & paste error I changed:
+ _rendererAttributes.height=attributes.width - 2*attributes.paddingH;
To
+ _rendererAttributes.height=attributes.heightV - 2*attributes.paddingH;
It should be instead:
+ _rendererAttributes.height=attributes.heightV - 2*attributes.paddingV;
Original comment by neverbi...@gmail.com
on 13 Aug 2012 at 11:23
Original comment by doc.andr...@gmail.com
on 3 Sep 2012 at 2:50
When using the bottom and right properties alone a null reference error can be
got in parseBlock because it tries to access child and it hasn't be set yet...
quite obvious.
It depends of where you use these properties, since not always that parseBlock
part is accessed called.
Haven't decided how to fix it yet.
Original comment by neverbi...@gmail.com
on 9 Sep 2012 at 11:45
Just to mention: Haven't decided how to fix it, but it may be possible to
completely remove it. The layout function is always called at first after
parseBlock, isn't it?
Original comment by neverbi...@gmail.com
on 9 Sep 2012 at 12:12
Original issue reported on code.google.com by
neverbi...@gmail.com
on 7 Aug 2012 at 2:27