[L2Ork-dev] Inconsistent window sizes across different OSs

[Ivica Bukvic]

On Wed, Aug 12, 2020, 17:21 Jonathan Wilkes <jon.w.wilkes at gmail.com> wrote:

> 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?
>
> -Jonathan
>

The same. This is true on all 3 OSs. Patch saved on the same OS will remain
the same size no matter what, as long as opened on the same OS.



> >
> > 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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20200812/6c4354b6/attachment.html>