[interfacekit] Re: BRegion
- From: burton666 <burton666@xxxxxxxxx>
- To: interfacekit <interfacekit@xxxxxxxxxxxxx>
- Date: Thu, 26 Jun 2003 08:21:09 +0200
---------- Initial Header -----------
> Yes. Add it to the build if it compiles properly and don't if it
> doesn't. We've had a problem in the past with people not checking in
> their work, getting hit by Real Life(tm) and their work never sees the
> light of day.
Yeah, I know. I read through the IK team ML archive and I found that someone
already wrote most of the support kit classes, but they weren't committed to
the CVS.
Currently BRegion compiles, and it even work, but just if it's linked to the
original libbe (some missing functions).
> > There are also some inline functions which work with clipping_rects,
> > that should be put in a private but "accessible" header (private/
> interface ?), since I guess they can be interesting even for our app
> server.
> Sure. private/interface would be an appropriate place for them. The
> server uses BRegions for most of the drawing stuff, but they might come
> in handy for when I need to implement stuff for Game Kit support.
I guess that Be's app server didn't use BRects, since they can have floats
coordinates. I guess it used clipping_rects internally (always IMHO, but I
think Marc will agree here). BTW this could be the reason for BRegion having
many C friend functions (be's app server didn't link against libbe, but I think
they used BRegion anyway, just as a struct and not as a class). Confused ?
Yeah, I am not so good when it comes to explain things... :P
Another thing: I peeked with diskprobe inside libbe, and I used the original
name for the inline functions (just the name though, since their implementation
is trivial, I wouldn't ever think about reverse engineering them) I hope this
isn't a problem for you.
Other related posts:
