<div dir="ltr">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.<div><br></div><div>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.<br><div><br></div><div>Best,</div><div><br></div><div>Ico<br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><pre cols="72"><pre cols="72">-- <br>Ivica Ico Bukvic, D.M.A.<br>Director, Creativity + Innovation
Director, Human-Centered Design iPhD
Institute for Creativity, Arts, and Technology
</pre><pre cols="72">Virginia Tech<br>Creative Technologies in Music<br>School of Performing Arts – 0141<br>Blacksburg, VA 24061<br>(540) 231-6139<br><a href="mailto:ico@vt.edu" target="_blank">ico@vt.edu</a><br><br><a href="http://ci.icat.vt.edu" target="_blank">ci.icat.vt.edu</a>
<a href="http://hcd.icat.vt.edu/" target="_blank">hcd.icat.vt.edu</a>
<a href="http://www.icat.vt.edu" target="_blank">www.icat.vt.edu</a><br><a href="http://www.performingarts.vt.edu" target="_blank">www.performingarts.vt.edu</a><br><a href="http://l2ork.icat.vt.edu" target="_blank">l2ork.icat.vt.edu</a><br><a href="http://ico.bukvic.net" target="_blank">ico.bukvic.net<br></a></pre></pre></div></div></div></div></div></div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 13, 2020 at 12:21 AM Ivica Bukvic <<a href="mailto:ico@vt.edu">ico@vt.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">I think it is both.<br><br><div>Best,<br><br>Ico<br><br>-- <br>Ivica Ico Bukvic, D.M.A.<br>Director, Creativity + Innovation<br>Institute for Creativity, Arts, and Technology<br><br>Virginia Tech<br>Creative Technologies in Music<br>School of Performing Arts – 0141<br>Blacksburg, VA 24061<br>(540) 231-6139<br><a href="mailto:ico@vt.edu" target="_blank">ico@vt.edu</a><br><br><a href="http://www.icat.vt.edu" target="_blank">www.icat.vt.edu</a><br><a href="http://www.performingarts.vt.edu" target="_blank">www.performingarts.vt.edu</a><br><a href="http://l2ork.icat.vt.edu" target="_blank">l2ork.icat.vt.edu</a><br><a href="http://ico.bukvic.net" target="_blank">ico.bukvic.net</a></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 12, 2020, 23:12 Jonathan Wilkes <<a href="mailto:jon.w.wilkes@gmail.com" target="_blank">jon.w.wilkes@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Aug 12, 2020 at 7:51 PM Ivica Bukvic <<a href="mailto:ico@vt.edu" rel="noreferrer" target="_blank">ico@vt.edu</a>> wrote:<br>
><br>
> 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...<br>
<br>
Just to be clear-- you're talking about measuring the viewport, *not*<br>
the size of the window in the OS's window manager,<br>
right?<br>
<br>
-Jonathan<br>
<br>
><br>
> Best,<br>
><br>
> Ico<br>
><br>
> --<br>
> Ivica Ico Bukvic, D.M.A.<br>
> Director, Creativity + Innovation<br>
> Institute for Creativity, Arts, and Technology<br>
><br>
> Virginia Tech<br>
> Creative Technologies in Music<br>
> School of Performing Arts – 0141<br>
> Blacksburg, VA 24061<br>
> (540) 231-6139<br>
> <a href="mailto:ico@vt.edu" rel="noreferrer" target="_blank">ico@vt.edu</a><br>
><br>
> <a href="http://www.icat.vt.edu" rel="noreferrer noreferrer" target="_blank">www.icat.vt.edu</a><br>
> <a href="http://www.performingarts.vt.edu" rel="noreferrer noreferrer" target="_blank">www.performingarts.vt.edu</a><br>
> <a href="http://l2ork.icat.vt.edu" rel="noreferrer noreferrer" target="_blank">l2ork.icat.vt.edu</a><br>
> <a href="http://ico.bukvic.net" rel="noreferrer noreferrer" target="_blank">ico.bukvic.net</a><br>
><br>
> On Wed, Aug 12, 2020, 18:18 Jonathan Wilkes <<a href="mailto:jon.w.wilkes@gmail.com" rel="noreferrer" target="_blank">jon.w.wilkes@gmail.com</a>> wrote:<br>
>><br>
>> Well, GLIST_DEFCANVASHEIGHT is 300.<br>
>><br>
>> So for a patch created by "File->New", the svg viewport area should be 300.<br>
>> But it<br>
>> Looks to me like Linux includes the window menubar in that<br>
>> calculation. because a 300-pixel high cnv will not fit<br>
>> in that default patch size.<br>
>><br>
>> Just curious-- what does Pd Vanilla do here?<br>
>><br>
>> In any case, Linux (and probably Windows) have a display bug. They<br>
>> need to size the window such that a default<br>
>> new patch has 300 pixels of vertical *viewable* area. Any other goal<br>
>> will break compatibility across all platforms.<br>
>><br>
>> -Jonathan<br>
>><br>
>><br>
>> On Wed, Aug 12, 2020 at 5:38 PM Ivica Bukvic <<a href="mailto:ico@vt.edu" rel="noreferrer" target="_blank">ico@vt.edu</a>> wrote:<br>
>> ><br>
>> ><br>
>> ><br>
>> > On Wed, Aug 12, 2020, 17:21 Jonathan Wilkes <<a href="mailto:jon.w.wilkes@gmail.com" rel="noreferrer" target="_blank">jon.w.wilkes@gmail.com</a>> wrote:<br>
>> >><br>
>> >> On Wed, Aug 12, 2020 at 4:56 PM Ivica Ico Bukvic <<a href="mailto:ico@vt.edu" rel="noreferrer" target="_blank">ico@vt.edu</a>> wrote:<br>
>> >> ><br>
>> >> > So, now that the scrollbar business has been resolved (see pending merge<br>
>> >> > request 485), it appears that the following is the issue across the<br>
>> >> > three most prominent OSs (Linux, OSX, Windows):<br>
>> >> ><br>
>> >> > 1) OSX when opening a patch saved on Linux adds 25 pixels to the bottom<br>
>> >> > of the window of the patch<br>
>> >><br>
>> >> Just to clarify:<br>
>> >><br>
>> >> 1. I save a patch on OSX that has a height of 300 pixels<br>
>> >> 2. When I re-open the patch *on OSX*, what is the height of the patch window?<br>
>> >><br>
>> >> -Jonathan<br>
>> ><br>
>> ><br>
>> > 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.<br>
>> ><br>
>> ><br>
>> >><br>
>> >> ><br>
>> >> > 2) Linux when opening a patch saved on OSX subtracts 25 pixels to the<br>
>> >> > bottom of the window of the patch<br>
>> >> ><br>
>> >> > 3) Windows when opening a patch saved on OSX adds 16 pixels to the right<br>
>> >> > and subtracts 18 from the bottom<br>
>> >> ><br>
>> >> > 4) OSX when opening a patch saved on Windows subtracts 16 pixels to the<br>
>> >> > right and adds 18 to the bottom<br>
>> >> ><br>
>> >> > There are, of course, ways to scale the svg area to make a relatively<br>
>> >> > quick fix to this issue. This, however, results in a fuzzy graphics and<br>
>> >> > text and is therefore suboptimal.<br>
>> >> ><br>
>> >> > To further exacerbate the issue, pre-0.46+ nw.js dubiously adds 4 more<br>
>> >> > pixels at the bottom of the canvas regardless of the OS. This is true of<br>
>> >> > older pre-scrollbar-redesign purr-data versions, suggesting this is an<br>
>> >> > nw.js bug. I propose we ignore this one for the time being, in<br>
>> >> > anticipation of the future migration to a newer version of nw.js which<br>
>> >> > will solve this issue (this migration, however, is pending until we<br>
>> >> > figure out what is causing a significant slowdown when opening more<br>
>> >> > complex patches).<br>
>> >> ><br>
>> >> > So, instead of doing a quick'n'fuzzy svg scaling solution, one thing we<br>
>> >> > could consider potentially doing is the following:<br>
>> >> ><br>
>> >> > 1) when saving a patch, add at the beginning of the patch OS on which it<br>
>> >> > was saved, and then, based on which OS we are and where the patch was<br>
>> >> > saved, compensate for the window size accordingly<br>
>> >> ><br>
>> >> > Alternately, we could<br>
>> >> ><br>
>> >> > 2) do the svg scaling and accept the fuzziness as par for the course (in<br>
>> >> > which case we may want to pick the "benchmark" platform which will not<br>
>> >> > be fuzzy)--I really do not like this option<br>
>> >> ><br>
>> >> > And of course, as always we could<br>
>> >> ><br>
>> >> > 3) do nothing<br>
>> >> ><br>
>> >> > Thoughts?<br>
>> >> ><br>
>> >> > Best,<br>
>> >> ><br>
>> >> > Ico<br>
>> >> ><br>
>> >> > --<br>
>> >> > Ivica Ico Bukvic, D.M.A.<br>
>> >> > Director, Creativity + Innovation<br>
>> >> > Director, Human Centered Design iPhD<br>
>> >> > Institute for Creativity, Arts, and Technology<br>
>> >> ><br>
>> >> > Virginia Tech<br>
>> >> > Creative Technologies in Music<br>
>> >> > School of Performing Arts – 0141<br>
>> >> > Blacksburg, VA 24061<br>
>> >> > (540) 231-6139<br>
>> >> > <a href="mailto:ico@vt.edu" rel="noreferrer" target="_blank">ico@vt.edu</a><br>
>> >> ><br>
>> >> > <a href="http://www.icat.vt.edu" rel="noreferrer noreferrer" target="_blank">www.icat.vt.edu</a><br>
>> >> > <a href="http://www.performingarts.vt.edu" rel="noreferrer noreferrer" target="_blank">www.performingarts.vt.edu</a><br>
>> >> > <a href="http://l2ork.icat.vt.edu" rel="noreferrer noreferrer" target="_blank">l2ork.icat.vt.edu</a><br>
>> >> > <a href="http://ico.bukvic.net" rel="noreferrer noreferrer" target="_blank">ico.bukvic.net</a><br>
>> >> ><br>
</blockquote></div>
</blockquote></div>