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
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.
Ciao
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?
-
B. Bogart -
Federico -
Frank Barknecht -
João Miguel Pais