I think it would be useful. I always manipulate my rects from the center anyway so it would make sense if you could build a rect or surface from the center with [centerx, centery, height, width]. It could be something like
rect(x, y, height, width, relative_to=top_left) and you could input any of a rect attributes to the relative to argument. example( bottom_left, bottom_right, center, etc...) On 8/24/07, Phil Hassey <[EMAIL PROTECTED]> wrote: > > Hi, > > I would like this feature too. It'd be quite useful for gui dev... Here's > an example: > > - Say your screen is 640x480. > - Say you're drawing Dialog, but it's half dragged off screen (for some > reason), so it's Rect would be: Rect(600,400,400,300) - putting it mostly > outside of the screen. > - Doing screen.subsurface(r) will raise an error > > What would be convenient is if .subsurface() would do this: > > - It didn't raise an error > - It would return a subsurface > - get_width, get_height would return 400,300 > - The surface would have it's clip set to (0,0,400,300) > - If you wanted to, you could change the clip to (-40,40,480,380) and be > able to draw *outside* of your subsurfaces region with blits to (-40,40) > etc. > > Not sure if I explained all that quite right, but it would be a pretty > useful feature :) > > The implementation I just described would not be entirely backwards > compatible with pygame, as the clipping region would be used for something > special in this case. So you might have to call it something like subarea() > or some such method. > > (This can all be emulated in python, but having a proxy-surface makes > everything a bit slower, though I'm not sure how much ...) > > Phil > > *René Dudfield <[EMAIL PROTECTED]>* wrote: > > Hi, > > I'm not sure I understand how that would work? Could you please > explain it with code? > > I think it sounds useful though - just not sure I understand. > > > On 8/24/07, Greg Ewing wrote: > > Lenard Lindstrom wrote: > > > As for slicing, that is just a generalized form of Surface.subsurface > > > (with the parent locked for consistency with surfarray). > > > > Speaking of subsurfaces, there is one thing that I wish > > they had, and that's the ability for the origin of the > > subsurface's coordinate system to be somewhere other than > > its top left corner. > > > > This would have been useful in a small GUI library I wrote > > recently, where to draw a subwidget I get a subsurface from > > the parent widget's surface and pass it to the subwidget's > > draw() method. But this means that a subwidget can't hang > > outside the bounds of its parent widget, as that causes > > subsurface() to throw a wobbly. > > > > If surfaces had an "origin" attribute, subsurface() could > > simply clip the subsurface and set its origin appropriately. > > > > -- > > Greg Ewing, Computer Science Dept, > +--------------------------------------+ > > University of Canterbury, | Carpe post meridiem! | > > Christchurch, New Zealand | (I'm not a morning person.) | > > [EMAIL PROTECTED] +--------------------------------------+ > > > > > ------------------------------ > Pinpoint customers > <http://us.rd.yahoo.com/evt=48250/*http://searchmarketing.yahoo.com/arp/sponsoredsearch_v9.php?o=US2226&cmp=Yahoo&ctv=AprNI&s=Y&s2=EM&b=50>who > are looking for what you sell. > >
