Re: [PD] GOP text field / symbol which is resizeable? (was: GOP text field which sends bang?)
On Jul 3, 2013 1:38 AM, Roman Haefeli reduz...@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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] GOP text field / symbol which is resizeable? (was: GOP text field which sends bang?)
On Wed, 2013-07-03 at 03:56 -0400, Ivica Bukvic wrote: On Jul 3, 2013 1:38 AM, Roman Haefeli reduz...@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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] GOP text field / symbol which is resizeable? (was: GOP text field which sends bang?)
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: 1) 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) 2) 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. -- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound Intermedia Studio Director, L2Ork Linux Laptop Orchestra Head, ICAT IMPACT Studio Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] GOP text field / symbol which is resizeable? (was: GOP text field which sends bang?)
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, -- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound Intermedia Studio Director, L2Ork Linux Laptop Orchestra Head, ICAT IMPACT Studio Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] GOP text field / symbol which is resizeable? (was: GOP text field which sends bang?)
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: 1) 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) 2) 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] GOP text field / symbol which is resizeable? (was: GOP text field which sends bang?)
Indeed. Let's hope pd/extended adopt these soon. Best wishes, Ico On Jul 3, 2013 7:31 AM, Roman Haefeli reduz...@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: 1) 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) 2) 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] GOP text field / symbol which is resizeable? (was: GOP text field which sends bang?)
On Wed, Jul 3, 2013 at 1:15 AM, Ivica Ico Bukvic i...@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 GOP-Label-test.pd Description: Binary data ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] GOP text field / symbol which is resizeable? (was: GOP text field which sends bang?)
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 muran...@gmail.com wrote: On Wed, Jul 3, 2013 at 1:15 AM, Ivica Ico Bukvic i...@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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] GOP text field / symbol which is resizeable? (was: GOP text field which sends bang?)
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 i...@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 muran...@gmail.com wrote: On Wed, Jul 3, 2013 at 1:15 AM, Ivica Ico Bukvic i...@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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] GOP text field / symbol which is resizeable? (was: GOP text field which sends bang?)
Thanks for the explanation. Tcl/tk is so funny! András On Wed, Jul 3, 2013 at 7:35 PM, Ivica Bukvic i...@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 muran...@gmail.com wrote: On Wed, Jul 3, 2013 at 1:15 AM, Ivica Ico Bukvic i...@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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] GOP text field / symbol which is resizeable? (was: GOP text field which sends bang?)
On Mon, Jul 1, 2013 at 10:05 PM, Roman Haefeli reduz...@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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] GOP text field / symbol which is resizeable? (was: GOP text field which sends bang?)
-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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlHSwlMACgkQkX2Xpv6ydvTHXgCg437h6lN1opMPE5jOXCMLy3Fl 0FYAn2rB02hqmCKVrbYoHZ1r/fejYvWZ =WHr9 -END PGP SIGNATURE- ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] GOP text field / symbol which is resizeable? (was: GOP text field which sends bang?)
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 reduz...@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] - (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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] GOP text field / symbol which is resizeable? (was: GOP text field which sends bang?)
On Tue, Jul 2, 2013 at 2:06 PM, IOhannes m zmoelnig zmoel...@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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] GOP text field / symbol which is resizeable? (was: GOP text field which sends bang?)
On Tue, Jul 2, 2013 at 2:27 PM, Roman Haefeli reduz...@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 reduz...@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. - (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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] GOP text field / symbol which is resizeable? (was: GOP text field which sends bang?)
On 07/02/2013 02:41 PM, András Murányi wrote: On Tue, Jul 2, 2013 at 2:27 PM, Roman Haefeli reduz...@gmail.com mailto:reduz...@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 reduz...@gmail.com mailto:reduz...@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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] GOP text field / symbol which is resizeable? (was: GOP text field which sends bang?)
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 reduz...@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 reduz...@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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] GOP text field / symbol which is resizeable? (was: GOP text field which sends bang?)
[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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] GOP text field / symbol which is resizeable? (was: GOP text field which sends bang?)
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] GOP text field / symbol which is resizeable? (was: GOP text field which sends bang?)
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 muran...@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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] GOP text field / symbol which is resizeable? (was: GOP text field which sends bang?)
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
