[L2Ork-dev] Inconsistent window sizes across different OSs

[Ivica Bukvic]

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/20200813/cae3654a/attachment.html>