Re: [boost] thoughts on a GUI component library

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2004-12-15 04:33:27

John Torjo wrote:

>>The first thing that comes to mind when reading "data that is associated 
>>with the component" is data binding. I think it is a mistake to build
>
>What do you mean by this? Could you give an example?

I gave examples in my explanation. Let's say you have a textbox component. 
To bind it to generic data, you would need something like:

   template< typename Data > class gui::textbox;

This would allow:

   gui::textbox< std::string > name;
   gui::textbox< long > age;

But: How do you convert the string data into a long? I suppose you could 
have a conversion parameter, so you would do:

   gui::textbox< long, lexical_converter< long > > age;

However, because textbox is now a template, you get potential code bloat, 
especially if you are templating a more complex component such as a table 
(where in windows this is a "virtual" ListView control in report mode). I 
want to stear away from using templates as much as possible, using them 
where necessary, and keep the design as simple as it can be.

>>With this in mind, I have taken a drastic approach: do not provide native 
>>interoperability for size, position and area. I have designed them as:
>>
>>   struct position{ float x; float y; };
>>   struct size{ float dx; float dy; };
>>   struct area
>>   {
>>      float top; float left;
>>      float width; float height;
>>   };
>>
>>This means that the interface must convert these to the native 
>>representations and vise versa.
>
>I would say that this is the correct approach.
>
>As a side-node, I'm moderately against having float coordinates. Why would 
>you think int is not enough?

>From the various discussions, it is down to precision in caclculation. 
Usually, this would be when rounding floating values to integer boundaries. 
For example:

   x = 2.6 + 5.6 = 8.2

as an integer expression, is this:

   x = 2 + 5 = 7; // using floor(val)
   x = 3 + 6 = 9; // using ceil(val) or round(val)

In this case, the integer expressions are out by 1 depending on what 
rounding scheme is used. I took actual values to show the case above. If 
these were values in an algorithm that performed anti-aliasing for example, 
the anti-aliasing would not calculate the correct values.

Note that for integer-based coordinate systems, the values are converted to 
integers when needed, but otherwise are left as floating values to retain 
precision.

Regards,
Reece