Re: [PD] GOP text field / symbol which is resizeable? (was: GOP text field which sends bang?)

[András Murányi]

Thanks for the explanation.
Tcl/tk is so funny!

András

On Wed, Jul 3, 2013 at 7:35 PM, Ivica Bukvic  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"  wrote:
>
>>
>> On Wed, Jul 3, 2013 at 1:15 AM, Ivica Ico Bukvic  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?)

[Ivica Bukvic]

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"  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"  wrote:
>
>>
>> On Wed, Jul 3, 2013 at 1:15 AM, Ivica Ico Bukvic  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?)

[Ivica Bukvic]

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"  wrote:

>
> On Wed, Jul 3, 2013 at 1:15 AM, Ivica Ico Bukvic  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?)

[András Murányi]

On Wed, Jul 3, 2013 at 1:15 AM, Ivica Ico Bukvic  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?)

[Ivica Bukvic]

Indeed. Let's hope pd/extended adopt these soon.

Best wishes,

Ico
On Jul 3, 2013 7: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:
> >
> > 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?)

[Roman Haefeli]

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?)

[Ivica Ico Bukvic]

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?)

[Ivica Ico Bukvic]

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?)

[Roman Haefeli]

On Wed, 2013-07-03 at 03:56 -0400, Ivica Bukvic wrote:
> 
> On Jul 3, 2013 1:38 AM, "Roman Haefeli"  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?)

[Ivica Bukvic]

On Jul 3, 2013 1:38 AM, "Roman Haefeli"  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?)

[Roman Haefeli]

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

Re: [PD] GOP text field / symbol which is resizeable? (was: GOP text field which sends bang?)

[Ivica Ico Bukvic]

> [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?)

[Roman Haefeli]

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 
> > 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
> > 
> > > 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?)

[Jonathan Wilkes]

On 07/02/2013 02:41 PM, András Murányi wrote:
On Tue, Jul 2, 2013 at 2:27 PM, Roman Haefeli > 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
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?)

[András Murányi]

On Tue, Jul 2, 2013 at 2:27 PM, Roman Haefeli  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 
> > 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?)

[András Murányi]

On Tue, Jul 2, 2013 at 2:06 PM, IOhannes m zmoelnig  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?)

[Roman Haefeli]

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 
> 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?)

[IOhannes m zmoelnig]

-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?)

[András Murányi]

On Mon, Jul 1, 2013 at 10:05 PM, Roman Haefeli  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?)

[Roman Haefeli]

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

[PD] GOP text field / symbol which is resizeable? (was: GOP text field which sends bang?)

[András Murányi]

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  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