[L2Ork-dev] Excalibur Bug
Ivica Bukvic
ico at vt.edu
Sat Jun 13 15:54:22 EDT 2020
Best way to summarize it is play with the bottom left corner and see what
happens when you are right on the edge of a shape that is rightmost and
bottom-most on the canvas. Is it flush with the edge? What happens when you
decrease width by one and what happens when you decrease height by one and
what happens when you do both? Finally, what happens when you return to the
outer bottom-right edge of a shape. Ideally you should have no margin
around the edges, and scrollbars should not be visible, so that patches can
be designed such that there's no margin around them. The scrollbar should
also promptly appear and disappear without unnecessarily invoking the other
scrollbarunless it is necessary to do so. Given that the default scrollbars
take away from the body of the document this is a bit fuzzier than what I'm
implementing where the scroll bar itself is a shape inside the document.
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 Sat, Jun 13, 2020, 14:03 Jonathan Wilkes <jon.w.wilkes at gmail.com> wrote:
> On Sat, Jun 13, 2020 at 9:15 AM Ivica Bukvic <ico at vt.edu> wrote:
> >
> > Yes, having body match the patchsvg w and h is what I shared with you in
> our conference call as part of the new scrollbars implementation. Check out
> my latest 3 commits to my branch and you will be able to test the new
> implementation (I will send you a merge request once I fix the last known
> bug). The only bug now remaining is that it appears sometimes when the file
> is saved with the new nw.js 0.46.2 it is for some reason saving bigger
> canvas than it should be. The new nw.js also has a tighter bbox which
> requires fewer hacks by adding and subtracting from the bbox size to
> prevent unnecessary toggling of scrollbars which is why I prefer it over
> the currently used versions.
> >
> > As for the objects which have handles I noted that issue in my commits
> and have added one getscroll update after deselecting objects in pdgui.js,
> which fixes that problem. The other consideration is that from the UI
> design perspective no handles should ideally exist outside of the objects
> themselves, as is the case with 1.x version objects (labels in both 1.x and
> be 2.x are still a bit tricky) and once we have that this update will
> become superfluous.
> >
> > Lastly, to test your implementation try having the window size such that
> the bottom right edge is right next to an edge of an object and changing
> the size by a single pixel to see if you start having a fluttering effect
> because of the scrollbar appearing and suddenly window becoming
> significantly smaller and then spawning the other scrollbar as a result.
> Then try reverting back and seeing whether the scrollbars disappear, as
> they should.
>
> I'd like to test this but I'm not sure I understand it. Can you give
> me more detailed instructions on this fluttering
> effect?
>
> -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 Sat, Jun 13, 2020, 01:11 Jonathan Wilkes <jon.w.wilkes at gmail.com>
> wrote:
> >>
> >> Okay, I've got an initial non-quirksmode fix:
> >>
> >> diff --git a/pd/nw/pdgui.js b/pd/nw/pdgui.js
> >> index a24a6f71..dc631963 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.
> >> @@ -5803,6 +5803,9 @@ function do_getscroll(cid) {
> >> mw: min_width, mh: min_height } = canvas_params(nw_win);
> >> if (width < min_width) {
> >> width = min_width;
> >> + nw_win.window.document.body.style.overflowX = "hidden";
> >> + } else {
> >> + nw_win.window.document.body.style.overflowX = "visible";
> >> }
> >> // 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
> >> @@ -5811,6 +5814,9 @@ function do_getscroll(cid) {
> >> // edges.
> >> if (height < min_height) {
> >> height = min_height;
> >> + nw_win.window.document.body.style.overflowY = "hidden";
> >> + } else{
> >> + nw_win.window.document.body.style.overflowY = "visible";
> >> }
> >> configure_item(svg_elem, {
> >> viewBox: [x, y, width, height].join(" "),
> >>
> >>
> >> So opening bang-help.pd I get no scrollbars under Linux. Works in
> >> different zoom levels, too.
> >>
> >> One unrelated bug I just noticed-- if you select a [cnv] with other
> >> multiple objects, the little
> >> anchor square appears for resizing the [cnv]. That square is in the
> >> bottom right-hand corner
> >> of the [cnv] so it will cause the bbox for the SVG to be bigger than
> >> it should when you have,
> >> say, the footer of bang-help.pd selected.
> >>
> >> -Jonathan
> >>
> >> On Sat, Jun 13, 2020 at 12:49 AM Jonathan Wilkes <
> jon.w.wilkes at gmail.com> wrote:
> >> >
> >> > Getting closer--
> >> >
> >> > You should get perfect, predictable scrollbar behavior by removing the
> >> > following line from pd_canvas.js:
> >> >
> >> > <!DOCTYPE html>
> >> >
> >> > Of course you'd have to also remove all the kludges currently in the
> >> > resizing algo.
> >> >
> >> > By removing this line, all browsers will render the page in "quirks
> >> > mode." Quirks mode uses some
> >> > old compatibility rendering algos that pre-date HTML5. Older web pages
> >> > don't have the !DOCTYPE
> >> > directive and therefore will be displayed properly.
> >> >
> >> > Now the problem is this: given the various quirksmode features, I have
> >> > no idea which of them is
> >> > responsible for fixing this issue. And while it must be possible that
> >> > non-quirks mode can achieve this
> >> > same obvious, unsurprising behavior I don't know what incantation of
> >> > CSS soup is required to
> >> > get it.
> >> >
> >> > Does anyone know an HTML5 guru who can recite for me the correct CSS
> >> > incantation here?
> >> >
> >> > If not I may have just figured out a workaround...
> >> >
> >> > -Jonathan
> >> _______________________________________________
> >> 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/20200613/2a399b88/attachment-0001.html>
More information about the L2Ork-dev
mailing list