Hi Lief,

IMO I the snap feature complements to collision
detection features of the motionx class.

For now I would suggest that you just include all the
features that you would like for snap detection inside
the motionx class. Once it's working as it should, we
can then look at whether it's best to separate the
snap features from the motionx class or not.

Keep up the good work.

--
Raymond Irving


--- Leif W <[EMAIL PROTECTED]> wrote:
> Started to think I bit off more than I could chew as
> my code modification
> attempts weren't working, so I stopped staring at it
> for a week or so.  Now
> getting back into it, I have made some progress
> where I can properly detect
> when a snap should occur and fire an event and so
> on.
> 
> Now, I am thinking of two types of borders, and two
> types of snapping, and
> wether I should include this into the API for ease
> of use (maybe not as
> flexible), or leave it to the programmers to
> continuously rewrite (maybe
> more flexible)?
> 
> To understand, I'll explain the functionality I am
> considering.
> 
> The concept of boundaries: inner boundary and outer
> boundary.  An outer
> boundary if you want to detect when a layer
> approaches another, then snap to
> the layer's real edge (this will have to co-exist
> with and may be combined
> with the collision functionality such that mutually
> exclusive layers can
> snap together, but not overlap, i.e. maybe they
> become grounped to a main
> layer a la winamp).  An inner boundary, if you have
> smaller layer inside a
> big layer and want to snap to the edge.  I.e. this
> might coexist with the
> setBoundary, to contain all the itty-bitty layers.
> 
> The concept of collisions (or exclusivity) versus
> overlapping of layers in
> combination with the snapping (sort of explained
> above).
> 
> There are already several combinations of collisions
> and snaps that I can
> conceive and it's a bit confusing.  Any feedback
> wether I should attempt to
> include all these conditions into the API (MotionX)
> for ease of use?  Any
> other ideas what to add, modify, or how to approach
> the problem?
> 
> Leif
> 
> 
> 
> 
>
-------------------------------------------------------
> This SF.net email is sponsored by: SlickEdit Inc.
> Develop an edge.
> The most comprehensive and flexible code editor you
> can use.
> Code faster. C/C++, C#, Java, HTML, XML, many more.
> FREE 30-Day Trial.
> www.slickedit.com/sourceforge
> _______________________________________________
> Dynapi-Dev mailing list
> [EMAIL PROTECTED]
>
http://www.mail-archive.com/[EMAIL PROTECTED]/


__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/


-------------------------------------------------------
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge
_______________________________________________
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://www.mail-archive.com/[EMAIL PROTECTED]/

Reply via email to