[Pipet Devel] Re: [Pipet Devel] Re: window sill

[Brad Chapman]

[...snip... my description of parent and child widgets...]

Jeff wrote:
> It depends on the container.  I need to find one that will let me 
flip
> between
> overlapping children.  The fixed-position and notebook containers 
come to
> mind.

Damn, you are so smart! This is a really good idea that I never even 
thought of.

[...snip... description of my refresh problem...]

> Did you try a Gtk refresh or a canvas refresh?

I believe I tried calling both types--I think I tried request_redraw 
on the canvas and queue_draw on the Widget. I don't really understand 
how all of the refreshing works tho.

>> Is this what you are proposing will replace the GtkCTree view? Will 
be
>> have to code our own widget for this?
> 
> No, I was suggesting to you that the 'view we have now' (the 
workspace normal
> view) replace the GtkCTree view for taking listings of directories.  
The
> composite GUI will look like a regular Gtk interface.

    Okay...how can you then distinguish between moving a locus from 
one workspace to another via dnd, and copying a locus unto a new 
workspace via dnd (ie. if you are copying a saved locus onto to the 
workspace to use, or if you are dragging a directory out of a 
representation of a local filesystem)? Will the workspace need to keep 
track of what kind of information it is holding? Similary, a 
composite representing a save directory or local filesystem will need 
to react different to loci that are dragged into them then a "regular" 
workspace would. I guess we would probably need to define two 
different workspace types in the code.
    Also, how will a workspace be populated with gui representations 
of loci if you, for instance, open up a save container full of loci? 
Just stick them with equal spacing throughout the workspace, like 
opening a directory on a mac?

>> I did code this feature, and then killed it because it sucked :-< 
There is
>> a zoom command for the canvas which is supposed to provide 
"automatic"
>> zooming, but I couldn't make it work.
> 
> Really?  Is the code still in there?

No, sorry, I blasted it away because, as I mentioned, it was really 
ugly. All I did was add a zoom in and zoom out option to the menu and 
attach them to workspace functions that call set_pixels_per_unit(). I 
can remake it really easy if you want it. But it was *really* ugly :-)

Brad