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

Alexandre Torres Porres porres at gmail.com
Sat Dec 3 02:06:05 CET 2016


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 <ico at vt.edu>:

> 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 <porres at 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 <jancsika at 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 at lists.iem.at mailing list
>> UNSUBSCRIBE and account-management -> https://lists.puredata.info/li
>> stinfo/pd-list
>>
>>
>
>
> _______________________________________________Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
>
>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20161202/5b30a8ca/attachment-0001.html>


More information about the Pd-list mailing list