[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 <porres at gmail.com>:

> 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/li
>> stinfo/pd-list
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20161202/3a0a0551/attachment-0001.html>