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 <i...@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 <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 <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/li >> stinfo/pd-list >> >> > > > _______________________________________________pd-l...@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