[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[sc-dev] Not so EZ Consistency
It turns out the the old EZ's are rather quirky in the way the bounds
are determined.
They have "dimensions" argument instead of "bounds". I could simply say
dimensions.asRect, but actually other things are a bit strange:
EZSlider uses the dimensions and the calculates the sliderWidth =
dimensions.x-labelWidth-numberWidth.
thus the dimensions are wrong, because the gap is not considered.
EZNumber uses the dimensions.y only and labelWidth-numberWidth
thus the dimensions are irrelevant to the width. Again the gap is
not considered.
My two new EZs take a bounds argument (Point or Rect), and calculate the
menu or listView repectively in relative to the determined bounds, gap
and label sizes.
I can make EZSlider and EZNumber use the new scheme, keeping the
dimensions argument (asRect), but some layouts would still break
however, since the calculation used to be inacurate. EZ number would
have to adjust its bounds if the numberbox+gap+label exceed the bounds
(If I don't do it this way I would certainly break code).
I think a lot of people use EZ Slider, so I don't know if we should make
this change.
What is more important here, consistency, backward compatibility, or
geometrically correct code?
I think my two new EZ's should remain geometrically correct. Now the
question is if we update EZSlider and EZNumber (possibly EZRanger).
jostM
_______________________________________________
sc-dev mailing list
info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: https://listarc.bham.ac.uk/marchives/sc-dev/
search: https://listarc.bham.ac.uk/lists/sc-dev/search/