[L2Ork-dev] Inconsistent window sizes across different OSs

Ivica Bukvic ico at vt.edu
Fri Aug 14 13:22:19 EDT 2020


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.eduhcd.icat.vt.eduwww.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/75c6aaad/attachment.html>


More information about the L2Ork-dev mailing list