Hello list, I'd like to extend the syntax of the xlet metadata in the [pd META] subpatch.
Currently something like [clip] has this for the inlets:
INLET_0 float list INLET_1 float INLET_2 float
That gets picked up by the autotips which display the methods in the tooltip.
However, for objects that have multiple xlets like [clip], an xlet tip would be more helpful if it included a one or two word description of what the inlet is for. So when the user hovers over the middle inlet the tip can also say something like: Inlet 1 of clip (low value): float
and for the right inlet: Inlet 2 of clip (high value): float
I just need some clear syntax for separating the inlet description from the methods.
Idea #0: semicolon Example:
INLET_1 float; low value Nice because there is no chance of ambiguity, since the semi can't be part of a method name. Unfortunately it forces a newline.
The semicolon + description part would be optional so there's no need to change any of the current docs. Plus it's easy to parse.
Thoughts?
-Jonathan
On Mon, 2013-02-25 at 22:10 -0800, Jonathan Wilkes wrote:
Hello list, I'd like to extend the syntax of the xlet metadata in the [pd META] subpatch.
Currently something like [clip] has this for the inlets:
INLET_0 float list INLET_1 float INLET_2 float
That gets picked up by the autotips which display the methods in the tooltip.
However, for objects that have multiple xlets like [clip], an xlet tip would be more helpful if it included a one or two word description of what the inlet is for. So when the user hovers over the middle inlet the tip can also say something like: Inlet 1 of clip (low value): float
and for the right inlet: Inlet 2 of clip (high value): float
I just need some clear syntax for separating the inlet description from the methods.
Idea #0: semicolon Example:
INLET_1 float; low value Nice because there is no chance of ambiguity, since the semi can't be part of a method name. Unfortunately it forces a newline.
The semicolon + description part would be optional so there's no need to change any of the current docs. Plus it's easy to parse.
What I like about the META format is it is also easy to parse with Pd itself. Thus, I was concerned if your proposed addition would break that. I figured it does not. I don't see any other troubles, but see the benefit of having a separator. Please go ahead.
Roman
P.S.: While testing "Pd parsability", I created an object [sel ;] which immediately collapsed to [sel;] on instantiation. Although it looks weird, it's still functional. It seems something in Pd removes spaces around ';'. (Also try creating a [sel ; sel])
----- Original Message -----
From: Roman Haefeli reduzent@gmail.com To: pd-list@iem.at Cc: Sent: Tuesday, February 26, 2013 8:24 AM Subject: Re: [PD] pd META extension
On Mon, 2013-02-25 at 22:10 -0800, Jonathan Wilkes wrote:
Hello list, I'd like to extend the syntax of the xlet metadata in the [pd
META] subpatch.
Currently something like [clip] has this for the inlets:
INLET_0 float list INLET_1 float INLET_2 float
That gets picked up by the autotips which display the methods in the
tooltip.
However, for objects that have multiple xlets like [clip], an xlet tip
would be more
helpful if it included a one or two word description of what the inlet is
for. So
when the user hovers over the middle inlet the tip can also say something
like:
Inlet 1 of clip (low value): float
and for the right inlet: Inlet 2 of clip (high value): float
I just need some clear syntax for separating the inlet description from the
methods.
Idea #0: semicolon Example:
INLET_1 float; low value Nice because there is no chance of ambiguity, since the semi can't be
part of a method
name. Unfortunately it forces a newline.
The semicolon + description part would be optional so there's no need
to change any
of the current docs. Plus it's easy to parse.
What I like about the META format is it is also easy to parse with Pd itself. Thus, I was concerned if your proposed addition would break that. I figured it does not. I don't see any other troubles, but see the benefit of having a separator. Please go ahead.
Currently the parsing is extremely simple since it's just a capitalized word followed by atoms and a terminating semicolon (plus filtering out newlines but that's easy). The proposed extension still fits that, except that atoms mean something different depending on which side of a semicolon atom (i.e., a backslashed semicolon) they happen to be. Not to mention the fact that the spaces around the semicolon atom look different depending on whether you're looking at a patch or the patch source as you show below.
I could keep the trivial syntax by adding a new tag:
INLET_1_DESC low value INLET_2_DESC high value
The tag is a little long but it's much easier to parse. For people making abstractions where they want to control tooltip text this is what they want, so it will keep people from mixing methods with free text.
-Jonathan
Roman
P.S.: While testing "Pd parsability", I created an object [sel ;] which immediately collapsed to [sel;] on instantiation. Although it looks weird, it's still functional. It seems something in Pd removes spaces around ';'. (Also try creating a [sel ; sel])
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Jonathan Wilkes -
Roman Haefeli