[pygtk] widget containers for free placement

[Donn]

Greg, thanks for the feedback. This is a little long, so I hope you get the 
time to read it. I'll understand if you back quickly away from it and saunter 
off whistling :)

I'm shooting for something seemingly impossible on Linux, and yet there are 
some tantalizing projects that approach it.

> Use the move() method of the Layout widget to position them.
Okay, will look into that. But the code as it stands still does not display 
the boxes (r and rb) at all.

> Dragging them is going to be tricky. Before trying to do
> that, I would be asking myself whether they really *need*
> to be widgets, or just something that you draw yourself
> in the main drawing area based on an internal data
> structure.
 I don't know. I am *aiming* at a "vector" interface very like Flash (or, less 
so, Director) produces - where "widgets" (movie clips) can contain and be 
contained (by) other "widgets". Individual "widgets" can be scripted, have 
events like clicks and enter/exit and emit events or signals to 
other "widgets"

Can one have "living" visual objects without making them "widgets"? My use of 
the word widgets is very probably incorrect.

 You see, I am still tainted by the Visual Basic way of thinking - I used to 
make ActiveX objects which had a visual interface, events and attached code. 
These could be dropped onto a "form" and thereafter be manipulated by code to 
move around, whatever. I am trying to make a tree-like class structure with 
flexible containing. (which I never got right in VB and then Flash came along 
and I jumped ship.)

 Another way to describe them would be "sprites" which can contain 
other "sprites" (etc. Each with a relative offset to each other).  
 Whichever "sprite" is a "top level" (root of a tree of children) can be moved 
(by dragging or by code) and all the children follow (like a group/clone of 
things in Inkscape). 
 They can be duplicated (instantiated). They can be removed, hidden/shown. 
They can contain internal "frames" such that the same "sprite" can "goto" and 
draw a totally different shape but still be the same object. For example, a 
list of fonts could be "collapsed" into a small icon that later (on click 
maybe) opens again into a list of fonts - all this happening internally 
within a "listOfFonts" object.
 Each "sprite" (movie clip/object) would have a layer such that they are all 
drawn from bottom up and thus overlap.

 That ListOfFonts can contain button objects, font objects, help objects, 
whatever -- all of them being inherited from "Sprite" with their own drawing 
code. Example, a button (when pressed) can open a pull-out (cartoon like 
balloon) which contains text controls (and whatever) in order to do it's 
business. It can be queries from its parent so that stuff happens according 
to what was set/done within it.

Really, each "sprite" is a free-floating concept not tied-down to being 
a "button" or a "text box". They are *whatever* goes into them.
 The most elemental things will be: rectangles, lines, circles, arcs, areas, 
text, images, masks. (A text-input class may be required as a basic 
element) -- all drawn by cairo.
 These things are all able to emit signals and be controlled by code. They go 
into a "sprite" and form a unit which can talk to other units.
 Within a unit, those basic elements can be changed over time so that they can 
animate - change: position, shape, scale, colour, alpha, appear, hide. One 
shape can entirely replace another at a certain "moment" (frame) in time.
 
> Are you going to be using any of the predefined widgets
> like buttons and text fields in this way, or will they
> all be custom things based on a DrawingArea?
I am aiming at en entirely custom interface - I want to create widgets that 
can be user-drawn by cairo. If I can adapt (skin) existing widgets that will 
enhance things nicely. 

> Also, how many are there likely to be? I would be wary
> of trying to make gtk handle a very large number of
> widgets -- it's likely to be very inefficient in a
> number of ways.
There are likely to be many of these "living" objects/sprites. The font lists 
would hold many thousands of faces (but I would only draw those that are 
visible within a clipped area). In the end, the number of objects would be 
under user-control, thus the slower it all responds, the fewer objects the 
user would implement. "User" here is end-user of the final app or a 
programmer using the classes that do all of this.

In the short-term, I would like to create objects that draw their own 
interface which will be embedded/contained manually (by a.add(b)) without all 
the tree-like containing. Just to see what is possible.

Another example - a "folder" object which when clicked will animate open (or 
just instantly draw) into a scrollable/dragable list that displays files 
which can in turn be clicked and dragged out of the widget to become new 
objects (like a ListOfFonts).

I'm entirely new to GTK. I was working in wxPython mostly. I am flexible and 
will follow the route that is best -- even if that means C++. (gulp!)
 The app is a font manager for Gnome because KDE is getting it's own; so using 
QT seems redundant. 
I could use Open GL but don't want to exclude those who have no 3d cards.

I realize it's counter to where GUI's go at the moment -- there likely will be 
no other "windows" opening, all will happen on one large 
(draggable) "canvas". (but not strictly.)

All this is a dream, I can shed it for an ordinary GUI -- which already exists 
in Fonty Python (in wxPython) at the moment -- I am really interested in 
breaking the mould and having a free-flowing interface.

It always struck me that the Flash concept of movie-clips and symbols that 
have internal time-lines and layers and scripting and events was a most 
brilliant and powerful one. It literally opens the door to *any* conceivable 
application. I am thinking along the lines of "wrapping" GTK in a such a way 
that a programmer can work with simple embeddable visual objects to achieve 
the same level of abstraction.

I don't know if GTK can do this -- but I have to ask.

For reference there is "Squeak" (smalltalk)- a very close (but no cigar) 
approximation. It's too heavy on requirements and very broken.

\d