Re: [pygtk] widget containers for free placement

[Dave Aitel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

For what it's worth we do a similar sort of thing for these:
http://www.immunityinc.com/downloads/NodeView.png (You can click on
the nodes and they pop up a menu)
http://www.immunityinc.com/documentation/mappingbeta.html (flash movie
of a map with little icons)

Just as some ideas as to what's possible. I'm not sure how we do this
stuff under the covers, but it's all pure pyGTK.

- -dave


Greg Ewing wrote:
 If I understand correctly, firstly you're trying to create a kind
 of graphical GUI-building environment, but using your own unique
 kinds of widgets rather than the standard ones.

 It's hard to say what would be the best way to go about it. Basing
 each of your pseudo-widgets on an actual gtk widget would buy you
 some things -- a parent-child hierarchy, nested coordinate systems
 and clipping, and handling input events. But you may end up
 fighting against gtk in various ways, in order to handle things
 like dragging widgets from one container to another, which really
 needs to be managed by something outside the widget that was
 clicked on.

 Also, if you're going to want transparency or nonrectangular shaped
 widgets, you may find a real gtk widget to be too restrictive. And
 if you try to have thousands of widgets, I wouldn't be surprised if
 things get bogged down. A gtk widget is a fairly heavyweight thing,
 involving a Python object, a gtk object, and some state in the X
 server that all need to be coordinated.

 Donn wrote:
 Can one have living visual objects without making them
 widgets?

 At some level, yes, of course -- you can draw whatever you want and
 handle input events however you want.

 The question is whether the freedom you get from doing it all
 yourself is worth the extra effort it would take. I've never tried
 to do anything like this with gtk, so I'm not really sure how all
 the tradeoffs would work out.

 Either way, it sounds like a fairly major project, and one that
 will be bending gtk in ways it wasn't really designed to go. It
 might be better to get some experience using gtk in the normal way
 before diving into this.

 You might also want to look at PythonCard, which I haven't seen,
 but from what I've heard it may be doing something along similar
 lines. It's based on wxPython rather than gtk, but there might be
 some ideas in it that you could use.

 I realize it's counter to where GUI's go at the moment

 I don't want to discourage you -- a Flash-like environment sounds
 like it would be a cool thing to have -- but as a GUI for a mundane
 application, it's probably not a good idea to depart too far from
 the platform standards. If it's too weird and wonderful, it will
 tend to repel users rather than attract them!

 -- Greg ___ 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/

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHJemMB8JNm+PA+iURAmQcAJ9LazV9+/gt4G57MzQwbw3Sr+AgLwCgwPim
KdrL9TMzaO6iQdhye9c4gAw=
=8QjG
-END PGP SIGNATURE-

___
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/

Re: [pygtk] widget containers for free placement

[Greg Ewing]

Donn wrote:

#How to put them at x,y? And later, drag them?


Use the move() method of the Layout widget to position them.

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.

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?

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.

--
Greg
___
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/

Re: [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!)
 

Re: [pygtk] widget containers for free placement

[Greg Ewing]

Donn wrote:
I 
want to put custom widgets (drawn by cairo calls) onto a vast, endless, plane 
at arbitrary x,y positions.


You want a gtk.Layout. It lets you place widgets at explicit
positions in a 32-bit coordinate system and can be scrolled.

--
Greg
___
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/

Re: [pygtk] widget containers for free placement

[Donn]

 You want a gtk.Layout. It lets you place widgets at explicit
 positions in a 32-bit coordinate system and can be scrolled.

Thanks for the tip. I'm not getting closer. If you have a moment, could you 
look at this code?

\d

#!/usr/bin/env python

import gtk
import math

class Thing(gtk.DrawingArea):
def __init__(self):
super(Thing, self).__init__()
self.connect(expose_event, self.expose)
print Thing __init__ called

def expose(self, widget, event):
print Thing expose called
context = widget.window.cairo_create()
# set a clip region for the expose event
context.rectangle(event.area.x, event.area.y,
   event.area.width, event.area.height)
context.clip()
self.draw(context)
return False

def draw(self, context): pass
def rect(self):
return self.get_allocation()

class Box(Thing):
#override draw
def draw(self,context):
r = self.rect()
context.set_source_rgb(0.5, 0.5, 0.5)
context.rectangle(1, 1, 10, 10)
context.fill()

class RedBox(Thing):
def draw(self,context):
r = self.rect()
context.set_source_rgb(1, 0, 0)
context.rectangle(20, 20, 50, 50)
context.fill()

def main():
window = gtk.Window()
window.set_size_request(300, 300)
window.connect('delete-event', gtk.main_quit)

sw = gtk.Layout()
window.add(sw)

rb = RedBox()
b  = Box()
#How to put them at x,y? And later, drag them?

sw.add(b)
sw.add(rb)

rb.show()
b.show()
sw.show()

window.show_all()
gtk.main()

if __name__ == __main__:
main()
___
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/