[L2Ork-dev] Inconsistent window sizes across different OSs

Fri Aug 14 16:10:31 EDT 2020

Yes. To further expand, this was not the case up until now. You may recall
our conversation when I was working on Tweeter back in April when I found
the window size to be different on different OSs.

Best,

Ico

-- 
Ivica Ico Bukvic, D.M.A.
Director, Creativity + Innovation
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

On Fri, Aug 14, 2020, 14:47 Jonathan Wilkes <jon.w.wilkes at gmail.com> wrote:

> Ok.
>
> And just so I'm clear:
>
> If I write a help patch that fits snuggly into a 300-pixel high
> canvas, with your fix it will fit snuggly on all supported platforms.
>
> Is this statement correct?
>
> -Jonathan
>
> On Fri, Aug 14, 2020 at 1:22 PM Ivica Bukvic <ico at vt.edu> wrote:
> >
> > I figured it out. It is now added to the 485 merge request and finally
> fixes this issue once and hopefully for all times (pending any cross-OS
> inconsistencies in nw in the 0.46+ versions). Linux-OSX inconsistency was a
> bug, whereas Linux/OSX-Windows inconsistency is a nw quirk where on Windows
> window.innerWidth and window.innerHeight for some reason misreports values.
> This bugfix ensures everything is accurate down to the pixel.
> >
> > If you like, I can work on finishing the dialogs and then throw that
> into that merge request, as well, or I can begin working on that merge
> request separately. Lemme know.
> >
> > 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
> >
> > ci.icat.vt.edu
> > hcd.icat.vt.edu
> > www.icat.vt.edu
> > www.performingarts.vt.edu
> > l2ork.icat.vt.edu
> > ico.bukvic.net
> >
> >
> >
> > On Thu, Aug 13, 2020 at 12:21 AM Ivica Bukvic <ico at vt.edu> wrote:
> >>
> >> I think it is both.
> >>
> >> Best,
> >>
> >> Ico
> >>
> >> --
> >> Ivica Ico Bukvic, D.M.A.
> >> Director, Creativity + Innovation
> >> 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
> >>
> >> On Wed, Aug 12, 2020, 23:12 Jonathan Wilkes <jon.w.wilkes at gmail.com>
> wrote:
> >>>
> >>> On Wed, Aug 12, 2020 at 7:51 PM Ivica Bukvic <ico at vt.edu> wrote:
> >>> >
> >>> > I honestly haven't tested the default window creation and have only
> played with ones where I would put objects in the top-left and bottom-right
> corner, so that I can accurately measure what has happened to the window.
> It appears that the Mac and Linux incompatibility may be rooted in an
> erroneous addition of the window height but that still does not alleviate
> the discrepancy between Windows and the other two. the window size is
> reported accurately on both platforms yet the results are not identical and
> it is unclear to me as to why. Investigating further...
> >>>
> >>> Just to be clear-- you're talking about measuring the viewport, *not*
> >>> the size of the window in the OS's window manager,
> >>> right?
> >>>
> >>> -Jonathan
> >>>
> >>> >
> >>> > Best,
> >>> >
> >>> > Ico
> >>> >
> >>> > --
> >>> > Ivica Ico Bukvic, D.M.A.
> >>> > Director, Creativity + Innovation
> >>> > 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
> >>> >
> >>> > On Wed, Aug 12, 2020, 18:18 Jonathan Wilkes <jon.w.wilkes at gmail.com>
> wrote:
> >>> >>
> >>> >> Well, GLIST_DEFCANVASHEIGHT is 300.
> >>> >>
> >>> >> So for a patch created by "File->New", the svg viewport area should
> be 300.
> >>> >> But it
> >>> >> Looks to me like Linux includes the window menubar in that
> >>> >> calculation. because a 300-pixel high cnv will not fit
> >>> >> in that default patch size.
> >>> >>
> >>> >> Just curious-- what does Pd Vanilla do here?
> >>> >>
> >>> >> In any case, Linux (and probably Windows) have a display bug. They
> >>> >> need to size the window such that a default
> >>> >> new patch has 300 pixels of vertical *viewable* area. Any other goal
> >>> >> will break compatibility across all platforms.
> >>> >>
> >>> >> -Jonathan
> >>> >>
> >>> >>
> >>> >> On Wed, Aug 12, 2020 at 5:38 PM Ivica Bukvic <ico at vt.edu> wrote:
> >>> >> >
> >>> >> >
> >>> >> >
> >>> >> > 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/20200814/8c409de8/attachment.html>