Besides [list], what are other exceptions to the rule of the class
being all characters before the first space? It might just be easier
to code in an exception for [list].
.hc
On Jul 15, 2011, at 1:41 PM, Miller Puckette wrote:
THere isn't a 1-to-1 correspondence between the string that invokes an
object and its class -- hence, "list" can give rise to several
different
classes, but also, there are sometimes multiple classes in Pd that
have
the same "class name", like "select". The string was originally only
there to help in pringing out error messages, (i.e. human readable),
not
as a way to disamiguate anything.
I think the only way to know everything relevant is to know the whole
argument list and parse it, ouch...
cheers
Miller
On Fri, Jul 15, 2011 at 09:46:38AM -0700, Jonathan Wilkes wrote:
--- On Fri, 7/15/11, IOhannes m zmölnig <zmoel...@iem.at> wrote:
From: IOhannes m zmölnig <zmoel...@iem.at>
Subject: Re: [PD-dev] replace spaces in list class names with
hyphens
To: pd-dev@iem.at
Date: Friday, July 15, 2011, 10:18 AM
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 07/14/2011 11:55 PM, Jonathan Wilkes wrote:
I've got a working tooltip prototype going, and I just
noticed that all the list classes screw up things on the tcl
side, because with "list append" (for example) it suddenly
looks like there is one more arg to the proc.
Are there any other objects that have a space in the
creator name? If not, could we just make it official
that creator names can't have spaces, and change all the
"list foo" creators objects to "list-foo"?
This would be transparent to the user*, since they can
still type "list foo" and list_new will instantiate the
right class. (Although going forward I would suggest
using "list-foo" as it is the standard for all the listabs
abstractions.)
while i was always opposed to using object names with
spaces [1], i
don't think that we should forbid it at all. i would rather
have the GUI
side have an idea of what is the object name and what are
the arguments
(e.g. "create {list split} {1}" rather than "text list
split 1") than to
add arbitrary limitations.
some externals use "proxy objects" for full-fledged
non-first inlets,
and those proxies tend to have "hard to type" names as
well. how do your
tooltips deal with those?
So if object "foo" has a 2nd inlet controlled by a proxy object
"bar", which class is referred to by t_object *ob of glist_drawio
in g_text.c: foo or bar?
gfmasdr
IOhannes
[1]
https://sourceforge.net/tracker/index.php?func=detail&aid=1544083&group_id=55736&atid=478072
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk4f984ACgkQkX2Xpv6ydvTpDQCcDJRCiMa6Ai9IYvFNp84wJCJY
EyMAoIhuOhVq2Sra+Uhi8DOpZ8az1cLg
=XO7J
-----END PGP SIGNATURE-----
_______________________________________________
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
_______________________________________________
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
_______________________________________________
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
"[T]he greatest purveyor of violence in the world today [is] my own
government." - Martin Luther King, Jr.
_______________________________________________
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
