Brian wrote:
> > Like Brian, I too had thought that the interpretation was
> > the poly points were taken to be rel to whatever the obj's current
> > position.. but that's not so. The obj's pos is taken as the min of
> > the poly vertex coords, and thus you are correct that the present
> > poly positioning semantics is mostly borked.
>
> Yeah. My mistake there. The current code was a patch from a few
> months back, that was apparently only half-correct. I've reverted it.
I see.. Well, the original semantics is somewhat unsatisfactory
too, since moving a poly object would do nothing - very unintuitive.
If you want to have 'moving' with the current state of things, the
simplest way would probably be to add
(obj->cur.geometry.x,y - obj->prev.geometry.x,y) as offsets in the
render function, and to set
obj->prev.geometry.x,y = obj->cur.geometry.x,y at the end of the
'point_add' api function.
> > Now, this actually brings up a question: Just what should
> > the interpretation be of vertex coords (in lines, polys,..), and
> > of the 'geometry' of such path-defined objs?
> > One could take the semantics to be that the vertices are
> > defined rel to whatever the obj's pos is, and have the obj's set
> > geometry clip the poly's extent. This seems more desirable to me...
> >
>
> A quick rundown of the options
>
> I) Absolute canvas coordinates
> _point_add() takes a coordinate in canvas coords, and draws that
> point at that coordinate, completely ignoring the object's position
>
> II) Relative object coordinates
> _point_add() takes a coord relative to the object, so if the poly
> is moved to (10,10) the point (5,5) will be drawn at (15,15).
>
> III) Polygon coordinates
> _point add() takes points in an abstract space. This space is
> located such that the origin of the object corresponds to top left
> of the bounding box of the polygon's points.
>
>
> Is the current method (without the botched patch) seems to be (I)
> from a quick test, but i haven't looked at the code much. From what
> you say above, it sounds like its SUPPOSED to be doing (III).
>
> I'm impartial as to whether (II) or (III) is better. (II) is a bit
> more predictable, though.
>
> As for the size clipping the poly's extents, that makes some sense,
> but I think the default expected behavior would be for it to be
> large enough to show all of its points. So, maybe it would be better
> to ignore the size?
All these seem reasonable in one way or another.. and other
possibilities come to mind now as well.
For this to be useful one will need further api functions
specific to 'path-based' objs, and one needs to have some consistency
in the interpretation of how things like move/resize/rotate/....
of an object affect the resulting rendering -- without getting into
a complex mess of multiple coordinate systems and such.
Unless someone is eager and ready to have a go at this vfgx
stuff right now (which would be great), I'd say let's put this off
for a bit until we can come back to it when ready. :)
jose.
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
enlightenment-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
