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

From: Rene Rivera (grafik.list_at_[hidden])
Date: 2004-11-10 23:30:35

David Abrahams wrote:

> "George van den Driessche" <grebe_at_[hidden]> writes:
> 
>>Once you've made that split, then you can add:
>>(c) Expose the types to Lua using the objects created by (a).
>>(d) Expose the types to <language-of-your-choice> using the objects created
>>by (a).
>>(e) Serialise the types, using results of (a).
> 
> This I have serious doubts about.  What you'd expose for Python/Lua
> binding would be an object's public interface: its abstraction.  In
> order to do serialization in that way, you'd likely have to expose an
> object's guts: its implementation details.

I think the assumption George is going under is that the public 
interface provides enough information to reconstruct the objects. 
Although that is not required it is a common way to design classes that 
are going to be serialized. So if you accept that axiom it's possible to 
serialize from a reflection of a public interface.

>>(f) Bind types to GUI objects, using results of (a).
> 
> What does it mean to bind a type to a GUI object?

This is something I somewhat do in parts of the GUI code I have. 
Basically it's being able to tie a variable (class member, global, etc) 
to be displayed and manipulated "directly" by a GUI widget. For example 
attaching an enum to a combo-box, or a string to a text-box. Doing 
something that maps from the type to the widget automatically given the 
reflection info of the type is not an easy task as there's more to a 
variable than just the type which one ends up adding when creating the 
widget bindings, or at least I did.

-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq