Re: [PD] cyclone comment and cross platform (was Re: Purr Data rc1)

[Jonathan Wilkes via Pd-list]

> The character is not invisible. In an editor it manifests with an endline 
> plus an indentation in the following line which actually visually helps parse 
> things out inside a plaintext file like .pd.
 

 I think the example you mentioned, while possible, is contrived because if a 
user is reading a config, they are likely already inside Pd with the intention 
of using such a config to configure their patch state. If this is the case, and 
the config is stored inside a patch in a form of a comment, then this is a 
non-issue because all \v chars are replaced with \n at runtime which IIRC 
regexp and similar methodologies can recognize as a separation between args. 
Now, the only reason I can imagine someone parsing a pd file without actually 
loading it would be your pd META example for tooltips which is a one-off 
example that can be easily addressed in a number of ways. Other examples seem 
to me like academic exercises--why would you store config inside a comments 
inside a pd patch, just to parse a comment which would require you to 
circumnavigate all the other syntax inside the file when you could do the same 
in a plaintext file or a coll object, or better yet, use preset_hub/node 
system? 
I agree that '\v' is a small inconsistency, but it's an inconsistency 
nonetheless.  
I worry about it getting used a model more than anything else.
This mostly comes after seeing the warnings in core Pd, and noticing that the 
same class of warnings is replicated throughout nearly all of the external 
libraries.
 
-Jonathan

> Best, Ico
  
 On 12/4/2016 2:38 PM, Jonathan Wilkes wrote:
  
   
 
> What about people parsing Pd files in Pd?  If they're searching for 
symbol "foo", are they going to have to deal with the edge case of symbol 
"foo\v"? 
  Ivica, Just to give an example-- suppose someone is using a 
patch to store configuration data for their project.  They type the config data 
as comments in the 
  patch, much like [pd META].  Then they parse their patch from within Pd, 
using [textfile], or [text] or  whatever.
  
  Now, if they decide to insert some newlines into the comments to make their 
config prettier, as far as I understand this ends up appending an invisible 
  '\v' character to the last atom of each line.  So the next time they read 
their config they will get corrupted data that's hard to debug because  the 
  character doing the corruption is non-printable. 
   That's the only direct downside I can see.  But as a design pattern it's 
problematic-- there are other places in Pd where a dev tried to  use an 
  "obscure" character as a placeholder for something else.  That approach 
usually ends up creating more bugs. 
  -Jonathan
   
 
 

   ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] cyclone comment and cross platform (was Re: Purr Data rc1)

[Alexandre Torres Porres]

2016-12-03 23:27 GMT-02:00 Jonathan Wilkes :

> Why not just use the built-in  comment?
>


So, why use cyclone/comment instead of pd’s comment?

It does offer advantages as it is, such as setting a different font type,
different font size and colors. It is still not updated  to the latest
version of Max 4, let alone up to Max 7, so it can be improved by including
other functionalities, such as background color. We didn’t touch it yet and
I was hoping to at least include a properties window as it’d be the
sensible thing to do with it.


I’ve been finding it very useful, and I can see advantages to have it in
vanilla even if you could use labels with spaces in there, such as not
having any canvas background or being able to break the text into different
lines.

Why keep distributing cyclone/comment in cyclone? Well, cause it was there
before…

Now, we have some issues with it.

In the cyclone development end, we find it is not behaving well in cross
platforms, we need to fix this! We haven’t really tried it yet… and we’re
not sure where to look.

In the Purr Data end, it is not yet ported, and it is the only object in
cyclone that doesn’t load yet.

So, my idea would be to maybe start a new cyclone/comment for Purr Data,
having it’s ability to use spaces in GUI’s labels as a starting point.
Somewhere in this process, it’d be good to come up with also a working
external, that doesn’t look weird in Linux, for the cyclone package release.


cheers
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] cyclone comment and cross platform (was Re: Purr Data rc1)

[Ivica Ico Bukvic]

The character is not invisible. In an editor it manifests with an 
endline plus an indentation in the following line which actually 
visually helps parse things out inside a plaintext file like .pd.


I think the example you mentioned, while possible, is contrived because 
if a user is reading a config, they are likely already inside Pd with 
the intention of using such a config to configure their patch state. If 
this is the case, and the config is stored inside a patch in a form of a 
comment, then this is a non-issue because all \v chars are replaced with 
\n at runtime which IIRC regexp and similar methodologies can recognize 
as a separation between args.


Now, the only reason I can imagine someone parsing a pd file without 
actually loading it would be your pd META example for tooltips which is 
a one-off example that can be easily addressed in a number of ways. 
Other examples seem to me like academic exercises--why would you store 
config inside a comments inside a pd patch, just to parse a comment 
which would require you to circumnavigate all the other syntax inside 
the file when you could do the same in a plaintext file or a coll 
object, or better yet, use preset_hub/node system?


Best,

Ico


On 12/4/2016 2:38 PM, Jonathan Wilkes wrote:



> What about people parsing Pd files in Pd?  If they're searching for 
symbol "foo", are they going to have to deal with the edge case of 
symbol "foo\v"?


Ivica,
Just to give an example-- suppose someone is using a patch to store 
configuration data for their project.  They type the config data as 
comments in the
patch, much like [pd META].  Then they parse their patch from within 
Pd, using [textfile], or [text] or whatever.


Now, if they decide to insert some newlines into the comments to make 
their config prettier, as far as I understand this ends up appending 
an invisible
'\v' character to the last atom of each line.  So the next time they 
read their config they will get corrupted data that's hard to debug 
because the

character doing the corruption is non-printable.

That's the only direct downside I can see.  But as a design pattern 
it's problematic-- there are other places in Pd where a dev tried to 
use an
"obscure" character as a placeholder for something else.  That 
approach usually ends up creating more bugs.


-Jonathan


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] cyclone comment and cross platform (was Re: Purr Data rc1)

[Jonathan Wilkes via Pd-list]

> What about people parsing Pd files in Pd?  If they're searching for symbol 
> "foo", are they going to have to deal with the edge case of symbol "foo\v"?
Ivica,Just to give an example-- suppose someone is using a patch to store 
configuration data for their project.  They type the config data as comments in 
the 
patch, much like [pd META].  Then they parse their patch from within Pd, using 
[textfile], or [text] or whatever.

Now, if they decide to insert some newlines into the comments to make their 
config prettier, as far as I understand this ends up appending an invisible 
'\v' character to the last atom of each line.  So the next time they read their 
config they will get corrupted data that's hard to debug because the 
character doing the corruption is non-printable.
That's the only direct downside I can see.  But as a design pattern it's 
problematic-- there are other places in Pd where a dev tried to use an 
"obscure" character as a placeholder for something else.  That approach usually 
ends up creating more bugs.
-Jonathan
   ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] cyclone comment and cross platform (was Re: Purr Data rc1)

[Ivica Ico Bukvic]

This only pertains to comments and as such should not make any 
difference elsewhere (unless you want to live-code something by hacking 
comments :-). Also, Pd-L2Ork inherited from extended search in patch 
option that offers match full or a subset of a string which should cover 
all the cases.



On 12/4/2016 1:57 PM, Jonathan Wilkes via Pd-list wrote:




*From:* IOhannes m zmölnig 
*To:* pd-list@lists.iem.at
*Sent:* Sunday, December 4, 2016 1:48 PM
*Subject:* Re: [PD] cyclone comment and cross platform (was Re: Purr 
Data rc1)


On 12/04/2016 07:13 PM, Jonathan Wilkes via Pd-list wrote:

>>  If they're searching for symbol "foo", are they going to have to 
deal with the edge case of symbol "foo\v"?


> hmm, how does "foo" not match "foo\v"?

[11(
|
[makefilename %c]
|
[symbol foo$1(
|
[select foo]
|
[bng]

-Jonathan

> grdsa
> IOhannes


___
Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list





___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] cyclone comment and cross platform (was Re: Purr Data rc1)

[IOhannes m zmölnig]

On 12/04/2016 07:57 PM, Jonathan Wilkes via Pd-list wrote:
> [11(|[makefilename %c]|[symbol foo$1(|[select foo]|[bng]

ah, i misread your question - i was thinking of regexes (parsing the
file outside of Pd)

Pd itself doesn't provide any ways to *search* for a string; the best
you can get is to iteratively match atoms which fails in this case.

gfmrdsa
IOhannes



signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] cyclone comment and cross platform (was Re: Purr Data rc1)

[Jonathan Wilkes via Pd-list]

  From: IOhannes m zmölnig 
 To: pd-list@lists.iem.at 
 Sent: Sunday, December 4, 2016 1:48 PM
 Subject: Re: [PD] cyclone comment and cross platform (was Re: Purr Data rc1)
   
On 12/04/2016 07:13 PM, Jonathan Wilkes via Pd-list wrote:
>>  If they're searching for symbol "foo", are they going to have to deal with 
>>the edge case of symbol "foo\v"?
> hmm, how does "foo" not match "foo\v"?

[11(|[makefilename %c]|[symbol foo$1(|[select foo]|[bng]
-Jonathan

> grdsa
> IOhannes

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list


   ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] cyclone comment and cross platform (was Re: Purr Data rc1)

[IOhannes m zmölnig]

On 12/04/2016 07:13 PM, Jonathan Wilkes via Pd-list wrote:
>  If they're searching for symbol "foo", are they going to have to deal with 
> the edge case of symbol "foo\v"?

hmm, how does "foo" not match "foo\v"?

grdsa
IOhannes



signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] cyclone comment and cross platform (was Re: Purr Data rc1)

[IOhannes m zmölnig]

On 12/04/2016 03:10 AM, Liam Goodacre wrote:
> Spaces work in labels in L2Ork because they are escaped with a backslash. But 
> this is creating an incompatibility with Vanilla, which then can't read the 
> object's properties.

are you sure?
my impression is, that Pd can parse any labels with backslash-escaped
spaces just fine (see attached patch with a canvas with a label with
spaces, which works nicely on my Pd-0.47-1 as packaged in Debian).

the only problem occurs when you try to save such patches.

mgfdsar
IOhannes
#N canvas 4 49 450 300 10;
#X obj 120 71 cnv 15 100 60 empty empty foo\ bar 20 12 0 14 -233017 -66577
0;


signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] cyclone comment and cross platform (was Re: Purr Data rc1)

[Jonathan Wilkes via Pd-list]

> Another thing that pd-l2ork's comment does that makes it theoretically 
> incompatible with vanilla, it recognizes line breaks and saves them. It uses 
> ASCII 11 to save it into the .pd file which is vertical tab that is by and 
> large unused. While vanilla shows line breaks when creating an object, 
> cutting and pasting it, or saving, closing, and reopening the file shows that 
> they don't get saved. As a result a lot of patches sidestep this by using 
> multiple comments, which is hard to maintain, particularly when it comes to 
> writing documentation.

 
  > Both improvements pd-l2ork uses could be easily ported back to vanilla as I 
cannot think of a scenario where it could potentially cause a breakage in 
backwards compatibility.
  
What about people parsing Pd files in Pd?  If they're searching for symbol 
"foo", are they going to have to deal with the edge case of symbol "foo\v"?

  > Best, 
  > Ico
  
 On 12/3/2016 9:10 PM, Liam Goodacre wrote:
  
 
#yiv8549058902 #yiv8549058902 -- P 
{margin-top:0;margin-bottom:0;}#yiv8549058902  Spaces work in labels in L2Ork 
because they are escaped with a backslash. But this is creating an 
incompatibility with Vanilla, which then can't read the object's properties.
  
 If you want a way to get larger, nicer text into a PD file than allowed with 
the ctrl+5 comment, the best way might be to use ASCII 255, the non breaking 
space (" "), which looks like a space but is read like a regular character. 
It's a bit of a pain to copy it between every word, but it works nicely across 
platforms once it's in place. A faster option for editing might be to let 
Vanilla replace spaces with underscores and then edit them in the .pd file with 
a text editor.
  
   From: Pd-list  on behalf of Jonathan Wilkes 
via Pd-list 
 Sent: 04 December 2016 01:27
 To: Alexandre Torres Porres
 Cc: Pd-List
 Subject: Re: [PD] cyclone comment and cross platform (was Re: Purr Data rc1)   
   Why not just use the built-in  comment?
  
 
   From: Alexandre Torres Porres 
 To: Jonathan Wilkes  
 Cc: Pd-List 
 Sent: Friday, December 2, 2016 1:10 PM
 Subject: Re: [PD] cyclone comment and cross platform (was Re: Purr Data rc1)
  
   Hi, I see Purr Data has this feature where it accepts spaces in lables such 
as in canvases... this is awesome, and mostly why I use cyclone/comment 
  I can see we could depart from how you can lable stuff in Purr Data to make a 
new working cross platform version of  cyclone/comment that is still backwards 
compatible. 
  cheers   
 2016-11-29 2:28 GMT-02:00 Alexandre Torres Porres :
 
  one question, how does canvas and other fonts for labels work in cross 
platforms?  
  why not use that for comment... for now, all cyclone/comment is can be 
thought of just being a  fancy label perhaps... 
  I did use it a lot in my new help files that I'm working on, but only cause 
it'd be too much  work to use canvas and labels, as it'd imply a canvas for 
each word as it doesn't take spaces (is only a symbol) 
  I was even thinking of ditching it when, it stopped working on vanilla 0.47 - 
yeah, that's  another thing, a fix needs to be made to vanilla for old versions 
of comment (0.2 and below to work) - but then I realized it could be really 
useful. I was also hoping  to add properties windows to make it more 
convenient. 
  anyway, the question is, why labels and stuff simply work? 
  cheers
 
  
 2016-11-28 21:45 GMT-02:00 Jonathan Wilkes  :
 
     
 

Another reason for putting it  off is that I still haven't figured 
out a sane approach 
   to handling arbitrary  fonts in a diagram where everything is  absolutely 
positioned.  
   In fact I only have a  minimally-workable approach to handling a  single, 
mono- 
   spaced font across  platforms.  For example, there was a  change somewhere 
in 
   the Gnu/Linux font-stack  (relatively) recently that renders fonts  (or at 
least 
   DejaVu Sans Mono)  noticeably wider than before.  So Windows, OSX, and 
   old Gnu/Linux would render a  particular line of text sized at  "12px" 
within less 
   than a single pixel of each  other.  The new Gnu/Linux font stack  (seen in 
Ubuntu 
   16.04 and some recent Arch)  rendered the same text about 7 pixels  wider.  
   Worse, the newer  Gnu/Linux font stack quantizes the  "px" sizes such that 
the  
   next smallest size is  noticeably smaller.  So in Ubuntu 16.04 I have  to 
compromise 
   by keeping the object box the  same size and having some extra padding at 
the 
   end-- otherwise  users of that OS could end up tightly  spacing their object 
chains  
   in ways that cause overlaps  on the other platforms. 
  So... I'd like to get a handle  on that mess first, then handling  arbitrary 
font 
   families-- as in  cyclone/comment-- will hopefully be easier and  less prone 
   to bugs.   

Re: [PD] cyclone comment and cross platform (was Re: Purr Data rc1)

[Ivica Ico Bukvic]

Another thing that pd-l2ork's comment does that makes it theoretically 
incompatible with vanilla, it recognizes line breaks and saves them. It 
uses ASCII 11 to save it into the .pd file which is vertical tab that is 
by and large unused. While vanilla shows line breaks when creating an 
object, cutting and pasting it, or saving, closing, and reopening the 
file shows that they don't get saved. As a result a lot of patches 
sidestep this by using multiple comments, which is hard to maintain, 
particularly when it comes to writing documentation.



Both improvements pd-l2ork uses could be easily ported back to vanilla 
as I cannot think of a scenario where it could potentially cause a 
breakage in backwards compatibility.



Best,


Ico


On 12/3/2016 9:10 PM, Liam Goodacre wrote:


Spaces work in labels in L2Ork because they are escaped with a 
backslash. But this is creating an incompatibility with Vanilla, which 
then can't read the object's properties.



If you want a way to get larger, nicer text into a PD file than 
allowed with the ctrl+5 comment, the best way might be to use ASCII 
255, the non breaking space (" "), which looks like a space but is 
read like a regular character. It's a bit of a pain to copy it between 
every word, but it works nicely across platforms once it's in place. A 
faster option for editing might be to let Vanilla replace spaces with 
underscores and then edit them in the .pd file with a text editor.




*From:* Pd-list  on behalf of Jonathan 
Wilkes via Pd-list 

*Sent:* 04 December 2016 01:27
*To:* Alexandre Torres Porres
*Cc:* Pd-List
*Subject:* Re: [PD] cyclone comment and cross platform (was Re: Purr 
Data rc1)

Why not just use the built-in  comment?



*From:* Alexandre Torres Porres 
*To:* Jonathan Wilkes 
*Cc:* Pd-List 
*Sent:* Friday, December 2, 2016 1:10 PM
*Subject:* Re: [PD] cyclone comment and cross platform (was Re: Purr 
Data rc1)


Hi, I see Purr Data has this feature where it accepts spaces in lables 
such as in canvases... this is awesome, and mostly why I use 
cyclone/comment


I can see we could depart from how you can lable stuff in Purr Data to 
make a new working cross platform version of cyclone/comment that is 
still backwards compatible.


cheers

2016-11-29 2:28 GMT-02:00 Alexandre Torres Porres <mailto:por...@gmail.com>>:


one question, how does canvas and other fonts for labels work in
cross platforms?

why not use that for comment... for now, all cyclone/comment is
can be thought of just being a fancy label perhaps...

I did use it a lot in my new help files that I'm working on, but
only cause it'd be too much work to use canvas and labels, as it'd
imply a canvas for each word as it doesn't take spaces (is only a
symbol)

I was even thinking of ditching it when, it stopped working on
vanilla 0.47 - yeah, that's another thing, a fix needs to be made
to vanilla for old versions of comment (0.2 and below to work) -
but then I realized it could be really useful. I was also hoping
to add properties windows to make it more convenient.

anyway, the question is, why labels and stuff simply work?

cheers


2016-11-28 21:45 GMT-02:00 Jonathan Wilkes mailto:jancs...@yahoo.com>>:



Another reason for putting it off is that I still haven't
figured out a sane approach
to handling arbitrary fonts in a diagram where everything
is absolutely positioned.
In fact I only have a minimally-workable approach to
handling a single, mono-
spaced font across platforms. For example, there was a
change somewhere in
the Gnu/Linux font-stack (relatively) recently that
renders fonts (or at least
DejaVu Sans Mono) noticeably wider than before.  So
Windows, OSX, and
old Gnu/Linux would render a particular line of text sized
at "12px" within less
than a single pixel of each other.  The new Gnu/Linux font
stack (seen in Ubuntu
16.04 and some recent Arch) rendered the same text about 7
pixels wider.

Worse, the newer Gnu/Linux font stack quantizes the "px"
sizes such that the
next smallest size is noticeably smaller.  So in Ubuntu
16.04 I have to compromise
by keeping the object box the same size and having some
extra padding at the
end-- otherwise users of that OS could end up tightly
spacing their object chains
in ways that cause overlaps on the other platforms.

So... I'd like to get a handle on that mess first, then
h

Re: [PD] cyclone comment and cross platform (was Re: Purr Data rc1)

[Liam Goodacre]

Spaces work in labels in L2Ork because they are escaped with a backslash. But 
this is creating an incompatibility with Vanilla, which then can't read the 
object's properties.


If you want a way to get larger, nicer text into a PD file than allowed with 
the ctrl+5 comment, the best way might be to use ASCII 255, the non breaking 
space (" "), which looks like a space but is read like a regular character. 
It's a bit of a pain to copy it between every word, but it works nicely across 
platforms once it's in place. A faster option for editing might be to let 
Vanilla replace spaces with underscores and then edit them in the .pd file with 
a text editor.


From: Pd-list  on behalf of Jonathan Wilkes via 
Pd-list 
Sent: 04 December 2016 01:27
To: Alexandre Torres Porres
Cc: Pd-List
Subject: Re: [PD] cyclone comment and cross platform (was Re: Purr Data rc1)

Why not just use the built-in  comment?



From: Alexandre Torres Porres 
To: Jonathan Wilkes 
Cc: Pd-List 
Sent: Friday, December 2, 2016 1:10 PM
Subject: Re: [PD] cyclone comment and cross platform (was Re: Purr Data rc1)

Hi, I see Purr Data has this feature where it accepts spaces in lables such as 
in canvases... this is awesome, and mostly why I use cyclone/comment

I can see we could depart from how you can lable stuff in Purr Data to make a 
new working cross platform version of cyclone/comment that is still backwards 
compatible.

cheers

2016-11-29 2:28 GMT-02:00 Alexandre Torres Porres 
mailto:por...@gmail.com>>:
one question, how does canvas and other fonts for labels work in cross 
platforms?

why not use that for comment... for now, all cyclone/comment is can be thought 
of just being a fancy label perhaps...

I did use it a lot in my new help files that I'm working on, but only cause 
it'd be too much work to use canvas and labels, as it'd imply a canvas for each 
word as it doesn't take spaces (is only a symbol)

I was even thinking of ditching it when, it stopped working on vanilla 0.47 - 
yeah, that's another thing, a fix needs to be made to vanilla for old versions 
of comment (0.2 and below to work) - but then I realized it could be really 
useful. I was also hoping to add properties windows to make it more convenient.

anyway, the question is, why labels and stuff simply work?

cheers


2016-11-28 21:45 GMT-02:00 Jonathan Wilkes 
mailto:jancs...@yahoo.com>>:



Another reason for putting it off is that I still haven't figured out a sane 
approach
to handling arbitrary fonts in a diagram where everything is absolutely 
positioned.
In fact I only have a minimally-workable approach to handling a single, mono-
spaced font across platforms.  For example, there was a change somewhere in
the Gnu/Linux font-stack (relatively) recently that renders fonts (or at least
DejaVu Sans Mono) noticeably wider than before.  So Windows, OSX, and
old Gnu/Linux would render a particular line of text sized at "12px" within less
than a single pixel of each other.  The new Gnu/Linux font stack (seen in Ubuntu
16.04 and some recent Arch) rendered the same text about 7 pixels wider.

Worse, the newer Gnu/Linux font stack quantizes the "px" sizes such that the
next smallest size is noticeably smaller.  So in Ubuntu 16.04 I have to 
compromise
by keeping the object box the same size and having some extra padding at the
end-- otherwise users of that OS could end up tightly spacing their object 
chains
in ways that cause overlaps on the other platforms.

So... I'd like to get a handle on that mess first, then handling arbitrary font
families-- as in cyclone/comment-- will hopefully be easier and less prone
to bugs.

> well, it seems some of the issues are exactly what we're facing now...

I think those issues are impossible to solve for displaying arbitrary fonts in
a diagram like a Pd patch, and especially for arbitrary fonts in multi-line 
text.
The user simply won't be able to predict whether or not there will be collisions
on someone else's platform (or even if those fonts aren't available, which fonts
will get chosen).

I'm all for porting cyclone/comment for the sake of Max compatibility.  But I'd
strongly advise against using cyclone/comment in any patch that's supposed to
be used cross-platform (aside from its own help patch, of course).

-Jonathan

> cheers




__ _
Pd-list@lists.iem.at<mailto:Pd-list@lists.iem.at> mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/ 
listinfo/pd-list<https://lists.puredata.info/listinfo/pd-list>




___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] cyclone comment and cross platform (was Re: Purr Data rc1)

[Jonathan Wilkes via Pd-list]

Why not just use the built-in  comment?


  From: Alexandre Torres Porres 
 To: Jonathan Wilkes  
Cc: Pd-List 
 Sent: Friday, December 2, 2016 1:10 PM
 Subject: Re: [PD] cyclone comment and cross platform (was Re: Purr Data rc1)
   
Hi, I see Purr Data has this feature where it accepts spaces in lables such as 
in canvases... this is awesome, and mostly why I use cyclone/comment
I can see we could depart from how you can lable stuff in Purr Data to make a 
new working cross platform version of cyclone/comment that is still backwards 
compatible.
cheers 
2016-11-29 2:28 GMT-02:00 Alexandre Torres Porres :

one question, how does canvas and other fonts for labels work in cross 
platforms?
why not use that for comment... for now, all cyclone/comment is can be thought 
of just being a fancy label perhaps...
I did use it a lot in my new help files that I'm working on, but only cause 
it'd be too much work to use canvas and labels, as it'd imply a canvas for each 
word as it doesn't take spaces (is only a symbol)
I was even thinking of ditching it when, it stopped working on vanilla 0.47 - 
yeah, that's another thing, a fix needs to be made to vanilla for old versions 
of comment (0.2 and below to work) - but then I realized it could be really 
useful. I was also hoping to add properties windows to make it more convenient.
anyway, the question is, why labels and stuff simply work?
cheers


2016-11-28 21:45 GMT-02:00 Jonathan Wilkes :

 


Another reason for putting it off is that I still haven't figured out a sane 
approach 
to handling arbitrary fonts in a diagram where everything is absolutely 
positioned.  
In fact I only have a minimally-workable approach to handling a single, mono- 
spaced font across platforms.  For example, there was a change somewhere in 
the Gnu/Linux font-stack (relatively) recently that renders fonts (or at least 
DejaVu Sans Mono) noticeably wider than before.  So Windows, OSX, and 
old Gnu/Linux would render a particular line of text sized at "12px" within 
less 
than a single pixel of each other.  The new Gnu/Linux font stack (seen in 
Ubuntu 
16.04 and some recent Arch) rendered the same text about 7 pixels wider.
Worse, the newer Gnu/Linux font stack quantizes the "px" sizes such that the 
next smallest size is noticeably smaller.  So in Ubuntu 16.04 I have to 
compromise 
by keeping the object box the same size and having some extra padding at the 
end-- otherwise users of that OS could end up tightly spacing their object 
chains 
in ways that cause overlaps on the other platforms.
So... I'd like to get a handle on that mess first, then handling arbitrary font 
families-- as in cyclone/comment-- will hopefully be easier and less prone 
to bugs.

> well, it seems some of the issues are exactly what we're facing now...
I think those issues are impossible to solve for displaying arbitrary fonts in 
a diagram like a Pd patch, and especially for arbitrary fonts in multi-line 
text.  
The user simply won't be able to predict whether or not there will be 
collisions 
on someone else's platform (or even if those fonts aren't available, which 
fonts 
will get chosen).

I'm all for porting cyclone/comment for the sake of Max compatibility.  But I'd 
strongly advise against using cyclone/comment in any patch that's supposed to 
be used cross-platform (aside from its own help patch, of course).

-Jonathan

> cheers

   


__ _
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/ 
listinfo/pd-list





   ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] cyclone comment and cross platform (was Re: Purr Data rc1)

[Alexandre Torres Porres]

well, another thing is getting cyclone/comment to work in Purr-data, which
it isn't yet, and needed to be ported. So maybe at least we could fix that
and sort it out by departing from this label structure into a new
cyclone/comment external for Purr-data, that seems like something that
makes sense

2016-12-02 23:06 GMT-02:00 Alexandre Torres Porres :

> but how about getting that functionality as an external.
>
> One thing is opening a vanilla GUI with spaces in the lable and trying to
> open that in Vanilla, another would be to have it an external GUI object
> with such functionality (such as cyclone/comment) and load it anywhere.
>
> I'm not really aware of the existing issues in cyclone/comment, and we
> haven't touched it yet, but they do not behave well in cross platforms.
>
> My insight was that maybe we could use the code from purr-data, but as I
> write this now, I realize how purr-data has this completely different GUI
> front end, that's completely different to what's in Pd, so I may have been
> way off...
>
> 2016-12-02 22:41 GMT-02:00 Ivica Ico Bukvic :
>
>> This has been around for some time in pd-l2ork and by extension in
>> Purr-Data, but as Liam recently pointed out on the l2ork-dev list, it can
>> also break patches on vanilla where spaces (including escaped ones) in the
>> .pd file get misinterpreted by the vanilla parser. Liam suggested changing
>> those to ASCII 255 which is some other sort of a space... Something to be
>> investigated further down the road. Of course, an alternative would be that
>> vanilla ports the same space parsing method from pd-l2ork/purr-data.
>>
>> Best,
>>
>> Ico
>>
>> On 12/2/2016 1:10 PM, Alexandre Torres Porres wrote:
>>
>> Hi, I see Purr Data has this feature where it accepts spaces in lables
>> such as in canvases... this is awesome, and mostly why I use
>> cyclone/comment
>>
>> I can see we could depart from how you can lable stuff in Purr Data to
>> make a new working cross platform version of cyclone/comment that is still
>> backwards compatible.
>>
>> cheers
>>
>> 2016-11-29 2:28 GMT-02:00 Alexandre Torres Porres :
>>
>>> one question, how does canvas and other fonts for labels work in cross
>>> platforms?
>>>
>>> why not use that for comment... for now, all cyclone/comment is can be
>>> thought of just being a fancy label perhaps...
>>>
>>> I did use it a lot in my new help files that I'm working on, but only
>>> cause it'd be too much work to use canvas and labels, as it'd imply a
>>> canvas for each word as it doesn't take spaces (is only a symbol)
>>>
>>> I was even thinking of ditching it when, it stopped working on vanilla
>>> 0.47 - yeah, that's another thing, a fix needs to be made to vanilla for
>>> old versions of comment (0.2 and below to work) - but then I realized it
>>> could be really useful. I was also hoping to add properties windows to make
>>> it more convenient.
>>>
>>> anyway, the question is, why labels and stuff simply work?
>>>
>>> cheers
>>>
>>>
>>> 2016-11-28 21:45 GMT-02:00 Jonathan Wilkes :
>>>



 Another reason for putting it off is that I still haven't figured out a
 sane approach
 to handling arbitrary fonts in a diagram where everything is absolutely
 positioned.
 In fact I only have a minimally-workable approach to handling a single,
 mono-
 spaced font across platforms.  For example, there was a change
 somewhere in
 the Gnu/Linux font-stack (relatively) recently that renders fonts (or
 at least
 DejaVu Sans Mono) noticeably wider than before.  So Windows, OSX, and
 old Gnu/Linux would render a particular line of text sized at "12px"
 within less
 than a single pixel of each other.  The new Gnu/Linux font stack (seen
 in Ubuntu
 16.04 and some recent Arch) rendered the same text about 7 pixels wider.

 Worse, the newer Gnu/Linux font stack quantizes the "px" sizes such
 that the
 next smallest size is noticeably smaller.  So in Ubuntu 16.04 I have to
 compromise
 by keeping the object box the same size and having some extra padding
 at the
 end-- otherwise users of that OS could end up tightly spacing their
 object chains
 in ways that cause overlaps on the other platforms.

 So... I'd like to get a handle on that mess first, then handling
 arbitrary font
 families-- as in cyclone/comment-- will hopefully be easier and less
 prone
 to bugs.


 > well, it seems some of the issues are exactly what we're facing now...

 I think those issues are impossible to solve for displaying arbitrary
 fonts in
 a diagram like a Pd patch, and especially for arbitrary fonts in
 multi-line text.
 The user simply won't be able to predict whether or not there will be
 collisions
 on someone else's platform (or even if those fonts aren't available,
 which fonts
 will get chosen).

 I'm all for porting cyclone/comment for the sake of Max comp

Re: [PD] cyclone comment and cross platform (was Re: Purr Data rc1)

[Alexandre Torres Porres]

but how about getting that functionality as an external.

One thing is opening a vanilla GUI with spaces in the lable and trying to
open that in Vanilla, another would be to have it an external GUI object
with such functionality (such as cyclone/comment) and load it anywhere.

I'm not really aware of the existing issues in cyclone/comment, and we
haven't touched it yet, but they do not behave well in cross platforms.

My insight was that maybe we could use the code from purr-data, but as I
write this now, I realize how purr-data has this completely different GUI
front end, that's completely different to what's in Pd, so I may have been
way off...

2016-12-02 22:41 GMT-02:00 Ivica Ico Bukvic :

> This has been around for some time in pd-l2ork and by extension in
> Purr-Data, but as Liam recently pointed out on the l2ork-dev list, it can
> also break patches on vanilla where spaces (including escaped ones) in the
> .pd file get misinterpreted by the vanilla parser. Liam suggested changing
> those to ASCII 255 which is some other sort of a space... Something to be
> investigated further down the road. Of course, an alternative would be that
> vanilla ports the same space parsing method from pd-l2ork/purr-data.
>
> Best,
>
> Ico
>
> On 12/2/2016 1:10 PM, Alexandre Torres Porres wrote:
>
> Hi, I see Purr Data has this feature where it accepts spaces in lables
> such as in canvases... this is awesome, and mostly why I use
> cyclone/comment
>
> I can see we could depart from how you can lable stuff in Purr Data to
> make a new working cross platform version of cyclone/comment that is still
> backwards compatible.
>
> cheers
>
> 2016-11-29 2:28 GMT-02:00 Alexandre Torres Porres :
>
>> one question, how does canvas and other fonts for labels work in cross
>> platforms?
>>
>> why not use that for comment... for now, all cyclone/comment is can be
>> thought of just being a fancy label perhaps...
>>
>> I did use it a lot in my new help files that I'm working on, but only
>> cause it'd be too much work to use canvas and labels, as it'd imply a
>> canvas for each word as it doesn't take spaces (is only a symbol)
>>
>> I was even thinking of ditching it when, it stopped working on vanilla
>> 0.47 - yeah, that's another thing, a fix needs to be made to vanilla for
>> old versions of comment (0.2 and below to work) - but then I realized it
>> could be really useful. I was also hoping to add properties windows to make
>> it more convenient.
>>
>> anyway, the question is, why labels and stuff simply work?
>>
>> cheers
>>
>>
>> 2016-11-28 21:45 GMT-02:00 Jonathan Wilkes :
>>
>>>
>>>
>>>
>>> Another reason for putting it off is that I still haven't figured out a
>>> sane approach
>>> to handling arbitrary fonts in a diagram where everything is absolutely
>>> positioned.
>>> In fact I only have a minimally-workable approach to handling a single,
>>> mono-
>>> spaced font across platforms.  For example, there was a change somewhere
>>> in
>>> the Gnu/Linux font-stack (relatively) recently that renders fonts (or at
>>> least
>>> DejaVu Sans Mono) noticeably wider than before.  So Windows, OSX, and
>>> old Gnu/Linux would render a particular line of text sized at "12px"
>>> within less
>>> than a single pixel of each other.  The new Gnu/Linux font stack (seen
>>> in Ubuntu
>>> 16.04 and some recent Arch) rendered the same text about 7 pixels wider.
>>>
>>> Worse, the newer Gnu/Linux font stack quantizes the "px" sizes such that
>>> the
>>> next smallest size is noticeably smaller.  So in Ubuntu 16.04 I have to
>>> compromise
>>> by keeping the object box the same size and having some extra padding at
>>> the
>>> end-- otherwise users of that OS could end up tightly spacing their
>>> object chains
>>> in ways that cause overlaps on the other platforms.
>>>
>>> So... I'd like to get a handle on that mess first, then handling
>>> arbitrary font
>>> families-- as in cyclone/comment-- will hopefully be easier and less
>>> prone
>>> to bugs.
>>>
>>>
>>> > well, it seems some of the issues are exactly what we're facing now...
>>>
>>> I think those issues are impossible to solve for displaying arbitrary
>>> fonts in
>>> a diagram like a Pd patch, and especially for arbitrary fonts in
>>> multi-line text.
>>> The user simply won't be able to predict whether or not there will be
>>> collisions
>>> on someone else's platform (or even if those fonts aren't available,
>>> which fonts
>>> will get chosen).
>>>
>>> I'm all for porting cyclone/comment for the sake of Max compatibility.
>>> But I'd
>>> strongly advise against using cyclone/comment in any patch that's
>>> supposed to
>>> be used cross-platform (aside from its own help patch, of course).
>>>
>>> -Jonathan
>>>
>>> > cheers
>>>
>>>
>>>
>>
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management -> https://lists.puredata.info/li
>> stinfo/pd-list
>>
>>
>
>
> ___pd-l...@lists

Re: [PD] cyclone comment and cross platform (was Re: Purr Data rc1)

[Ivica Ico Bukvic]

This has been around for some time in pd-l2ork and by extension in 
Purr-Data, but as Liam recently pointed out on the l2ork-dev list, it 
can also break patches on vanilla where spaces (including escaped ones) 
in the .pd file get misinterpreted by the vanilla parser. Liam suggested 
changing those to ASCII 255 which is some other sort of a space... 
Something to be investigated further down the road. Of course, an 
alternative would be that vanilla ports the same space parsing method 
from pd-l2ork/purr-data.


Best,

Ico


On 12/2/2016 1:10 PM, Alexandre Torres Porres wrote:
Hi, I see Purr Data has this feature where it accepts spaces in lables 
such as in canvases... this is awesome, and mostly why I use 
cyclone/comment


I can see we could depart from how you can lable stuff in Purr Data to 
make a new working cross platform version of cyclone/comment that is 
still backwards compatible.


cheers

2016-11-29 2:28 GMT-02:00 Alexandre Torres Porres >:


one question, how does canvas and other fonts for labels work in
cross platforms?

why not use that for comment... for now, all cyclone/comment is
can be thought of just being a fancy label perhaps...

I did use it a lot in my new help files that I'm working on, but
only cause it'd be too much work to use canvas and labels, as it'd
imply a canvas for each word as it doesn't take spaces (is only a
symbol)

I was even thinking of ditching it when, it stopped working on
vanilla 0.47 - yeah, that's another thing, a fix needs to be made
to vanilla for old versions of comment (0.2 and below to work) -
but then I realized it could be really useful. I was also hoping
to add properties windows to make it more convenient.

anyway, the question is, why labels and stuff simply work?

cheers


2016-11-28 21:45 GMT-02:00 Jonathan Wilkes mailto:jancs...@yahoo.com>>:



Another reason for putting it off is that I still haven't
figured out a sane approach
to handling arbitrary fonts in a diagram where everything
is absolutely positioned.
In fact I only have a minimally-workable approach to
handling a single, mono-
spaced font across platforms. For example, there was a
change somewhere in
the Gnu/Linux font-stack (relatively) recently that
renders fonts (or at least
DejaVu Sans Mono) noticeably wider than before.  So
Windows, OSX, and
old Gnu/Linux would render a particular line of text sized
at "12px" within less
than a single pixel of each other.  The new Gnu/Linux font
stack (seen in Ubuntu
16.04 and some recent Arch) rendered the same text about 7
pixels wider.

Worse, the newer Gnu/Linux font stack quantizes the "px"
sizes such that the
next smallest size is noticeably smaller.  So in Ubuntu
16.04 I have to compromise
by keeping the object box the same size and having some
extra padding at the
end-- otherwise users of that OS could end up tightly
spacing their object chains
in ways that cause overlaps on the other platforms.

So... I'd like to get a handle on that mess first, then
handling arbitrary font
families-- as in cyclone/comment-- will hopefully be
easier and less prone
to bugs.


> well, it seems some of the issues are exactly what we're
facing now...

I think those issues are impossible to solve for displaying
arbitrary fonts in
a diagram like a Pd patch, and especially for arbitrary fonts
in multi-line text.
The user simply won't be able to predict whether or not there
will be collisions
on someone else's platform (or even if those fonts aren't
available, which fonts
will get chosen).

I'm all for porting cyclone/comment for the sake of Max
compatibility.  But I'd
strongly advise against using cyclone/comment in any patch
that's supposed to
be used cross-platform (aside from its own help patch, of course).

-Jonathan

> cheers




___
Pd-list@lists.iem.at  mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list





___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] cyclone comment and cross platform (was Re: Purr Data rc1)

[Alexandre Torres Porres]

Hi, I see Purr Data has this feature where it accepts spaces in lables such
as in canvases... this is awesome, and mostly why I use cyclone/comment

I can see we could depart from how you can lable stuff in Purr Data to make
a new working cross platform version of cyclone/comment that is still
backwards compatible.

cheers

2016-11-29 2:28 GMT-02:00 Alexandre Torres Porres :

> one question, how does canvas and other fonts for labels work in cross
> platforms?
>
> why not use that for comment... for now, all cyclone/comment is can be
> thought of just being a fancy label perhaps...
>
> I did use it a lot in my new help files that I'm working on, but only
> cause it'd be too much work to use canvas and labels, as it'd imply a
> canvas for each word as it doesn't take spaces (is only a symbol)
>
> I was even thinking of ditching it when, it stopped working on vanilla
> 0.47 - yeah, that's another thing, a fix needs to be made to vanilla for
> old versions of comment (0.2 and below to work) - but then I realized it
> could be really useful. I was also hoping to add properties windows to make
> it more convenient.
>
> anyway, the question is, why labels and stuff simply work?
>
> cheers
>
>
> 2016-11-28 21:45 GMT-02:00 Jonathan Wilkes :
>
>>
>>
>>
>> Another reason for putting it off is that I still haven't figured out a
>> sane approach
>> to handling arbitrary fonts in a diagram where everything is absolutely
>> positioned.
>> In fact I only have a minimally-workable approach to handling a single,
>> mono-
>> spaced font across platforms.  For example, there was a change somewhere
>> in
>> the Gnu/Linux font-stack (relatively) recently that renders fonts (or at
>> least
>> DejaVu Sans Mono) noticeably wider than before.  So Windows, OSX, and
>> old Gnu/Linux would render a particular line of text sized at "12px"
>> within less
>> than a single pixel of each other.  The new Gnu/Linux font stack (seen in
>> Ubuntu
>> 16.04 and some recent Arch) rendered the same text about 7 pixels wider.
>>
>> Worse, the newer Gnu/Linux font stack quantizes the "px" sizes such that
>> the
>> next smallest size is noticeably smaller.  So in Ubuntu 16.04 I have to
>> compromise
>> by keeping the object box the same size and having some extra padding at
>> the
>> end-- otherwise users of that OS could end up tightly spacing their
>> object chains
>> in ways that cause overlaps on the other platforms.
>>
>> So... I'd like to get a handle on that mess first, then handling
>> arbitrary font
>> families-- as in cyclone/comment-- will hopefully be easier and less
>> prone
>> to bugs.
>>
>>
>> > well, it seems some of the issues are exactly what we're facing now...
>>
>> I think those issues are impossible to solve for displaying arbitrary
>> fonts in
>> a diagram like a Pd patch, and especially for arbitrary fonts in
>> multi-line text.
>> The user simply won't be able to predict whether or not there will be
>> collisions
>> on someone else's platform (or even if those fonts aren't available,
>> which fonts
>> will get chosen).
>>
>> I'm all for porting cyclone/comment for the sake of Max compatibility.
>> But I'd
>> strongly advise against using cyclone/comment in any patch that's
>> supposed to
>> be used cross-platform (aside from its own help patch, of course).
>>
>> -Jonathan
>>
>> > cheers
>>
>>
>>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] cyclone comment and cross platform (was Re: Purr Data rc1)

[Alexandre Torres Porres]

one question, how does canvas and other fonts for labels work in cross
platforms?

why not use that for comment... for now, all cyclone/comment is can be
thought of just being a fancy label perhaps...

I did use it a lot in my new help files that I'm working on, but only cause
it'd be too much work to use canvas and labels, as it'd imply a canvas for
each word as it doesn't take spaces (is only a symbol)

I was even thinking of ditching it when, it stopped working on vanilla 0.47
- yeah, that's another thing, a fix needs to be made to vanilla for old
versions of comment (0.2 and below to work) - but then I realized it could
be really useful. I was also hoping to add properties windows to make it
more convenient.

anyway, the question is, why labels and stuff simply work?

cheers


2016-11-28 21:45 GMT-02:00 Jonathan Wilkes :

>
>
>
> Another reason for putting it off is that I still haven't figured out a
> sane approach
> to handling arbitrary fonts in a diagram where everything is absolutely
> positioned.
> In fact I only have a minimally-workable approach to handling a single,
> mono-
> spaced font across platforms.  For example, there was a change somewhere
> in
> the Gnu/Linux font-stack (relatively) recently that renders fonts (or at
> least
> DejaVu Sans Mono) noticeably wider than before.  So Windows, OSX, and
> old Gnu/Linux would render a particular line of text sized at "12px"
> within less
> than a single pixel of each other.  The new Gnu/Linux font stack (seen in
> Ubuntu
> 16.04 and some recent Arch) rendered the same text about 7 pixels wider.
>
> Worse, the newer Gnu/Linux font stack quantizes the "px" sizes such that
> the
> next smallest size is noticeably smaller.  So in Ubuntu 16.04 I have to
> compromise
> by keeping the object box the same size and having some extra padding at
> the
> end-- otherwise users of that OS could end up tightly spacing their object
> chains
> in ways that cause overlaps on the other platforms.
>
> So... I'd like to get a handle on that mess first, then handling arbitrary
> font
> families-- as in cyclone/comment-- will hopefully be easier and less prone
> to bugs.
>
>
> > well, it seems some of the issues are exactly what we're facing now...
>
> I think those issues are impossible to solve for displaying arbitrary
> fonts in
> a diagram like a Pd patch, and especially for arbitrary fonts in
> multi-line text.
> The user simply won't be able to predict whether or not there will be
> collisions
> on someone else's platform (or even if those fonts aren't available, which
> fonts
> will get chosen).
>
> I'm all for porting cyclone/comment for the sake of Max compatibility.
> But I'd
> strongly advise against using cyclone/comment in any patch that's supposed
> to
> be used cross-platform (aside from its own help patch, of course).
>
> -Jonathan
>
> > cheers
>
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list