[L2Ork-dev] New scrollbars and other commits, and next steps (was: Excalibur bug)

Ivica Bukvic ico at vt.edu
Mon Jun 15 16:46:17 EDT 2020


Thanks for your response. All this makes sense. Allow me to share a few
more thoughts inline below.

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 Mon, Jun 15, 2020, 12:27 Jonathan Wilkes <jon.w.wilkes at gmail.com> wrote:

> Responding inline:
>
> Aside from seeing underneath the scrollbar, I think my fix to the excalibur
> bug delivers most of these features. Of course it's possible your
> implementation
> does essentially the same as my fix in do_getscroll, so I'll have a look
> and
> see.
>

I think there is also a foundational question whether we wish to move to
0.46.2 which I favor.


> >
> > Next, we may want to consider working on the following:
> > 1) This one will benefit from Jonathan's help: reworking how the
> > listeners are added and removed when the scrollbars are rendered visible
> > and invisible (currently they are mapped until the patch is closed).
> > This is mainly because I still don't quite understand how the event
> > listener system works inside the pd_canvas.js. I was also unable to
> > locate resize listener in there. Note that pd_canvas.html has noscroll
> > and onresize inside its body tag, which may also benefit from being
> > integrated into the js file.
>

This is one place I would advise your input.

>
> > 2) figuring out a way where clicking on the scrollbar prevents the click
> > to propagate onto the canvas. I noticed this when there was an array
> > under it and I ended-up moving both.
>
> I may have a fix for that.
>

Great!


> >
> > 3) Once these two little things are figured out, we may want to figure
> > out finishing implementing other 1.x window features, such as window
> > transparency, noresize, ontop, and disable maximize (maximize and
> > transparency was not used extensively nor properly documented). For
> > this, I would love to learn how once could send messages directly to
> > window, effectively invoking functions inside the pdgui.js, for
> > instance. 1.x had a hcs external that did this. Does this "just work"
> > inside 2.x or is there something we need to add to make that possible?
>
> I'm very reluctant to do that because it turns the entire GUI into a public
> interface.
>
> For example-- if I had already done that it would make moving away from
> the nw.js api difficult because every user would have some reason that
> their
> patch must call directly into one of nw.js's methods.
>
> On the other hand, we're currently working on this webapp frontend for
> GSoC. So it may be helpful as part of that to consider what exactly the
> user would need to access in the GUI that they can't currently do. Then
> we could start gathering up our own curated public API.
>
> In other words, a filter could be-- can the thing be accessed both in
> native
> Purr Data and in the webapp? That would exclude things like accessing
> the filesystem through the GUI, for example.
>
> Still, I think it makes more sense to build in a hook for plugins written
> in javascript rather than accessing the GUI through a Pd object.
>

I imagine having at least ability to have these window features as a
checkbox inside the canvas dialog. A considerably better option would be if
we could agree on a limited number of API calls within ja that would be
exposed to manipulation from the canvas. I believe this is important
because given we are dealing with a programming language that has a GUI
component it would be essential that the user has control over those
parameters as they design their own patch or what may eventually become a
full-fledged application. Exposing that API would allow for that control to
be dynamic. Once we have agreed on that select API, even if we decide to
move to a different front-end we would at least know what functions are
considered public and therefore guaranteed to exist in the new
implementation, as well. And in the event that a certain API is not
implementable under certain conditions, such as web browser, we could at
least provide a convenience feedback buy a console letting the user know as
to why their call did not work.


> >
> > 4) Ensure that the zooms are consistent across all platforms, so that
> > what fits on one edge-to-edge, looks identical on another. I suspect
> > this could be a simple albeit time-consuming matter of tweaking zoom
> values.
>
> I didn't know they weren't. Did you post an issue to the tracker about
> this?
>

I mentioned it in our earlier conversation when dealing with Tweeter.
Namely the same path with the same window dimensions and same default zoom
level (100%) on different platforms results in a differently sized window.
Please note this does not include the window decoration but rather the
minute zoom differences between the platforms that result in greater white
space around the patch edges even though I was opening the same patch.
Happy to post the issue.


> >
> > 5) Once all this is done, I would suggest merging Tweeter (once I update
> > it) and then we can use this as an additional carrot to engage new
> > potential users.
>
> Sounds good.
>
> >
> > Other bugs I noticed that still need attention:
> >
> > *aforesaid dealing with off-center dialogs
> > *tweaking the window theme (0.46.2 looks different for some reason)
> > *ensuring that dialogs are not resizable
> > *reintroducing iemgui features 1.x has, such as ability for the number2
> > object to not have a frame or the > next to the number (used by K12)
> > *fixing weird sizes of the various dialog windows and ensuring that they
> > are not resizable.
> > *dynamic addition and removal of the event listeners for the scrollbars
> > and integration of the onscroll and onresize inside pd_canvas.js as
> > opposed to the pd_canvas.thml (as noted above)
> > *iemguis still have legacy issues when using properties/apply and having
> > a label reposition (I believe Jonathan is already working on this)
>
> You might check this since I merged fix-iemgui-label-bug
>

Was this after our conference call when we discovered additional legacy
issues for select objects and places where legacies not being checked for
even though it should be?


> > *subpatch with an array needs to be properly titled (right now it has no
> > title).
> > *subpatch plots need to be properly sized to go from edge to edge.
> > *fix slow console (e.g. by limiting the number of printed lines?)
> > *add ability to add \n to objects and their labels
> > *coll ability to dynamically monitor external file or edit the file via
> gui
> >
> > And new features (in addition to the GSoC efforts, listed in no
> > particular order):
> >
> > *Catching-up with the vanilla features, where applicable
> > *K12 integration
> > *Tooltips
> > *New HTML-based menu (this should be actually a lot of fun and could
> > end-up looking really cool)
>
> For that last one-- can we leverage whatever Hugo is creating for the
> webapp?
>

Totally!

>
> Related-- I'd really like to set up native Purr Data with a flag to run
> using
> the single-page webapp style Hugo is working on. That's just a much better
> UX than the toplevel window thing Pd has inherited from 90s motif.
>

I like that as long as we don't fragment our development efforts in an
attempt to support what may end up effectively being three different front
ends.


> As for the rest-- for the issues that aren't currently on the tracker,
> please add
> them.
>

Will do.


> -Jonathan
>
> >
> > Best,
> >
> > Ico
> >
> > On 6/14/2020 5:29 PM, Jonathan Wilkes wrote:
> > > On Sun, Jun 14, 2020 at 5:01 PM Ivica Bukvic <ico at vt.edu> wrote:
> > >> 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.
> > > It may be possible to fetch it at runtime with the Pd Window. E.g.,
> > > fetch the height, create the menu, then set a
> > > timeout that's long enough that the race is over.
> > >
> > > Still, you'll get buggy scrollbar appearance because we cannot trust
> > > the initial height values reported for the window.
> > >
> > > To make it clear-- suppose someone runs `pd-l2ork t*-help.pd`. The
> > > timeout duration necessary to ensure that the
> > > race doesn't screw up the scrollbars on once of those patches is so
> > > long that it would ruin the UX to implement it.
> > >
> > > -Jonathan
> > >
> > >
> > >
> > >
> > >
> > >> 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
> > >> _______________________________________________
> > >> 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
> >
> > --
> > 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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20200615/b93426a2/attachment-0001.html>


More information about the L2Ork-dev mailing list