[L2Ork-dev] Excalibur Bug
Jonathan Wilkes
jon.w.wilkes at gmail.com
Sun Jun 14 15:51:37 EDT 2020
On Sun, Jun 14, 2020 at 2:59 PM Ivica Bukvic <ico at vt.edu> wrote:
>
> Why not simply subtract the menu at height from the document height?
It's probably different on Windows and Linux, non-existent on OSX, possibly
different on different Linux distros.
Also it appears to be a race-- so it's possible a big beefy setup could win the
race and now they can't click in the bottom 15 pixels of the patch.
-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 Sun, Jun 14, 2020, 14:50 Jonathan Wilkes <jon.w.wilkes at gmail.com> wrote:
>>
>> It appears there's a race condition with the nw.js Menu menubar
>> rendering and nw.js actually
>> updating the DOM.
>>
>> This means we have to rely on a timeout to get accurate window height
>> report, and for
>> some heavy patches this won't be enough.
>>
>> That's why you get the extra height at the bottom of the window for
>> some help patches.
>>
>> I just filed a bug on nw.js google group. Hopefully Roger can fix it
>> our at least give us a
>> callback when it's done rendering.
>>
>> -Jonathan
>>
>> On Sun, Jun 14, 2020 at 1:09 AM Jonathan Wilkes <jon.w.wilkes at gmail.com> wrote:
>> >
>> > Excalibur successfully retrieved.
>> >
>> > And the secret CSS incantation is...
>> >
>> > float: left;
>> >
>> > Initial implementation below. I've got the scrollbars hard-coded atm,
>> > but they can easily be measured at startup.
>> >
>> > Also-- I added some overflow offsets so that if a scrollbar is needed,
>> > then there is some padding below the object.
>> > That always drives me crazy when I scroll down and the bottom of the
>> > object is flush with the scrollbar or the
>> > bottom of the window.
>> >
>> > diff --git a/pd/nw/pdgui.js b/pd/nw/pdgui.js
>> > index a24a6f71..7ff9fdab 100644
>> > --- a/pd/nw/pdgui.js
>> > +++ b/pd/nw/pdgui.js
>> > @@ -5774,8 +5774,8 @@ function canvas_params(nw_win)
>> > // the scrollbars from appearing. Here, we just subtract 4 from both
>> > // of them. This could lead to some problems with event handlers but I
>> > // haven't had a problem with it yet.
>> > - min_width = nw_win.window.innerWidth - 4;
>> > - min_height = nw_win.window.innerHeight - 4;
>> > + min_width = nw_win.window.innerWidth;
>> > + min_height = nw_win.window.innerHeight;
>> > // Since we don't do any transformations on the patchsvg,
>> > // let's try just using ints for the height/width/viewBox
>> > // to keep things simple.
>> > @@ -5799,24 +5799,82 @@ function do_getscroll(cid) {
>> > // errors wrt the rendering context disappearing.
>> > gui(cid).get_nw_window(function(nw_win) {
>> > var svg_elem = nw_win.window.document.getElementById("patchsvg");
>> > + var overflow_x,
>> > + overflow_y,
>> > + scrollbar_x_would_overlap_content,
>> > + scrollbar_y_would_overlap_content,
>> > + x_offset = 0,
>> > + y_offset = 0;
>> > var { x: x, y: y, w: width, h: height,
>> > mw: min_width, mh: min_height } = canvas_params(nw_win);
>> > +
>> > + // Let's get to it. First we want to know if our SVG has any child
>> > + // elements overflowing our viewport
>> > +
>> > + overflow_x = width > min_width;
>> > + overflow_y = height > min_height;
>> > +
>> > + // Now let's see if drawing a scrollbar would hide objects at the
>> > + // extremities of the viewport
>> > +
>> > + scrollbar_x_would_overlap_content = height > min_height - 15;
>> > + scrollbar_y_would_overlap_content = width > min_width - 15;
>> > +
>> > + if (overflow_x) {
>> > + // We have a horizontal scrollbar.
>> > + if (scrollbar_x_would_overlap_content) {
>> > + // If there are objects underneath the horizontal scrollbar,
>> > + // we want to make sure that the height of our SVG covers
>> > + // the entire viewport. That way the browser will give us
>> > + // a vertical scrollbar in order to view those objects
>> > + y_offset = 0;
>> > + } else {
>> > + // We don't need a vertical scrollbar after all. So make the
>> > + // canvas 15 pixels shorter so the vertical scrollbar doesn't
>> > + // show up
>> > + y_offset = -15;
>> > + }
>> > + }
>> > +
>> > + if (overflow_y) {
>> > + // vert scrollbar
>> > + if (scrollbar_y_would_overlap_content) {
>> > + // same as above
>> > + x_offset = 0;
>> > + } else {
>> > + x_offset = -15;
>> > + }
>> > + }
>> > +
>> > + // Finally, if we overflow the viewport, let's add some padding so
>> > + // that objects at the edge aren't flush against the scrollbar. At
>> > + // least I find that a real pain at the bottom of the window when
>> > + // trying to add more objects
>> > +
>> > + if (overflow_x) {
>> > + x_offset = 5;
>> > + }
>> > +
>> > + if (overflow_y) {
>> > + y_offset = 5;
>> > + }
>> > +
>> > if (width < min_width) {
>> > width = min_width;
>> > }
>> > - // If the svg extends beyond the viewport, it might be nice to pad
>> > - // both the height/width and the x/y coords so that there is extra
>> > - // room for making connections and manipulating the objects. As it
>> > - // stands objects will be flush with the scrollbars and window
>> > - // edges.
>> > + width += x_offset;
>> > +
>> > if (height < min_height) {
>> > - height = min_height;
>> > + height = min_height
>> > }
>> > + height += y_offset;
>> > +
>> > configure_item(svg_elem, {
>> > viewBox: [x, y, width, height].join(" "),
>> > width: width,
>> > height: height
>> > });
>> > +
>> > });
>> > }
>> _______________________________________________
>> L2Ork-dev mailing list
>> L2Ork-dev at disis.music.vt.edu
>> https://disis.music.vt.edu/listinfo/l2ork-dev
>
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> https://disis.music.vt.edu/listinfo/l2ork-dev
More information about the L2Ork-dev
mailing list