[L2Ork-dev] Inconsistent window sizes across different OSs

Jonathan Wilkes jon.w.wilkes at gmail.com
Wed Aug 12 17:20:57 EDT 2020

On Wed, Aug 12, 2020 at 4:56 PM Ivica Ico Bukvic <ico at vt.edu> wrote:
> So, now that the scrollbar business has been resolved (see pending merge
> request 485), it appears that the following is the issue across the
> three most prominent OSs (Linux, OSX, Windows):
> 1) OSX when opening a patch saved on Linux adds 25 pixels to the bottom
> of the window of the patch

Just to clarify:

1. I save a patch on OSX that has a height of 300 pixels
2. When I re-open the patch *on OSX*, what is the height of the patch window?


> 2) Linux when opening a patch saved on OSX subtracts 25 pixels to the
> bottom of the window of the patch
> 3) Windows when opening a patch saved on OSX adds 16 pixels to the right
> and subtracts 18 from the bottom
> 4) OSX when opening a patch saved on Windows subtracts 16 pixels to the
> right and adds 18 to the bottom
> There are, of course, ways to scale the svg area to make a relatively
> quick fix to this issue. This, however, results in a fuzzy graphics and
> text and is therefore suboptimal.
> To further exacerbate the issue, pre-0.46+ nw.js dubiously adds 4 more
> pixels at the bottom of the canvas regardless of the OS. This is true of
> older pre-scrollbar-redesign purr-data versions, suggesting this is an
> nw.js bug. I propose we ignore this one for the time being, in
> anticipation of the future migration to a newer version of nw.js which
> will solve this issue (this migration, however, is pending until we
> figure out what is causing a significant slowdown when opening more
> complex patches).
> So, instead of doing a quick'n'fuzzy svg scaling solution, one thing we
> could consider potentially doing is the following:
> 1) when saving a patch, add at the beginning of the patch OS on which it
> was saved, and then, based on which OS we are and where the patch was
> saved, compensate for the window size accordingly
> Alternately, we could
> 2) do the svg scaling and accept the fuzziness as par for the course (in
> which case we may want to pick the "benchmark" platform which will not
> be fuzzy)--I really do not like this option
> And of course, as always we could
> 3) do nothing
> Thoughts?
> Best,
> Ico
> --
> Ivica Ico Bukvic, D.M.A.
> Director, Creativity + Innovation
> Director, Human Centered Design iPhD
> Institute for Creativity, Arts, and Technology
> Virginia Tech
> Creative Technologies in Music
> School of Performing Arts – 0141
> Blacksburg, VA 24061
> (540) 231-6139
> ico at vt.edu
> www.icat.vt.edu
> www.performingarts.vt.edu
> l2ork.icat.vt.edu
> ico.bukvic.net

More information about the L2Ork-dev mailing list