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 _______________________________________________ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
