[L2Ork-dev] Inconsistent window sizes across different OSs

[Ivica Bukvic]

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...

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/20200812/f67f318a/attachment-0001.html>