[PD-dev] canvas get method

[Jonathan Wilkes]

Oh, and... I'm not sure if screenpos is totally accurate.  I haven't 
tested it in different window managers.

-Jonathan

--- On Tue, 5/24/11, Jonathan Wilkes <jancsika at yahoo.com> wrote:

> From: Jonathan Wilkes <jancsika at yahoo.com>
> Subject: canvas get method
> To: Pd-dev at iem.at
> Date: Tuesday, May 24, 2011, 6:30 PM
> Hi list,
>      Here's my first attempt at some c
> code to create a "get" method to 
> query the properties of a canvas.  I included the
> entire g_canvas.c from 
> 0.43 (haven't started using git and diff yet) and a demo
> patch with some 
> helper abstractions.  Some things that it does:
> 
> * [namecanvas] (and [sendcanvas]) are _actually_ obsolete
> * canvas environment variables available to the user
> (filename, dir, 
> canvas-local paths, dollarzero)
> * parent attributes (like dollarzero) are gettable without
> having to give 
> it as an argument to the abstraction
> * possible to find the toplevel canvas that contains "this"
> 
> abstraction (plus making all kinds of "canvas-abs" like the
> list-abs lib)
> * ability to get gop status, coords values, patch screen
> position, 
> abstraction's position on parent, and other goodies that
> are currently 
> scattered all around external libraries with various
> interfaces
> * abstraction can get a list of all attributes (like
> dollarzero) from 
> all the abstraction instances that exist.  (Probably
> should institute 
> patch 1403917 to make this rock-solid.)
> * parent args are gettable!
> 
> Things seem to work alright so far, but I'm not sure how to
> handle 
> reentrancy.  Also, I'm currently replying to queries
> using the attribute 
> as a selector.  The only model I had-- the [cnv]
> get_pos-- just sends the 
> data, but it seems cleaner to send to one receive-symbol
> and [route] 
> accordingly.  (I also much prefer one "get" method to
> separate ones to 
> access each attribute.)
> 
> -Jonathan