Re: [9front] Mouse clipping patch

["José Miguel Sánchez García" <soy.jmi2k@gmail.com>]

Okay, now I think the best way to solve it while keeping transparency
is to rely on convention, just like ESC and Del. Programs clipping the
mouse should unclip it if a particular key is pressed. Programs like
screenlock can choose to ignore this convention, as they rely on
having a permanent grab.

Rio would simply pass the event to the focused window (if it's a
window grabbing the mouse, it'll release it; if it's a nested rio, it
will also pass down the event, if it's a regular window it will do
whatever it wants with it). Does that sound good?

On Wed, Jul 14, 2021 at 2:28 PM Stuart Morrow <morrow.stuart@gmail.com> wrote:
>
> On 14/07/2021, hiro <23hiro@gmail.com> wrote:
> > i still don't see it. either rio consumes the commands or it forwards
> > them. i don't see anything inbetween.
> > where is the complication?
>
> It's not a complication in terms of code, it's that it's an
> untransparent interface.  If we think that window management : the
> windows :: the line discipline : the shell, then keyboard-driven wm is
> like when the line discipline used to interpret # and @.
>
> There's nothing obvious about Unix commands, which one you want for
> what you're trying to do. But knowing the command is *all* the
> difficulty - there's no further difficulty in the "transmit the
> command from the user to the shell" layer, it's just "for each letter
> in the command, type that letter on the keyboard".
>
> The outermost layer needs to be transparent, perhaps so that stuff on
> the other side of it can get more leeway to be confusing.