hello list(s),
I have a problem: must create a small graph-on-parent abstraction. but I can't keep it small, because the object name and it's creation arguments enlarge the effective graph size.
so if I set 20x20px as GOP size, but the object instance is: [myobj $0 foo bar 0 0 0 1] the instantiated object is too wide.
is it possible to hide the object name (for GOP abstractions) or force it to not overflow dimensions set in canvas properties?
(i write CC to the developer list, because i think if this is not possible, would be nice at least discuss about it... my little C programming skills don't help me in looking at the code and submitting an appropriate patch, but i think it won't get too difficult to change this... just want to see if other people experienced similar problems)
bye
Hallo, Federico hat gesagt: // Federico wrote:
I have a problem: must create a small graph-on-parent abstraction. but I can't keep it small, because the object name and it's creation arguments enlarge the effective graph size.
so if I set 20x20px as GOP size, but the object instance is: [myobj $0 foo bar 0 0 0 1] the instantiated object is too wide.
As much as I grew fond of the fixed-width font used in Pd over the years, this issue has plagued me in the past as well. And in the present, too, because to my knowledge there is no trick to avoid it yet.
I agree very much that being able to hide all or the overflowing part of a GOP abstraction's name and arguments would be a very nice feature. (It would for example allow custom wrappers for [vslider] that still could be arranged neatly.)
But additionally I would also suggest to have something similar the other way around: If you have a GOP abstraction, where e.g. a [cnv] object overlaps with the abstraction's name, the name and args currently are invisible even when trying to edit the arguments. Because of this, all my GOP abstractions leave the upper ~15px free from any [cnv] objects.
So my suggestion would be to always show the abstractions name, if in Edit Mode and if the object is selected for editing. Hiding any overflowing letters could be made an option in the Canvas properties of the GOP abstraction then, so everyone is happy.
Frank Barknecht _ ______footils.org_ __goto10.org__
Federico schrieb:
hello list(s),
<snip> > > is it possible to hide the object name (for GOP abstractions) or force > it to not overflow dimensions set in canvas properties? > > (i write CC to the developer list, because i think if this is not > possible, would be nice at least discuss about it... my little C > programming skills don't help me in looking at the code and submitting > an appropriate patch, but i think it won't get too difficult to change > this... just want to see if other people experienced similar problems) I'd second this as an item on the wish list... I quite often use GOP abstractions that just expose a single 'bang' or 'toggle' that suffer from the mentioned behaviour.
Best Urs
Urs Liska wrote:
I'd second this as an item on the wish list... I quite often use GOP abstractions that just expose a single 'bang' or 'toggle' that suffer from the mentioned behaviour.
right; would be great if you could put it on the feature-request tracker at sourceforge.
mfga.sdr. IOhannes
Thanks for the hint. Just did it (for the first time ;-) Urs
IOhannes m zmoelnig schrieb:
Urs Liska wrote:
I'd second this as an item on the wish list... I quite often use GOP abstractions that just expose a single 'bang' or 'toggle' that suffer from the mentioned behaviour.
right; would be great if you could put it on the feature-request tracker at sourceforge.
mfga.sdr. IOhannes
This would be nice for me also, currently I just don't put in as many arguments as would break the gop size...
editing the (hidden) arguments is difficult though, maybe when they are "hidden" you can change them via a small "inspector"?
.b.
Federico wrote:
hello list(s),
I have a problem: must create a small graph-on-parent abstraction. but I can't keep it small, because the object name and it's creation arguments enlarge the effective graph size.
so if I set 20x20px as GOP size, but the object instance is: [myobj $0 foo bar 0 0 0 1] the instantiated object is too wide.
is it possible to hide the object name (for GOP abstractions) or force it to not overflow dimensions set in canvas properties?
(i write CC to the developer list, because i think if this is not possible, would be nice at least discuss about it... my little C programming skills don't help me in looking at the code and submitting an appropriate patch, but i think it won't get too difficult to change this... just want to see if other people experienced similar problems)
bye
Hallo, B. Bogart hat gesagt: // B. Bogart wrote:
This would be nice for me also, currently I just don't put in as many arguments as would break the gop size...
editing the (hidden) arguments is difficult though, maybe when they are "hidden" you can change them via a small "inspector"?
Last week IOhannes made a patch (as in diff) to toggle hiding of object names for GOP abstractions through the Properties dialog. It's in the Soruceforge patch tracker and works quite well in my short tests. To be able to see the object names and arguments again you need to reenable visibility for object names again.
Frank Barknecht _ ______footils.org_ __goto10.org__
Last week IOhannes made a patch (as in diff) to toggle hiding of object names for GOP abstractions through the Properties dialog. It's in the Soruceforge patch tracker and works quite well in my short tests. To be able to see the object names and arguments again you need to reenable visibility for object names again.
I don't know if I am repeating myself too much: would it be now also the
chance to make these controls available also through messaging? like
"pd-subpatch vis 1", but only "pd-subpatch gop 1 100 17 20 20 ...". I
guess it shouldn't be too complicated, and since you're working around it,
now seems to be the best time for it. If it's already possible for lots of
(if not all) GUI objects and menus, why not implement it as well?
by the way, speaking of abstractions and message control (ok, I was the
one that spoke about it), I just noticed something: given a subpatch
"subpatch", the message ";pd-subpatch vis 1" opens up the window, as
expected. When instead of the subpatch an abstraction "abstrct" is used,
either ";pd-abstrct vis 1" or ";abstrct vis 1" works. Is this a missing
feature, or did I failed to read something?
On Jul 10, 2006, at 12:45 AM, João Miguel Pais wrote:
I just noticed something: given a subpatch "subpatch", the message ";pd-subpatch vis 1" opens up the window, as expected. When instead of the subpatch an abstraction "abstrct" is used, either ";pd-abstrct vis 1" or ";abstrct vis 1" works.
";pd-abstrct vis 1" doesn't work here (pd-039.2)
try :
[; pd-abstrct.pd vis 1(