[L2Ork-dev] Excalibur Bug
Ivica Bukvic
ico at vt.edu
Sun Jun 14 17:01:15 EDT 2020
True. although if we know what the menu bar will be in terms of size (which
appears to be fluctuating 0.46.2 is 25 pixels whereas 0.14.7 is 23, go
figure), we shouldn't have to worry about that race condition as long as we
assign it proper size and then do not worry about scroll bars because they
are already handled within HTML5. The next step then is to remove the NW
menu and build the entire thing in the HTML which shouldn't be too hard
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, 16:20 Jonathan Wilkes <jon.w.wilkes at gmail.com> wrote:
> On Sun, Jun 14, 2020 at 3:55 PM Ivica Bukvic <ico at vt.edu> wrote:
> >
> > One response I got on the nw group chat which is something you also
> mentioned to me once is that we should imppement as much as possible inside
> HTML5 and forgo reliance on the often buggy nw.
>
> I agree, but the buggy part of nw is it's cross-platform native window
> menus. The scrollbar behavior is part of HTML5.
>
> > The implementation of custom scrollbars I'm about to finish does exactly
> that. Not only will it look identical on all platforms but will also be
> completely oblivious to the race condition you are encountering. This will
> be even more apparent once we get rid of the node webkit menu bar which is
> been causing so many problems.
>
> For this bug it doesn't matter if we use native scrollbars or code
> them manually. If we don't know that the window height
> value we retrieve after load is correct, *and* we don't know how long
> to wait until it becomes correct, we're screwed.
>
> -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, 15:51 Jonathan Wilkes <jon.w.wilkes at gmail.com>
> wrote:
> >>
> >> 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
> >> _______________________________________________
> >> 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
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> https://disis.music.vt.edu/listinfo/l2ork-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20200614/a853a51d/attachment-0001.html>
More information about the L2Ork-dev
mailing list