Re: Trapping Box Properties?

On Mon, 2004-04-12 at 01:09 -0700, Adam Megacz wrote:
> So, I've been thinking about this, and it's actually not as scary as
> it looks.  In fact, I think trapping width and height will replace
> SizeChange, and trapping numchildren will replace ChildChange.

I'm really unsure that you are thinking this through properly.

'width' and 'height' are synonyms for 'minwidth/maxwidth' and
'minheight/maxheight'.  They are not explicitly put to by the core.

To mandate trapping width and height is to create a confusing scenario
in that width/height would now be put to in 2 different contexts, 1 by
the core and another by the app, where the put behaves differently in
each context.

It might work fine, I'm not saying you're wrong.

I just don't like the way you're just doing things without consulting us
and giving an explanation behind any of your changes other than 'yes'
and 'symmetry'.  A lot of us put a lot of effort into Ibex/XWT and we
deserve an explanation behind changes.

And if you do go with dropping ChildChange, I implore you to go back to
childadded / childremoved rather than with numchildren ++=.  I mean,
think about the semantics of it.  numchildren ++= function(v) - what is
v?  You're saying it should be a box (I think).  In that case, it makes
no sense that a box is being 'put' to numchildren which is a numerical
value.  If v is numerical, then how do you get the box added or removed?
And whichever way, you still need to jump through a hoop everything time
you implement said trap to make sure you're working in the right context
(ie an add or a remove).
-- 
- Charlie

Charles Goodwin <[email protected]>
Online @ www.charlietech.com