Re: [pygtk] deriving classes from gtk.py
On 22 Apr 2001, Bernhard Herzog wrote: > Well, the ExtensionClass docs contain the following example, which is > actually a bit different (i.e. I did not remember correctly) from the > situation above (taken from the ExtensionClass.stx that comes with Zope > 2.3.0: > > from ExtensionClass import Base > > class Spam: > > def __init__(self, name): > self.name=name > > class ECSpam(Base, Spam): > > def __init__(self, name, favorite_color): > Spam.__init__(self,name) > self.favorite_color=favorite_color > > and the docs go on to say: > > This implementation will fail when an 'ECSpam' object is > instantiated. The problem is that 'ECSpam.__init__' calls > 'Spam.__init__', and 'Spam.__init__' can only be called with a > Python instance (an object of type '"instance"') as the first > argument. The first argument passed to 'Spam.__init__' will be an > 'ECSpam' instance (an object of type 'ECSPam'). > > So at least mixin classes are a bit of a problem with ExtensionClasses > (there's a solution to the problem given in the docs, however). It may > well be that with Python 2.0 this is not an issue anymore. This won't affect pygtk. GtkWidgets won't work if you don't chain to their constructor anyway, so I don't think this will be a problem. This hasn't been an issue with any of the examples I have tested. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk
Re: [pygtk] queue_draw_area?
On Apr 21 KIU Shueng Chuan wrote: >On 20 Apr 2001, at 19:36, Tim Goetze wrote: > >> i set a background pixmap for the drawing_area's window and draw directly >> to this pixmap. after drawing, synthesize an expose event (or do the blit >> directly). > >hmm... this seems to be exactly what I was doing. > >> the X server will now update the window from the contents of the >> background pixmap in the fastest fashion whenever your window gets an >> expose event (don't know about how gtk on windows(r)(tm) handles this). >> >> after drawing to the pixmap, synthesize an expose event or do the blit >> yourself. > >What I wanted to do in my program was to animate the solving of a >maze, ie show the wiggling around and backtracking of the path >taken as it searches for the exit. > >For each iteration, I only draw onto the pixmap a mini rectangle, >the area of which is much much less than the area of the whole >pixmap itself. (I want to update the screen for each iteration for the >animation effect) > >In other words, if I only update a small piece of the pixmap, is there >any way to synthesize the expose event to tell it to only update the >drawingarea from that small piece? > >The way I do it currently is to update both the pixmap and the >drawingarea without synthesizing any expose event for each >iteration. This is much faster than blitting the whole pixmap for >each iteration. then from my understanding there is not much to optimize since you have to update both the window and the pixmap. synthesizing an expose event comes down to a lot of additional code being executed; ie the allocation/filling of the event structure, its routing within gtk and the decoding of the event. better skip all of this and stick with doing the blit yourself. afaik there's no way to automatically synthesize the expose event when you draw to a drawable in gtk/X anyway (except when you scroll a drawable with the copy_area family). though it may feel awkward, in fact this method you (and i too) use is probably the best you can get if you want flicker-free performance. regarding queue_draw_area, i think it doesn't really matter if you queue the redraw for later or do it right after the pixmap has been drawn to; drawing immediately has the advantage of reducing complexity in your program but that may be a matter of personal preference. if you insist on queuing the redraw without James' updated version, you might try using idle_add which is in gtk.py 0.6.5 and calls back as soon as gtk is idle; ie there are no other events to process. with queue_draw_area however, iirc the behaviour is that queued areas may be processed together as one bigger expose; but this doesn't seem to be what you want - the wiggling around in the maze wouldn't look so wiggly :) .tim ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk
Re: [pygtk] deriving classes from gtk.py
James Henstridge <[EMAIL PROTECTED]> writes: > On 11 Apr 2001, Bernhard Herzog wrote: > > However, IIRC, calling a baseclass' method in a method has to be done > > slightly different. E.g. > > > > class MyBox(GtkBaseClass): > > > > def __init__(self): > > GtkBaseClass.__init__(self) > > This works with ExtensionClass. ExtensionClass is designed to create > types that act as much like python classes as possible, so it would be a > bug if this didn't work. Well, the ExtensionClass docs contain the following example, which is actually a bit different (i.e. I did not remember correctly) from the situation above (taken from the ExtensionClass.stx that comes with Zope 2.3.0: from ExtensionClass import Base class Spam: def __init__(self, name): self.name=name class ECSpam(Base, Spam): def __init__(self, name, favorite_color): Spam.__init__(self,name) self.favorite_color=favorite_color and the docs go on to say: This implementation will fail when an 'ECSpam' object is instantiated. The problem is that 'ECSpam.__init__' calls 'Spam.__init__', and 'Spam.__init__' can only be called with a Python instance (an object of type '"instance"') as the first argument. The first argument passed to 'Spam.__init__' will be an 'ECSpam' instance (an object of type 'ECSPam'). So at least mixin classes are a bit of a problem with ExtensionClasses (there's a solution to the problem given in the docs, however). It may well be that with Python 2.0 this is not an issue anymore. Bernhard -- Intevation GmbH http://intevation.de/ Sketch http://sketch.sourceforge.net/ MapIt! http://mapit.de/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk
Re: [pygtk] Re: [pygtk] queue draw area?
> > In other words, if I only update a small piece of the pixmap, is there > > any way to synthesize the expose event to tell it to only update the > > drawingarea from that small piece? I have added the queue_draw_area() method to pygtk in CVS, so it should be in the next release (along with a gdkpixbuf module and some other misc bug fixes). James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk
[pygtk] Re: [pygtk] queue draw area?
> In other words, if I only update a small piece of the pixmap, is there > any way to synthesize the expose event to tell it to only update the > drawingarea from that small piece? Look at at the 'event' structure of the expose event. It contains the attribute 'area', which is a 4-tuple describing the rectangular area that has changed. An example (this code is not complete but only shows how to do it): def on_expose(widget, event, *args): # get the area area = event.area # redraw the area widget.draw_pixmap(gc, destination, area[1], area[2], area[0], area[1], area[2], area[3]) This is the way I handle this problem. Bye, Martin Grimme - http://www.pycage.de ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk
