[PD-dev] info classes

[Jonathan Wilkes]

Just made a change so that the "args" method grabs from
the parent instead of the root canvas.  I initially didn't see a
use case for grabbing the args of a [pd] object, but someone
posted one awhile back.

Should I go ahead and also add a "selector" method to grab
the selector of the parent canvas?  This would make it possible
to grab the "pd" selector or the name of the abstraction
without the extension (e.g., ".pd").  This would be in addition to
a "filename" method that grabs the gl_name regardless of
whether you're in a [pd] or not.  I find that necessary because,
after all, we could be inside an abstraction within a max patch
and so the patch author can't just append ".pd" to the "selector".

-Jonathan



----- Original Message -----
> From: Jonathan Wilkes <jancsika at yahoo.com>
> To: "pd-dev at iem.at" <pd-dev at iem.at>
> Cc: 
> Sent: Thursday, November 15, 2012 2:34 AM
> Subject: [PD-dev] info classes
> 
> Here is a quick snapshot of a bundle of classes I'm working on to
> provide a standardized way to get properties from parts of pd
> that aren't "objectified":
> 
> [canvasinfo] get the properties of a canvas
> [pdinfo] get info about the running Pd instance
> [classinfo] info on a class (still under construction)
> 
> I currently have them below [print] in x_interface.c from 0.43, so you
> can just drop it in and compile with Pd Vanilla if you want to check it
> out.  (I'll make a patch later.)
> 
> 
> The props for [canvasinfo] are from my patch on the tracker that adds
> a "get" method to canvas.  The nice thing about this particular
> 
> interface is that there is only one class per domain which makes
> it much easier IMO to learn and remember the tools you need to
> inspect data (vs the one class per property approach which I find
> cumbersome).  For example, a bang to canvasinfo or pdinfo will print
> out a complete sequence of all properties and their values to the
> Pd window, so one doesn't even have to memorize the methods in
> order to see the values.  Incoming messages are done "pack" style,
> so that "symbol method" and "method" work the same, and with
> [canvasinfo] "A_SYMBOL A_FLOAT" messages get distributed among
> the inlets as lists do.
> 
> 
> I only have "dsp" and "version" properties for [pdinfo] so 
> far.  I'm curious
> what else would be useful.
> 
> [classinfo] just tells whether the incoming symbol is one that will create
> an object that is already loaded.  I'm not sure what an incoming bang
> would do here, or what more information would be useful.  Actually I
> think [declare -lib blah] fails silently, so you could use this as a way to
> "catch" missing objects and specify an alternative.
> 
> 
> I stole some code from IOhannes to get canvas args without digging
> into the innards of g_canvas.c. :)
> 
> 
> -Jonathan
> 
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev
>