[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/