Dear Kuba,
> I've managed to get native scrollbars working with a horrible hack, but
> that's really just
> due to my lack of understanding.
> I need help with the following (additions/corrections):
> 1. areawin->width/height - that's the size of the viewport in GUI (X11,
> whatnot) units
> 2. [top]object->bbox.width/height - size of a bounding box enclosing all
> elements, in workspace units
> 3. areawin->pcorner - ??? (what does it point to, and in what units)
> 4. areawin->v/hscale - ratio of what to what?
> 5. [top]object->bbox.lowerleft - is "left" towards smaller x, and "lower"
> towards smaller y??
Yes, as often is the case, I opted for the mathemetician's/physicist's
use of coordinate space, with the Y axis origin at the bottom, instead of
the top. Naturally, there are places in the code where the two coordinate
systems have to be resolved relative to one another (if engineers had
just designed cathode ray tubes upside down, with scan lines going from
the bottom to the top, we wouldn't have this problem. . . I've heard plenty
of people complain about Ben Franklin mislabeling positive and negative
charge, but never heard anybody complain before that engineers designed
the CRT upside-down!).
The best reference for most of the variables named above are the two
functions window_to_user() and user_to_window() in functions.c, which
translate coordinates between the xcircuit coordinate system and X11.
For an X11 coordinate (x, y) to xcircuit coordinate (a, b):
a = x / vscale + pcorner.x
b = (height - y) / vscale + pcorner.y
(rounded to the nearest integer). So "vscale" is the scalefactor between
the xcircuit top-level and X11 coordinate systems, and pcorner is the
translation, in xcircuit (top-level) units. "vscale" is short for
"viewscale" (there is no 'hscale'). Each object maintains its own pcorner
and viewscale in the "object" structure, and these are copied over to the
"XCWindowData" (areawin) structure when that object becomes the topmost
object in the window (I suppose it would be more efficient to keep
referring to the object's viewscale and pcorner, rather than to copy it
into the window's structure and write it back to the object's structure,
which is undoubtedly some holdover from a very early version of xcircuit).
So if you stop editing an object and return to it later, it will preserve
the last position and scale used.
The object bounding box width and height are, yes, in workspace units, and
since the workspace units follow "normal" mathematical rules of coordinate
space, so the bounding box "lowerleft" is to the left (smaller x) and bottom
(smaller y).
The XCWindowData (areawin) structure holds information about the display
window itself, so yes, its width and height are in pixels.
It was a bad idea to use XPoint structures for XCircuit's internal units
as well as the window pixel units. This has led to some awkwardly
constructed structures for the arc and spline (curve) elements, where
the control points are type short (they must be on integer coordinates
in the workspace) but the actual curve is calculated as an array of
segments in type float. "Convert xcircuit units to floating-point"
has been on the to-do list for the longest time; it never rose to the
level of urgency that would make me sit down and do it.
---Tim
+--------------------------------+-------------------------------------+
| Dr. R. Timothy Edwards (Tim) | email: [email protected] |
| Open Circuit Design, Inc. | web: http://opencircuitdesign.com |
| 22815 Timber Creek Lane | phone: (301) 528-5030 |
| Clarksburg, MD 20871-4001 | cell: (240) 401-0616 |
+--------------------------------+-------------------------------------+
_______________________________________________
Xcircuit-dev mailing list
[email protected]
http://www.opencircuitdesign.com/mailman/listinfo/xcircuit-dev
