[L2Ork-dev] upcoming: 2.14.1

Fri Sep 18 10:05:16 EDT 2020

On 9/17/2020 11:43 PM, Jonathan Wilkes wrote:
>> 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.

Yep, that is what I was already looking into and I think I found a 
potentially easy way to do exactly that c-side. I just wanted to make 
sure that this will not result in annoying side-effects and so far it 
sounds like it won't?

Speaking of side-effects, my vote would be against tab focusing because 
that would be too intrusive from the key/keyup/keyname perspective. Tab 
could be also used in run mode for some activity (as it is in L2Ork 
Tweeter, for instance) and hijacking it would interrupt the interaction 
flow. At least the new iemgui numbox behavior when focused allows for 
pressing Esc to get out of it and it does require one to click on the 
object to get there in the first place, thus limiting the unintended 
consequences. Tab presses would result in tons of erroneous and 
potentially frustrating interruptions to the keyboard-based interaction.

That said, perhaps having tab focus in edit mode may not be a bad idea 
(e.g. navigating the glist), but doing so blindly, and activating the 
text object, as well as graphical objects. Come to think of it, this may 
be a nice way to understand the creation order, should such prove necessary.

>
>
> 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
> _______________________________________________
> 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
Co-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

www.icat.vt.edu
www.performingarts.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net