[boost] Re: thoughts on a GUI component library

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2004-12-21 06:10:47

Dave Harris wrote:
> In-Reply-To: <cpsv4p$foa$1_at_[hidden]>
> michaeltoksvig_at_[hidden] (michael toksvig) wrote (abridged):
> 
>>you might consider adding operator[] to point and size
>>
>>also, consider defining area in terms of 2 points, and adding 
>>operator[] to that, too
> 
> I was about to say the same thing :-) I'd go further, and expose the 
> array.
> 
>     class box {
>         point data_[2];
 > [snip]
>    };

I think that this is the wrong representation.

> This is because you will almost certainly want transforms that act on 
> arrays of points, and it will sometimes be convenient if they can act on 
> rectangles too.

Translation: a.pos += gui::size( 5, 7 );
Scaling: a.size += gui::size( 10, 20 );
Rotation: n/a since you are assuming that each side has an angle of 90 
degrees (allowing for two point representations).

> I would provide get/set methods which are independent of representation. 
> I'd consider allowing things like ++box.top() too. Currently I think the 
> convenience is not worth the loss of purity. ++box[0][1] should work, 
> though.

If you have point high, low; then which corner is "high"? Likewise, 
using top_left, bottom_right is bad. In general, storing a rectangle as 
a set of two points is the wrong representation, especially for portability.

Windows defines (0, 0) to be the top left corner, while Mac/Cocoa define 
it to be the bottom left corner. Therefore, in order to extract the two 
points in any of the above point set representations, you need platform 
dependant information about the coordinate orientation. This complicates 
matters similar to my initial attempt (using properties) by having to 
rely on platform dependant mapping every time you are referencing the 
rectangle data.

Having a (point, size) notation, similar to the Cocoa representation, 
you remove the need for platform dependancy (except when mapping between 
the native type and the independant type). Also, this representation 
simplifies translation and scaling (see above). You do not need to worry 
about the direction of the size type since this is resolved for you by 
the operating system. Granted, gui::rect( 10, 15, 100, 150 ) will be 
orientated differently on Windows and Mac, but for the operating system 
user, they will be orientated correctly.

> On naming... I think "area" is the wrong name.

I have revised the names for area (now rect with a typedef for rectangle 
if you prefer to use the longer name) and position (now point).

> I see no benefit in using "position" instead of the usual "point". "Point" 
> is shorter.

I was aiming at adding information to the name, for example
    move( point pt ); // move to the new point
    move( position pos ); // change the position

I have conceeded the point (pun intended!) and changed the name. It may 
be a good idea to typedef point as position, like I do with rect.

> It's hard to improve on "size" :-)

:)

> I would seriously consider replacing float with a typedef, perhaps with 
> another typedef for distances and offsets. Even without type checking, I 
> think using more exact type names helps to clarify thought.

I am now using a UDT called metric (re: mathematics) to represent the 
values. See the other messages in the thread for discussions on this.

> [Later...]
> 
> I've looked at the code in the zip file now. I see it doesn't match the 
> email. It uses a different representation and adds several member 
> functions, although not as many as me. I am surprised to see things like 
> size*size and size/size. 

On review, I have removed size/size, size*size. As for the 
representation change: this is an evolving library, but the essence 
remains the same, so discussion here is still valid. I do not intend on 
posting the full member function list as these e-mails are long enough 
already! If you are interested, take a look at the code (as you have 
done). I appreciate the feedback.

Regards,
Reece