[PD-dev] tooltips ideas (was: Re: [PD-dev] displaying when an arg has been overridden)

IOhannes m zmoelnig zmoelnig at iem.at
Mon Jun 26 17:34:36 CEST 2006


geiger wrote:
> On Mon, 26 Jun 2006, IOhannes m zmoelnig wrote:
>> one problem with the tool tips patch is, that miller accepted my patch
>> for up/downsampling long ago (btw, i am very thankful for this): both
>> use the arguments to the [inlet~], but disagree on the meaning of these
>> arguments.
> 
> I think this is not the real problem, as up/downsampling could be
> specified through other means and backwards compatibility could be
> maintained easily.

seems like a bit blindfolded...
the simplest way would of course be to just ignore the fact (on the 
users side) that there is an additional word (e.g. "linear") in the 
comment. e.g [inlet~ linear center frequency] would do linear resampling 
and have a tooltip "linear center frequency" which in fact should read 
only "center frequency" but might be ok as a simple workaround (requires 
the user to be aware of the whole thing); even better if you do [inlet~ 
linear - center frequency]....

however, what exactly do you mean with "through other means"?
i have a strong feeling that this method ought to be given via the 
argument, as it changes the behaviour of the object, whereas the tooltip 
only changes the graphical appearance of the object.

personally i would prefer most, if tooltips would be available for 
_every_ object and they should be set via the preferences (right-click) 
menu.
this of course does not deal at all with the way how this information is 
stored within a pd-patch.
probably it would be a good idea to do it similar to the way arrays are 
stored inline.

e.g. something like

#X obj 100 100 inlet;
#G tooltip reset the game
#X obj 100 200 outlet;
#G tooltip finished!
#X connect 0 0 1 0
#G tooltip here flows the data
#G color red

#G (like "Gui") is attached to the preceding "#X" line.
i would prefer "#P" (Properties), but this is already taken by the good 
olde Patcher.

the patch given create an abstraction with 1 in- and 1 outlet: if the 
abstraction is closed, the tooltips "reset the game" (inlet) and 
"finished!" (outlet) would popup when you hover over the iolets.
when you open the abstraction, you get the tooltip; by hovering over the 
objects; the connection between the 2 objects is red and has also a 
tool-tip....

any pd interpreter could just omit lines starting with "#G", and still 
the functionality of the patch would be untouched.
an interpreter could also choose to ignore certain tags in the #G lines 
(e.g. no fanzy color support).

so i am thinking about an _optional_ non-functional data-field for each 
element of a pd-patch (not just iolets)



> The reason why he didn't accept the patch was that it changes the
> size of the pd base class, which breakes the external ABI and therefore
> externals compiled with older version of pd would stop working.

ok, this is obviously far more important than my little concerns.

reading miller's comment at the patch tracker suggest, that he also 
wants to keep things as tight as possible.

it would be good to hear miller's opinion (once everything has calmed 
down) of whether there is a chance to get a feature like the tooltips 
(or my more general idea of graphical properties) into vanilla pd and 
how it ought to be done "the right way"....

> 
> Amen
> 


mfg.asdr
IOhannes




More information about the Pd-dev mailing list