[L2Ork-dev] upcoming: 2.14.1

Thu Sep 17 23:43:59 EDT 2020

> Seems like we want a "focus" event to listen for here. Can't remember
if activation is instance-wide. But if it is it could be a message to
the "pd" receiver, perhaps with a gpointer to the gobj that has just
been activated and a "1" or "0" for activation, deactivation.

Oops, I meant to talk about glist_grab here, not activatefn. Obviously that is
per canvas, so I'm not sure the "pd" receiver is the right place for that.

On Thu, Sep 17, 2020 at 11:42 PM Jonathan Wilkes <jon.w.wilkes at gmail.com> wrote:
>
> On Thu, Sep 17, 2020 at 10:41 PM Ivica Bukvic <ico at vt.edu> wrote:
> >
> > That is fine by me. Please bear in mind the way the improvement is structured right now it works out-of-box with the current upstream HEAD and offers immediate benefits. If you like, I can merge it with the clippable GOP branch because there is at least one place where a manual merge may be otherwise necessary. Lemme know.
>
> Keep it as a separate branch.
>
> >
> > On a related note, not sure if you saw the question I posed on the said git merge request (!554). Namely, do we want to disable global key press detection (via key/keyname/keyup) while user has focus on gatom and iemgui numbox and typing into it? The precedent for doing so is because that is how editing a text object text works.
>
> I think that was just a side-effect of the way I'm handling text
> object activation in the DOM, and nobody ever objected to it.
>
> > The argument against would be that text object behavior is only available in edit mode whereas gatom and iemgui numbox content editing is also available in runmode. My gut tells me disabling other key press detection may be the right way to go but am not 100% sold on it. In L2Ork Tweeter it is somewhat annoying even though I implemented keyboard disable option in there exactly for these kinds of reasons.
>
> Seems like we want a "focus" event to listen for here. Can't remember
> if activation is instance-wide. But if it is it could be a message to
> the "pd" receiver, perhaps with a gpointer to the gobj that has just
> been activated and a "1" or "0" for activation, deactivation.
>
> Other thing it makes me thing of:
>
> 1. If I have a patch in runmode that has two gatoms, shouldn't
> pressing `<tab>` in runmode glist_grab the first one?
> 2. Shouldn't pressing `<tab>` again glist_grab the second one, and so on?
> 3. Shouldn't pressing `<shift-tab>` traverse backwards for glist_grab'ing?
> 4. If one agrees with 1-3, then shouldn't *all* iemguis, gatom, msg
> (to trigger it) and some select GUI externals have a method to respond
> to being called up in the `<tab>` order?
>
> I think it would just require adding something like a "__focus" method
> so they can be queried using zgetfn. Then add a key method for classes
> like bng that don't have one, so we can respond to spacebar and/or
> enter to trigger the object.
>
> -Jonathan
>
> >
> > 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
> >
> > ci.icat.vt.edu
> > hcd.icat.vt.edu
> > www.icat.vt.edu
> > www.performingarts.vt.edu
> > l2ork.icat.vt.edu
> > ico.bukvic.net
> >
> >
> >
> > On Thu, Sep 17, 2020 at 3:57 PM Jonathan Wilkes <jon.w.wilkes at gmail.com> wrote:
> >>
> >> Thanks. I merged the two VU fixes.
> >>
> >> I left the numbox fix for when we merge your GOP clipping branch. That
> >> way if someone was using a numbox right on the edge of a GOP, the new
> >> shouldvis algorithm will still display it. The current algorithm would
> >> boot it off the GOP.
> >>
> >> It's definitely an edge case as the font would be overlapping the
> >> border in that case. But Pd users seem trained to seek out every
> >> unspecified corner case and use it to their advantage. (I offer in
> >> evidence the various Pd mailing list threads teaching people to change
> >> the size of a viewport by using a method called "donecanvasdialog".)
> >>
> >> -Jonathan
> >>
> >> On Thu, Sep 17, 2020 at 2:33 PM Ivica Bukvic <ico at vt.edu> wrote:
> >> >
> >> > You may want to consider merging a couple of small and quick merge requests I just submitted. Thanks.
> >> >
> >> > 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 Thu, Sep 17, 2020, 13:57 Jonathan Wilkes <jon.w.wilkes at gmail.com> wrote:
> >> >>
> >> >> HI all,
> >> >>
> >> >> In the interest of releasing early and often, I think we're ready for
> >> >> another release.
> >> >>
> >> >> This one doesn't yet include Albert's search bookmark feature or Ico's
> >> >> clipping window for GOPs. But it fixes a lot of usability bugs with
> >> >> 2.14.0. So unless there turn out to be nasty regressions in what's
> >> >> currently getting built in master, I'll bump it to 2.14.1, tag it, and
> >> >> release.
> >> >>
> >> >> Sam has generously made some changes to improve CI build times. I've
> >> >> merged the first of them and will test how that goes. This will
> >> >> hopefully bring CI builds back to a tolerable state.
> >> >>
> >> >> Best,
> >> >> 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
> >
> > _______________________________________________
> > L2Ork-dev mailing list
> > L2Ork-dev at disis.music.vt.edu
> > https://disis.music.vt.edu/listinfo/l2ork-dev