Re: [boost] Re: Re: GUI Library Proposal for a Proposal

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2004-11-05 13:21:15

Andy Little wrote:
> "Reece Dunn" <msclrhd_at_[hidden]> wrote in message
>>There are also platform-independant versions of position (NSPoint, POINT,
>>etc.), size (NSSize, PointType, etc.) and area (NSRect, RECT, etc.) that
>
> FWIW I find the difference between Point and Size largely irrelevent
>
> In MFC:
>     CPoint (CSize );
>     CSize(CPoint );
>
> tending to make me think that they could be covered by one type eg xy_pair;

MFC gets the intended use of CPoint/CSize wrong.

In a mathematical sense, a point is a 0-size location in an nD
coordinate system. In this case, it is a 2D coordinate system, so is
(x,y). This is used for positioning, e.g. moving the graphics cursor, so
I call it gui::position. It does not make sense to perform point [+-*/]=
point since points are locations in a space (how do I add the location
of my house to the location of Jupiter)?

The size type stores width and height information, so it can be treated
as a 2D vector. In this case, standard arithmetic operations make sense.
Also, it is possible for sizes to interact with points, e.g. point += size.

If you do point - point, then the resulting type is a size type that
represents the distance between the two points.

So in a mathematical sense, the difference between size and position is
entirely relevant, it's just that some libraries (not mentioning names)
do not adhere to the above mathematical rules.

>>At the moment, you need to register Win32/64 window classes using:
>>   gui::win::window_type frame_class( TEXT( "CxxGUIFrame" ), COLOR_BTNFACE
>>);
>>but I am looking to abstract this.
>
> I reckon the X  or Fresco http://www.fresco.org ;-)  end should be
> tackled too ...

Noted. I was planning on getting support for WinXX, Cocoa (MacOS), X11,
GTK+ and Motif. I will need assistance to port to some of these APIs.

Regards,
Reece