I'm reformulating my question as the problem is evolving: do we have an object that
- Displays and holds a text value (like Symbol or Message box),
- is Graph-on-Parent,
- can be resized (like Number2)? (or small enough by default?)
Something like a Number2 for symbols...? Or a settable comment...?
Thanks,
András
On Sun, Jun 23, 2013 at 9:22 PM, András Murányi muranyia@gmail.com wrote:
Hi List,
I'm trying to switch from oldstyle dropdown combo box (toxy/widget popup) to tof/plist which is a nice dropdown menu except it has no placeholder, but the menu appears wherever when sent a bang. My question is: do we have an object that
- Displays and holds a text value (like Symbol or Message box),
- is Graph-on-Parent,
- emits a bang when clicked?
It doesn't have to be Vanilla.
Thanks,
András
On Mon, 2013-07-01 at 20:56 +0200, András Murányi wrote:
I'm reformulating my question as the problem is evolving: do we have an object that
- Displays and holds a text value (like Symbol or Message box),
- symbolbox with width set 0 resizes dynamically
- hsl, vsl, cnv, etc. can adjust size with 'size' message, can change
displayed text with 'label' message
- is Graph-on-Parent,
applies to all above solutions.
- can be resized (like Number2)? (or small enough by default?)
see above.
To make something send a bang, you could put some [bng] objects behind your whatever text displaying objects. Interestingly, hidden GUI objects have priority over visible objects when clicked. Another way is to use a construct like the following to make a slider send bangs only when clicked, but not when dragged:
[hsl]
|
[t a a]
/
/
[sel 0]
Roman
On Mon, Jul 1, 2013 at 10:05 PM, Roman Haefeli reduzent@gmail.com wrote:
On Mon, 2013-07-01 at 20:56 +0200, András Murányi wrote:
I'm reformulating my question as the problem is evolving: do we have an object that
- Displays and holds a text value (like Symbol or Message box),
- symbolbox with width set 0 resizes dynamically
- hsl, vsl, cnv, etc. can adjust size with 'size' message, can change
displayed text with 'label' message
Very good idea, thanks Roman! Some difficulties I'm having:
- I don't know how to set the label of [cnv]... is it possible at all?
- (ATTN: Ivica) [hsl] seems to have the bounding box (?) miscalculated in
l2ork so it doesn't GOP when it's less than 2-3px from the border of the parent canvas. Checked in Vanilla, it works as expected ([hsl] can be placed to the very border and it will GOP).
- is Graph-on-Parent,
applies to all above solutions.
- can be resized (like Number2)? (or small enough by default?)
see above.
To make something send a bang, you could put some [bng] objects behind your whatever text displaying objects. Interestingly, hidden GUI objects have priority over visible objects when clicked. Another way is to use a construct like the following to make a slider send bangs only when clicked, but not when dragged:
[hsl] | [t a a] / /
[sel 0]
Interesting indeed. Actually, I don't need the label to send a bang any more, because [pmenu] won't pop up when the click happens inside a subpatch, so I need to put the triggering object in the toplevel. (I might still hide it under the GOP abstraction...) BTW, is it theoretically possible for a GOP object to display a menu on the toplevel (stretching over the GOP area of the subpatch where it is)? If yes, I'd eventually try to hack the pmenu code.
András
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-07-02 12:54, András Murányi wrote:
- I don't know how to set the label of [cnv]... is it possible at
all?
yes, it's easy. since [cnv] doesn't have an inlet, you have to use the receive-label.
just check the help-patch for [cnv] - there's a [pd edit] that explains all this stuff.
fgamsdr IOhannes
On Tue, Jul 2, 2013 at 2:06 PM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-07-02 12:54, András Murányi wrote:
- I don't know how to set the label of [cnv]... is it possible at
all?
yes, it's easy. since [cnv] doesn't have an inlet, you have to use the receive-label.
just check the help-patch for [cnv] - there's a [pd edit] that explains all this stuff.
fgamsdr IOhannes
Oh, yes. I'm sorry I didn't take a better look. (Maybe I didn't see the recieve symbol in properties because I was not clicking on the cnv's selectable area but on the underlying canvas'...)
András
On Die, 2013-07-02 at 12:54 +0200, András Murányi wrote:
On Mon, Jul 1, 2013 at 10:05 PM, Roman Haefeli reduzent@gmail.com wrote: On Mon, 2013-07-01 at 20:56 +0200, András Murányi wrote: > I'm reformulating my question as the problem is evolving: > do we have an object that > - Displays and holds a text value (like Symbol or Message box),
* symbolbox with width set 0 resizes dynamically * hsl, vsl, cnv, etc. can adjust size with 'size' message, can change displayed text with 'label' messageVery good idea, thanks Roman!
Some difficulties I'm having:
- I don't know how to set the label of [cnv]... is it possible at all?
[symbol
|
[label $1(
|
[cnv]
- (ATTN: Ivica) [hsl] seems to have the bounding box (?) miscalculated
in l2ork so it doesn't GOP when it's less than 2-3px from the border of the parent canvas. Checked in Vanilla, it works as expected ([hsl] can be placed to the very border and it will GOP).
According to Ivica this is on purpose. The reason is that iemguis used to have miscalculated positions and pd-l2ork fixed that while pd-vanilla/pd-extended didn't. Unfortunately, this breaks compatibility between pd-l2ork and pd-vanilla/pd-extended.
Roman
On Tue, Jul 2, 2013 at 2:27 PM, Roman Haefeli reduzent@gmail.com wrote:
On Die, 2013-07-02 at 12:54 +0200, András Murányi wrote:
On Mon, Jul 1, 2013 at 10:05 PM, Roman Haefeli reduzent@gmail.com wrote: On Mon, 2013-07-01 at 20:56 +0200, András Murányi wrote: > I'm reformulating my question as the problem is evolving: > do we have an object that > - Displays and holds a text value (like Symbol or Message box),
* symbolbox with width set 0 resizes dynamically * hsl, vsl, cnv, etc. can adjust size with 'size' message, can change displayed text with 'label' messageVery good idea, thanks Roman!
Some difficulties I'm having:
- I don't know how to set the label of [cnv]... is it possible at all?
[symbol
| [label $1( | [cnv]
my [cnv] has no inlets so IOhannes's solution applies.
- (ATTN: Ivica) [hsl] seems to have the bounding box (?) miscalculated
in l2ork so it doesn't GOP when it's less than 2-3px from the border of the parent canvas. Checked in Vanilla, it works as expected ([hsl] can be placed to the very border and it will GOP).
According to Ivica this is on purpose. The reason is that iemguis used to have miscalculated positions and pd-l2ork fixed that while pd-vanilla/pd-extended didn't. Unfortunately, this breaks compatibility between pd-l2ork and pd-vanilla/pd-extended.
Roman
I'm seeing a tiny bit more complication here (in l2ork):
- when trying to place [hsl] close to the GOP area edges, it disappears
from GOP (as said before)
- when trying to place [cnv] close to the GOP area edges (in a fairly large
GOP area) everything is fine, however:
- when trying to fit a 10px high [cnv] into a 12px high GOP area, the [cnv]
refuses to show up in GOP.
András
On 07/02/2013 02:41 PM, András Murányi wrote:
On Tue, Jul 2, 2013 at 2:27 PM, Roman Haefeli <reduzent@gmail.com mailto:reduzent@gmail.com> wrote:
On Die, 2013-07-02 at 12:54 +0200, András Murányi wrote: > On Mon, Jul 1, 2013 at 10:05 PM, Roman Haefeli <reduzent@gmail.com <mailto:reduzent@gmail.com>> > wrote: > On Mon, 2013-07-01 at 20:56 +0200, András Murányi wrote: > > I'm reformulating my question as the problem is evolving: > > do we have an object that > > - Displays and holds a text value (like Symbol or Message > box), > > > * symbolbox with width set 0 resizes dynamically > * hsl, vsl, cnv, etc. can adjust size with 'size' message, can > change > displayed text with 'label' message > > > Very good idea, thanks Roman! > > Some difficulties I'm having: > > - I don't know how to set the label of [cnv]... is it possible at all? [symbol\ | [label $1( | [cnv]my [cnv] has no inlets so IOhannes's solution applies.
The [cnv] object has no inlet.
-Jonathan
On Die, 2013-07-02 at 17:58 -0400, Jonathan Wilkes wrote:
On 07/02/2013 02:41 PM, András Murányi wrote:
On Tue, Jul 2, 2013 at 2:27 PM, Roman Haefeli reduzent@gmail.com wrote: On Die, 2013-07-02 at 12:54 +0200, András Murányi wrote: > On Mon, Jul 1, 2013 at 10:05 PM, Roman Haefeli reduzent@gmail.com > wrote: > On Mon, 2013-07-01 at 20:56 +0200, András Murányi wrote: > > I'm reformulating my question as the problem is evolving: > > do we have an object that > > - Displays and holds a text value (like Symbol or Message > box), > > > * symbolbox with width set 0 resizes dynamically > * hsl, vsl, cnv, etc. can adjust size with 'size' message, can > change > displayed text with 'label' message > > > Very good idea, thanks Roman! > > Some difficulties I'm having: > > - I don't know how to set the label of [cnv]... is it possible at all?
[symbol\ | [label $1( | [cnv]my [cnv] has no inlets so IOhannes's solution applies.
The [cnv] object has no inlet.
Yeah, my mistake. Didn't check when writing the mail.
Roman
[symbol
| [label $1( | [cnv]
- (ATTN: Ivica) [hsl] seems to have the bounding box (?) miscalculated
in l2ork so it doesn't GOP when it's less than 2-3px from the border of the parent canvas. Checked in Vanilla, it works as expected ([hsl] can be placed to the very border and it will GOP).
According to Ivica this is on purpose. The reason is that iemguis used to have miscalculated positions and pd-l2ork fixed that while pd-vanilla/pd-extended didn't. Unfortunately, this breaks compatibility between pd-l2ork and pd-vanilla/pd-extended.
Roman
This is true. Although, I wouldn't call translating an object by 3 pixels exactly breaking compatibility. I do agree it is a nuisance nonetheless, yet I feel it is a necessary part of pd(-l2ork) growing and becoming more consistent. The reason why I did what I did in pd-l2ork is best portrayed if you use autopatching option which positions everything in line vertically. If you autopatch objects like atom, then hsl, then another atom (or symbol or simply an object), you'll see how things align (or don't).
Now, if an object does not render properly in pd-l2ork because of this translation, then what is needed is simply nudging it in the opposite direction. However, if the object appears within the GOP boundaries but is still not visible in GOP window, then there may be some stale things I missed in the getrect call for hsl. In this case, please do file a bug report.
Best wishes,
Ico
On Die, 2013-07-02 at 19:15 -0400, Ivica Ico Bukvic wrote:
[symbol
| [label $1( | [cnv]
- (ATTN: Ivica) [hsl] seems to have the bounding box (?) miscalculated
in l2ork so it doesn't GOP when it's less than 2-3px from the border of the parent canvas. Checked in Vanilla, it works as expected ([hsl] can be placed to the very border and it will GOP).
According to Ivica this is on purpose. The reason is that iemguis used to have miscalculated positions and pd-l2ork fixed that while pd-vanilla/pd-extended didn't. Unfortunately, this breaks compatibility between pd-l2ork and pd-vanilla/pd-extended.
This is true. Although, I wouldn't call translating an object by 3 pixels exactly breaking compatibility.
If a patch just isn't usable at all on a different flavor, then I don't see how this doesn't qualify for breaking compatibility.
Roman
On Jul 3, 2013 1:38 AM, "Roman Haefeli" reduzent@gmail.com wrote:
On Die, 2013-07-02 at 19:15 -0400, Ivica Ico Bukvic wrote:
[symbol
| [label $1( | [cnv]
- (ATTN: Ivica) [hsl] seems to have the bounding box (?)
miscalculated
in l2ork so it doesn't GOP when it's less than 2-3px from the border of the parent canvas. Checked in Vanilla, it works as expected
([hsl]
can be placed to the very border and it will GOP).
According to Ivica this is on purpose. The reason is that iemguis used to have miscalculated positions and pd-l2ork fixed that while pd-vanilla/pd-extended didn't. Unfortunately, this breaks
compatibility
between pd-l2ork and pd-vanilla/pd-extended.
This is true. Although, I wouldn't call translating an object by 3 pixels exactly breaking compatibility.
If a patch just isn't usable at all on a different flavor, then I don't see how this doesn't qualify for breaking compatibility.
Roman
I guess we need to clarify what "not usable at all" means. If a patch works but one optional gop hsl is not visible, personally I would say that one element may not be usable and only temporarily. If you are looking for things that really break compatibility, then those would be things like preset_node object that are current only possible in pd-l2ork.
HTH
On Wed, 2013-07-03 at 03:56 -0400, Ivica Bukvic wrote:
On Jul 3, 2013 1:38 AM, "Roman Haefeli" reduzent@gmail.com wrote:
On Die, 2013-07-02 at 19:15 -0400, Ivica Ico Bukvic wrote:
[symbol
| [label $1( | [cnv]
- (ATTN: Ivica) [hsl] seems to have the bounding box (?)
miscalculated
in l2ork so it doesn't GOP when it's less than 2-3px from the
border
of the parent canvas. Checked in Vanilla, it works as expected
([hsl]
can be placed to the very border and it will GOP).
According to Ivica this is on purpose. The reason is that
iemguis used
to have miscalculated positions and pd-l2ork fixed that while pd-vanilla/pd-extended didn't. Unfortunately, this breaks
compatibility
between pd-l2ork and pd-vanilla/pd-extended.
This is true. Although, I wouldn't call translating an object by 3 pixels exactly breaking compatibility.
If a patch just isn't usable at all on a different flavor, then I
don't
see how this doesn't qualify for breaking compatibility.
Roman
I guess we need to clarify what "not usable at all" means. If a patch works but one optional gop hsl is not visible, personally I would say that one element may not be usable and only temporarily.
Many of my patches are not usable at all without GOP GUIs visible. And I cannot fix it myself as either it breaks pd-vanilla|pd-extended or pd-l2ork or it looks dead ugly. So yes, it breaks compatibility in a serious way. And I also do not see the temporary aspect of it. I as a patch developer can't provide a solution to this.
This is _the_ reason I don't even try to bother to make my patches work in pd-l2ork. And I even need to tell people that they shouldn't use pd-l2ork when they want to use my patches.
If you are looking for things that really break compatibility, then those would be things like preset_node object that are current only possible in pd-l2ork.
Actually, one can decide to use or not to use new features. Obviously, added features do not work in flavors that do not implement that feature. From a user point of view, this can be dealt with in an clean way. If you want your patch to work on other flavors, don't use stuff like preset_node. I don't see a problem at all with that.
Roman
On 07/03/2013 04:31 AM, Roman Haefeli wrote:
On Wed, 2013-07-03 at 03:56 -0400, Ivica Bukvic wrote:
I guess we need to clarify what "not usable at all" means. If a patch works but one optional gop hsl is not visible, personally I would say that one element may not be usable and only temporarily.
Many of my patches are not usable at all without GOP GUIs visible. And I cannot fix it myself as either it breaks pd-vanilla|pd-extended or pd-l2ork or it looks dead ugly. So yes, it breaks compatibility in a serious way. And I also do not see the temporary aspect of it. I as a patch developer can't provide a solution to this.
This is _the_ reason I don't even try to bother to make my patches work in pd-l2ork. And I even need to tell people that they shouldn't use pd-l2ork when they want to use my patches.
The solution is the one you stated above--stick to one particular flavor of pd and run with it. I for one believe the sooner I switch my patches to a more consistent drawing mechanism the less I will have to deal with down the road. pd has two choices:
- keep the same inconsistent behaviour for as long as it exists causing
problems in other places for the patch developers such as yourself (e.g. autopatching), in the end causing the same amount of work (whether you fix whatever is currently misaligned or do that while patching because your autopatch feature did not align your objects properly is as far as I can tell the same amount of work, of course, assuming that you do use autopatch--I do, so this is very important to me)
- fix this at some later date at which point you will have a larger
library of patches you've built between now and that later date that will require fixing because they relied on the current inconsistent way
Consider also how pd does not properly account for labels on iemguis or comments and does not mind having them stick outside GOP. Or how dynamically changed iemgui objects inside GOP do not get their visibility rechecked to see if they still fit within GOP and then spill outside it only to disappear when you copy and paste the said GOP. These are all fixed within pd-l2ork. I believe these are very pressing issues for me as L2Ork's entire GUI scoring system is built around iemguis and scalars and I want to make sure that others developing similar scores (or expanding upon the existing) for the ensemble do not encounter such inconsistencies that can be abused for temporary solutions that later break because such bugs have been fixed, rendering their scoring engine unusable.
tl;dr version: I find issues of GUI inconsistency critical and prefer to fix them sooner rather than later and do not want to worry about legacy behaviour that is incorrect to begin with, because the longer one waits, the more they'll have to fix later when the similar/identical fix is implemented in their flavor of pd.
On Wed, 2013-07-03 at 05:53 -0400, Ivica Ico Bukvic wrote:
On 07/03/2013 04:31 AM, Roman Haefeli wrote:
On Wed, 2013-07-03 at 03:56 -0400, Ivica Bukvic wrote:
I guess we need to clarify what "not usable at all" means. If a patch works but one optional gop hsl is not visible, personally I would say that one element may not be usable and only temporarily.
Many of my patches are not usable at all without GOP GUIs visible. And I cannot fix it myself as either it breaks pd-vanilla|pd-extended or pd-l2ork or it looks dead ugly. So yes, it breaks compatibility in a serious way. And I also do not see the temporary aspect of it. I as a patch developer can't provide a solution to this.
This is _the_ reason I don't even try to bother to make my patches work in pd-l2ork. And I even need to tell people that they shouldn't use pd-l2ork when they want to use my patches.
The solution is the one you stated above--stick to one particular flavor of pd and run with it. I for one believe the sooner I switch my patches to a more consistent drawing mechanism the less I will have to deal with down the road. pd has two choices:
- keep the same inconsistent behaviour for as long as it exists causing
problems in other places for the patch developers such as yourself (e.g. autopatching), in the end causing the same amount of work (whether you fix whatever is currently misaligned or do that while patching because your autopatch feature did not align your objects properly is as far as I can tell the same amount of work, of course, assuming that you do use autopatch--I do, so this is very important to me)
- fix this at some later date at which point you will have a larger
library of patches you've built between now and that later date that will require fixing because they relied on the current inconsistent way
Consider also how pd does not properly account for labels on iemguis or comments and does not mind having them stick outside GOP. Or how dynamically changed iemgui objects inside GOP do not get their visibility rechecked to see if they still fit within GOP and then spill outside it only to disappear when you copy and paste the said GOP. These are all fixed within pd-l2ork. I believe these are very pressing issues for me as L2Ork's entire GUI scoring system is built around iemguis and scalars and I want to make sure that others developing similar scores (or expanding upon the existing) for the ensemble do not encounter such inconsistencies that can be abused for temporary solutions that later break because such bugs have been fixed, rendering their scoring engine unusable.
tl;dr version: I find issues of GUI inconsistency critical and prefer to fix them sooner rather than later and do not want to worry about legacy behaviour that is incorrect to begin with, because the longer one waits, the more they'll have to fix later when the similar/identical fix is implemented in their flavor of pd.
Thanks for your considerations. I actually agree with you in every respect. I also wouldn't mind having GUI glitches fixed in pd-extended| pd-vanilla, even if it means having to go through all my patches to fix them. However, things haven't changed in pd-vanilla|pd-extended yet and I see myself forced to decide which route to go.
Roman
Indeed. Let's hope pd/extended adopt these soon.
Best wishes,
Ico On Jul 3, 2013 7:31 AM, "Roman Haefeli" reduzent@gmail.com wrote:
On Wed, 2013-07-03 at 05:53 -0400, Ivica Ico Bukvic wrote:
On 07/03/2013 04:31 AM, Roman Haefeli wrote:
On Wed, 2013-07-03 at 03:56 -0400, Ivica Bukvic wrote:
I guess we need to clarify what "not usable at all" means. If a patch works but one optional gop hsl is not visible, personally I would say that one element may not be usable and only temporarily.
Many of my patches are not usable at all without GOP GUIs visible. And
I
cannot fix it myself as either it breaks pd-vanilla|pd-extended or pd-l2ork or it looks dead ugly. So yes, it breaks compatibility in a serious way. And I also do not see the temporary aspect of it. I as a patch developer can't provide a solution to this.
This is _the_ reason I don't even try to bother to make my patches work in pd-l2ork. And I even need to tell people that they shouldn't use pd-l2ork when they want to use my patches.
The solution is the one you stated above--stick to one particular flavor of pd and run with it. I for one believe the sooner I switch my patches to a more consistent drawing mechanism the less I will have to deal with down the road. pd has two choices:
- keep the same inconsistent behaviour for as long as it exists causing
problems in other places for the patch developers such as yourself (e.g. autopatching), in the end causing the same amount of work (whether you fix whatever is currently misaligned or do that while patching because your autopatch feature did not align your objects properly is as far as I can tell the same amount of work, of course, assuming that you do use autopatch--I do, so this is very important to me)
- fix this at some later date at which point you will have a larger
library of patches you've built between now and that later date that will require fixing because they relied on the current inconsistent way
Consider also how pd does not properly account for labels on iemguis or comments and does not mind having them stick outside GOP. Or how dynamically changed iemgui objects inside GOP do not get their visibility rechecked to see if they still fit within GOP and then spill outside it only to disappear when you copy and paste the said GOP. These are all fixed within pd-l2ork. I believe these are very pressing issues for me as L2Ork's entire GUI scoring system is built around iemguis and scalars and I want to make sure that others developing similar scores (or expanding upon the existing) for the ensemble do not encounter such inconsistencies that can be abused for temporary solutions that later break because such bugs have been fixed, rendering their scoring engine unusable.
tl;dr version: I find issues of GUI inconsistency critical and prefer to fix them sooner rather than later and do not want to worry about legacy behaviour that is incorrect to begin with, because the longer one waits, the more they'll have to fix later when the similar/identical fix is implemented in their flavor of pd.
Thanks for your considerations. I actually agree with you in every respect. I also wouldn't mind having GUI glitches fixed in pd-extended| pd-vanilla, even if it means having to go through all my patches to fix them. However, things haven't changed in pd-vanilla|pd-extended yet and I see myself forced to decide which route to go.
Roman
On 07/03/2013 07:31 AM, Roman Haefeli wrote:
On Wed, 2013-07-03 at 05:53 -0400, Ivica Ico Bukvic wrote:
On 07/03/2013 04:31 AM, Roman Haefeli wrote:
On Wed, 2013-07-03 at 03:56 -0400, Ivica Bukvic wrote:
I guess we need to clarify what "not usable at all" means. If a patch works but one optional gop hsl is not visible, personally I would say that one element may not be usable and only temporarily.
Many of my patches are not usable at all without GOP GUIs visible. And I cannot fix it myself as either it breaks pd-vanilla|pd-extended or pd-l2ork or it looks dead ugly. So yes, it breaks compatibility in a serious way. And I also do not see the temporary aspect of it. I as a patch developer can't provide a solution to this.
This is _the_ reason I don't even try to bother to make my patches work in pd-l2ork. And I even need to tell people that they shouldn't use pd-l2ork when they want to use my patches.
The solution is the one you stated above--stick to one particular flavor of pd and run with it. I for one believe the sooner I switch my patches to a more consistent drawing mechanism the less I will have to deal with down the road. pd has two choices:
- keep the same inconsistent behaviour for as long as it exists causing
problems in other places for the patch developers such as yourself (e.g. autopatching), in the end causing the same amount of work (whether you fix whatever is currently misaligned or do that while patching because your autopatch feature did not align your objects properly is as far as I can tell the same amount of work, of course, assuming that you do use autopatch--I do, so this is very important to me)
- fix this at some later date at which point you will have a larger
library of patches you've built between now and that later date that will require fixing because they relied on the current inconsistent way
Consider also how pd does not properly account for labels on iemguis or comments and does not mind having them stick outside GOP. Or how dynamically changed iemgui objects inside GOP do not get their visibility rechecked to see if they still fit within GOP and then spill outside it only to disappear when you copy and paste the said GOP. These are all fixed within pd-l2ork. I believe these are very pressing issues for me as L2Ork's entire GUI scoring system is built around iemguis and scalars and I want to make sure that others developing similar scores (or expanding upon the existing) for the ensemble do not encounter such inconsistencies that can be abused for temporary solutions that later break because such bugs have been fixed, rendering their scoring engine unusable.
tl;dr version: I find issues of GUI inconsistency critical and prefer to fix them sooner rather than later and do not want to worry about legacy behaviour that is incorrect to begin with, because the longer one waits, the more they'll have to fix later when the similar/identical fix is implemented in their flavor of pd.
Thanks for your considerations. I actually agree with you in every respect. I also wouldn't mind having GUI glitches fixed in pd-extended| pd-vanilla, even if it means having to go through all my patches to fix them.
Well, maybe if we can get the bug fixed in all distributions then we could automate updating all the gop abstractions in svn.
But if standardization doesn't happen it's going to cause minor but _unfixable_ annoyances for all distributions.
-Jonathan
However, things haven't changed in pd-vanilla|pd-extended yet and I see myself forced to decide which route to go.
Roman
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 07/03/2013 04:31 AM, Roman Haefeli wrote:
On Wed, 2013-07-03 at 03:56 -0400, Ivica Bukvic wrote:
On Jul 3, 2013 1:38 AM, "Roman Haefeli" reduzent@gmail.com wrote:
On Die, 2013-07-02 at 19:15 -0400, Ivica Ico Bukvic wrote:
[symbol
| [label $1( | [cnv]
- (ATTN: Ivica) [hsl] seems to have the bounding box (?)
miscalculated
in l2ork so it doesn't GOP when it's less than 2-3px from the
border
of the parent canvas. Checked in Vanilla, it works as expected
([hsl]
can be placed to the very border and it will GOP).
According to Ivica this is on purpose. The reason is that
iemguis used
to have miscalculated positions and pd-l2ork fixed that while pd-vanilla/pd-extended didn't. Unfortunately, this breaks
compatibility
between pd-l2ork and pd-vanilla/pd-extended.
This is true. Although, I wouldn't call translating an object by 3 pixels exactly breaking compatibility.
If a patch just isn't usable at all on a different flavor, then I
don't
see how this doesn't qualify for breaking compatibility.
Roman
I guess we need to clarify what "not usable at all" means. If a patch works but one optional gop hsl is not visible, personally I would say that one element may not be usable and only temporarily.
I agree with Roman. Patch authors were being very reasonable when they created their GOPs that just so happened to be based on faulty logic under the hood. Those discrepancies were extremely small, small enough that most patch author's probably didn't even notice the bug until you pointed it out and fixed it.
So through no fault of their own, their patches are broken on the distribution of Pd that has a superior UX. That's a bad situation.
If you have a solution not too far off that will allow such GOP objects to be functional again, then the temporary breakage is probably ok. If not, then we need to keep the bug for all eternity and work around it.
To do otherwise is to scare off potential users who have no idea how many other changes will break their patches because of idiosyncracies that lurk deep in code that Pd was designed to abstract away from them.
-Jonathan
Many of my patches are not usable at all without GOP GUIs visible. And I cannot fix it myself as either it breaks pd-vanilla|pd-extended or pd-l2ork or it looks dead ugly. So yes, it breaks compatibility in a serious way. And I also do not see the temporary aspect of it. I as a patch developer can't provide a solution to this.
This is _the_ reason I don't even try to bother to make my patches work in pd-l2ork. And I even need to tell people that they shouldn't use pd-l2ork when they want to use my patches.
If you are looking for things that really break compatibility, then those would be things like preset_node object that are current only possible in pd-l2ork.
Actually, one can decide to use or not to use new features. Obviously, added features do not work in flavors that do not implement that feature. From a user point of view, this can be dealt with in an clean way. If you want your patch to work on other flavors, don't use stuff like preset_node. I don't see a problem at all with that.
Roman
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Jul 3, 2013 7:09 PM, "Jonathan Wilkes" jancsika@yahoo.com wrote:
On 07/03/2013 04:31 AM, Roman Haefeli wrote:
On Wed, 2013-07-03 at 03:56 -0400, Ivica Bukvic wrote:
On Jul 3, 2013 1:38 AM, "Roman Haefeli" reduzent@gmail.com wrote:
On Die, 2013-07-02 at 19:15 -0400, Ivica Ico Bukvic wrote:
[symbol
| [label $1( | [cnv]> - (ATTN: Ivica) [hsl] seems to have the bounding box (?)
miscalculated
> > in l2ork so it doesn't GOP when it's less than 2-3px from the
border
> > of the parent canvas. Checked in Vanilla, it works as expected
([hsl]
> > can be placed to the very border and it will GOP).
According to Ivica this is on purpose. The reason is that
iemguis used
to have miscalculated positions and pd-l2ork fixed that while pd-vanilla/pd-extended didn't. Unfortunately, this breaks
compatibility
between pd-l2ork and pd-vanilla/pd-extended.
This is true. Although, I wouldn't call translating an object by 3 pixels exactly breaking compatibility.
If a patch just isn't usable at all on a different flavor, then I
don't
see how this doesn't qualify for breaking compatibility.
Roman
I guess we need to clarify what "not usable at all" means. If a patch works but one optional gop hsl is not visible, personally I would say that one element may not be usable and only temporarily.
I agree with Roman. Patch authors were being very reasonable when they created their GOPs that just so happened to be based on faulty logic under the hood. Those discrepancies were extremely small, small enough that most patch author's probably didn't even notice the bug until you pointed it out and fixed it.
For me having a new user face inconsistency with autopatching is a lot more critical than an existing user encounter an inconsistency due to the fact that an old bug has been fixed.
One could approach this problem by having a hack that adjusts the spacing during autopatching and that's exactly what I used to have. At some point I simply realized that I was adding more and more hacks to keep the hack propagating through the undo and other functions, and came to the conclusion it's time to start cleaning up hacks like these and make the code cleaner and easier to maintain.
Otherwise, by your suggested approach one could conclude that PD is perfect as-is and that no other development/changes are necessary. Case in point if a comment or labels for iemgui objects do in part fall out of GOP area, pd/extended still render them visible. Since this bug has been there for some time there are possibly patches out there that exploit this bug as a feature and by using your logic we should never change that either as doing so would break old patches. Again, if we take the suggested approach then there's nothing to change about pd. OTOH, one could ostensibly look into creating a simple shell script that when run could easily adapt all of the old patches to the new spacing. Perhaps someone else may want to contribute this?
In summary let us hope that other versions of the pd adopt the same/similar fixes and do so soon.
Best wishes,
Ico
So through no fault of their own, their patches are broken on the distribution of Pd that has a superior UX. That's a bad situation.
If you have a solution not too far off that will allow such GOP objects to be functional again, then the temporary breakage is probably ok. If not, then we need to keep the bug for all eternity and work around it.
To do otherwise is to scare off potential users who have no idea how many other changes will break their patches because of idiosyncracies that lurk deep in code that Pd was designed to abstract away from them.
-Jonathan
Many of my patches are not usable at all without GOP GUIs visible. And I cannot fix it myself as either it breaks pd-vanilla|pd-extended or pd-l2ork or it looks dead ugly. So yes, it breaks compatibility in a serious way. And I also do not see the temporary aspect of it. I as a patch developer can't provide a solution to this.
This is _the_ reason I don't even try to bother to make my patches work in pd-l2ork. And I even need to tell people that they shouldn't use pd-l2ork when they want to use my patches.
If you are looking for things that really break compatibility, then those would be things like preset_node object that are current only possible in pd-l2ork.
Actually, one can decide to use or not to use new features. Obviously, added features do not work in flavors that do not implement that feature. From a user point of view, this can be dealt with in an clean way. If you want your patch to work on other flavors, don't use stuff like preset_node. I don't see a problem at all with that.
Roman
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
On Wed, Jul 3, 2013 at 1:15 AM, Ivica Ico Bukvic ico@vt.edu wrote:
[...]
However, if the object appears within the GOP boundaries but is still not
visible in GOP window, then there may be some stale things I missed in the getrect call for hsl. In this case, please do file a bug report.
Best wishes,
Ico
I would. Where is the l2ork bug tracker? I see you don't use the tracker on github...
I have compiled the newest l2ork and things are almost perfect, if not perfect. My hsl and cnv still don't fit where they should but I've realized it's because of their labels. The labels are rendered seemingly inside the objects' boundaries, however I need to decrease the font size further to make them GOP. Please see the attached little example patch.
Thanks,
András
That is because tk renders them as such. In other words when text is written inside the canvas it is not just the text itself that takes up space but imagine a box around it as if you were to select text that actually within tk returns visible area required by the text itself. Finding out only the pixels assigned to text itself without having direct access to tk is extremely cumbersome if not impossible. This is also why comment when jam packed right against the edge of the graph on parent box is not visible because of this invisible selection area that is reserved for the text. On Jul 3, 2013 11:47 AM, "András Murányi" muranyia@gmail.com wrote:
On Wed, Jul 3, 2013 at 1:15 AM, Ivica Ico Bukvic ico@vt.edu wrote:
[...]
However, if the object appears within the GOP boundaries but is still not
visible in GOP window, then there may be some stale things I missed in the getrect call for hsl. In this case, please do file a bug report.
Best wishes,
Ico
I would. Where is the l2ork bug tracker? I see you don't use the tracker on github...
I have compiled the newest l2ork and things are almost perfect, if not perfect. My hsl and cnv still don't fit where they should but I've realized it's because of their labels. The labels are rendered seemingly inside the objects' boundaries, however I need to decrease the font size further to make them GOP. Please see the attached little example patch.
Thanks,
András
Forgot to add, try selecting comment text and you will notice how much more space selected area takes up then the text itself. This is what pd-l2ork takes into account when calculating whether something fits within the gop boundaries or not. HTH On Jul 3, 2013 1:35 PM, "Ivica Bukvic" ico@vt.edu wrote:
That is because tk renders them as such. In other words when text is written inside the canvas it is not just the text itself that takes up space but imagine a box around it as if you were to select text that actually within tk returns visible area required by the text itself. Finding out only the pixels assigned to text itself without having direct access to tk is extremely cumbersome if not impossible. This is also why comment when jam packed right against the edge of the graph on parent box is not visible because of this invisible selection area that is reserved for the text. On Jul 3, 2013 11:47 AM, "András Murányi" muranyia@gmail.com wrote:
On Wed, Jul 3, 2013 at 1:15 AM, Ivica Ico Bukvic ico@vt.edu wrote:
[...]
However, if the object appears within the GOP boundaries but is still not
visible in GOP window, then there may be some stale things I missed in the getrect call for hsl. In this case, please do file a bug report.
Best wishes,
Ico
I would. Where is the l2ork bug tracker? I see you don't use the tracker on github...
I have compiled the newest l2ork and things are almost perfect, if not perfect. My hsl and cnv still don't fit where they should but I've realized it's because of their labels. The labels are rendered seemingly inside the objects' boundaries, however I need to decrease the font size further to make them GOP. Please see the attached little example patch.
Thanks,
András
Thanks for the explanation. Tcl/tk is so funny!
András
On Wed, Jul 3, 2013 at 7:35 PM, Ivica Bukvic ico@vt.edu wrote:
That is because tk renders them as such. In other words when text is written inside the canvas it is not just the text itself that takes up space but imagine a box around it as if you were to select text that actually within tk returns visible area required by the text itself. Finding out only the pixels assigned to text itself without having direct access to tk is extremely cumbersome if not impossible. This is also why comment when jam packed right against the edge of the graph on parent box is not visible because of this invisible selection area that is reserved for the text. On Jul 3, 2013 11:47 AM, "András Murányi" muranyia@gmail.com wrote:
On Wed, Jul 3, 2013 at 1:15 AM, Ivica Ico Bukvic ico@vt.edu wrote:
[...]
However, if the object appears within the GOP boundaries but is still not
visible in GOP window, then there may be some stale things I missed in the getrect call for hsl. In this case, please do file a bug report.
Best wishes,
Ico
I would. Where is the l2ork bug tracker? I see you don't use the tracker on github...
I have compiled the newest l2ork and things are almost perfect, if not perfect. My hsl and cnv still don't fit where they should but I've realized it's because of their labels. The labels are rendered seemingly inside the objects' boundaries, however I need to decrease the font size further to make them GOP. Please see the attached little example patch.
Thanks,
András
On 07/02/2013 06:54 AM, András Murányi wrote:
On Mon, Jul 1, 2013 at 10:05 PM, Roman Haefeli <reduzent@gmail.com mailto:reduzent@gmail.com> wrote:
On Mon, 2013-07-01 at 20:56 +0200, András Murányi wrote: > I'm reformulating my question as the problem is evolving: > do we have an object that > - Displays and holds a text value (like Symbol or Message box), * symbolbox with width set 0 resizes dynamically * hsl, vsl, cnv, etc. can adjust size with 'size' message, can change displayed text with 'label' messageVery good idea, thanks Roman! Some difficulties I'm having:
- I don't know how to set the label of [cnv]... is it possible at all?
- (ATTN: Ivica) [hsl] seems to have the bounding box (?) miscalculated
in l2ork so it doesn't GOP when it's less than 2-3px from the border of the parent canvas. Checked in Vanilla, it works as expected ([hsl] can be placed to the very border and it will GOP).
> - is Graph-on-Parent,
If you start with an auto-resizable widget or iemgui label that takes an arbitrary string you probably don't want to combine it with a fixed-width geometry manager (geometry unmanager?) like a GOP canvas.
You'll have to resize the width of the GOP box manually, which means you have to listen for changes to the string length of the label and _guess_ at how many pixels that translates to. If you guess wrong (and given that different OSes do fonts differently you will guess wrong) it will break. Every modern GUI toolkit (even tk) assumes that the developer doesn't want to worry about these problems, or at least assume they only want to control them at a much higher level.
For some context: Pd's diagrams actually break all the time: whenever patch authors set up objects so that the wires to/from a secondary xlet are either straight or at 45-degree angles. Those lines may not be at the same angle on someone else's machine, because of font rendering peculiarities on the OS or specific font settings that user has made. The breakage can actually introduce ambiguities that aren't there on the original author's machine, but most of the time these breakages just degrade the diagram gracefully-- you get not-quite-straight lines that don't look as aesthetically pleasing but the patch is fully functional/editable.
If your iemgui label or symbol box on a GOP canvas goes over the allotted pixel width of the GOP rectangle you lose functionality because the object no longer moves with the GOP canvas. If you're making a one-off GUI for your own purposes this may be fine, but if you're trying to make a reusable abstraction, don't combine auto-resizing widgets with geometry-unmanagers. They don't degrade gracefully, and the pitfalls aren't trivial to see unless you stream the patch to three different OSes at the same time and watch the differences.
-Jonathan
On 07/02/2013 06:54 AM, András Murányi wrote:
Very good idea, thanks Roman! Some difficulties I'm having:
- I don't know how to set the label of [cnv]... is it possible at all?
- (ATTN: Ivica) [hsl] seems to have the bounding box (?) miscalculated
in l2ork so it doesn't GOP when it's less than 2-3px from the border of the parent canvas. Checked in Vanilla, it works as expected ([hsl] can be placed to the very border and it will GOP).
Thanks for reporting this, András! hslider, vslider, and vumeter had indeed had incorrect getrect calculation for the bottom-right corners inside GOP (vu also had incorrect top). This has been fixed and committed a couple minutes ago into git. Binary builds of the new version forthcoming.
Best wishes,
-
András Murányi -
IOhannes m zmoelnig -
Ivica Bukvic -
Ivica Ico Bukvic
-
Jonathan Wilkes -
Roman Haefeli