From: Lyle Johnson <lyle@...>
Date: 2002-08-08T22:46:29+09:00
Subject: Re: [OT] GUI's and the Rouge, Part IV

Tom Sawyer wrote:
> On Wed, 2002-08-07 at 20:25, Lyle Johnson wrote:
>> Could you maybe defer the construction of the actual FOX widget until it's
>> added to a parent (or however it is in GUtopIa that you associate child
>> widgets with parent containers)? I'm not familiar enough with the GUtopIa
>> architecture to know if this is doable or not.
> 
> i thought about this, breifly. i will consider it some more.
> 
> quick example on how children are assoc. to parents:
> 
>   abutton = GUtopIa::Button.new
> 
>   awindow = GUtopIa::Window.new
>   awindow.body = [ [ abutton ] ]
> 
> so as you can see from this, the button needs to have some sort of
> existence prior to being told were it will show up.

<snip>

To be sure you're clear about what I meant by deferring construction of 
the *FOX* widget:

Yes, the GUtopIa::Button instance needs to exist prior to being told 
where it will show up (i.e. who its parent will be). But am I correct in 
assuming that a GUtopIa::Button is a wrapper around an FXButton (or a 
GTK::Button, or whatever)? And if so, maybe you can delay instantiating 
the FXButton instance until late in the game. A lazy evaluation strategy 
of sorts.

> So i hesitate to adjust the way GUtopIa handles this, just for FOX's
> sake. the "foo" window may be a kludge, but it seems to work okay --i
> don't see any problems with doing this, but perhaps there are?

I'm not sure that you would need to adjust the way that GUtopIa handles 
things (at least from the public API standpoint that you've described). 
I mean, it's going to be true for any GUI toolkit that you choose that 
until a child widget is associated with a parent window you're not going 
to be able to realize that child widget. GTK isn't going to let you 
create a standalone GTK::Button widget and show it onscreen before you 
pack it into some parent container. But it is true that (at least for 
the FOX-based implementation) you'd need to structure things so that 
this deferred creation strategy works properly.

OTOH, if a "fake" parent window kludge is already working for you, I 
can't think of any problem with that.

> 
> ~transami
> 
>