[L2Ork-dev] Inconsistent window sizes across different OSs

Jonathan Wilkes jon.w.wilkes at gmail.com
Wed Aug 12 18:17:47 EDT 2020


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


More information about the L2Ork-dev mailing list