From: Amavect <amavect@gmail.com>
To: ori@eigenstate.org, 9front@9front.org
Subject: Re: [9front] rio: resize flash patch
Date: Sun, 22 Nov 2020 00:18:19 -0600 [thread overview]
Message-ID: <0c9bf097-0048-ef5b-2368-6a5a4b4dca3a@gmail.com> (raw)
In-Reply-To: <9241A7B5D971C32B53D48B6E7DC515F6@eigenstate.org>
On 11/21/2020 11:33 PM, ori@eigenstate.org wrote:
> The only question I have is whether there's an edge case
> with a program that opens the mouse device without doing
> any drawing of its own?
>
> 'cat /dev/mouse' acts a bit funny, for example -- does
> this matter? Can we fix it?
>
There are already quite a few if statements in rio that use
Window->mouseopen. /sys/src/cmd/rio/wind.c:/^repaint/ is one of them
affecting draw routines, but I'm not yet sure how it manifests.
Though I do enjoy printing out /dev/mouse on occasion, I don't think it
matters very much. As a counterexample, 'cat /dev/kbd' is utterly broken
as you cannot Delete to freedom. I'm not familiar with any non-gui mouse
programs.
Having /dev/mouse signal window resize events was never the Right Thing.
/dev/wctl has a very similar output, and even signals on hide and on
window activation, which may be nice to have. Taking control of a window
would be opening wctl for reading. That kind of semantic sounds very
nice. There are many edge cases, though, like winwatch.
Obviously, anything involving wctl would lead to a lot of retooling rio,
and it would break a lot of things. Food for thought.
Thanks,
Amavect
next prev parent reply other threads:[~2020-11-22 6:19 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-22 4:36 Amavect
2020-11-22 5:33 ` [9front] " ori
2020-11-22 6:18 ` Amavect [this message]
2020-11-22 10:33 ` hiro
2020-11-22 16:57 ` cinap_lenrek
2020-11-22 17:10 ` Amavect
2020-11-24 23:35 ` ori
2020-11-25 0:21 ` Amavect
2020-11-25 9:38 ` hiro
2020-11-25 12:34 ` Ethan Gardener
[not found] ` <379baa18-a67f-de65-98b5-d7e08cbb5101@gmail.com>
[not found] ` <19260358-767b-4746-a3ff-4ce456a646c5@www.fastmail.com>
[not found] ` <CAFSF3XN_vLb89F=CCzXLkiQvYFFHYm72aSbc1NRkPBtDqwPzFA@mail.gmail.com>
2020-11-29 20:55 ` Ethan Gardener
2020-11-29 22:15 ` cinap_lenrek
2020-11-29 22:55 ` Stuart Morrow
2020-11-29 23:35 ` cinap_lenrek
2020-11-30 0:10 ` Stuart Morrow
2020-11-30 0:13 ` Stuart Morrow
2020-11-30 0:21 ` Alex Musolino
2020-11-30 1:48 ` ori
2020-11-30 2:17 ` Stanley Lieber
2020-11-30 9:19 ` hiro
2020-11-30 18:26 ` Ethan Gardener
2020-11-29 22:26 ` umbraticus
2020-11-29 22:50 ` Ethan Gardener
2020-11-22 17:14 ` ori
2020-11-22 20:40 ` hiro
2020-11-22 21:18 ` ori
2020-12-03 2:17 ` magma698hfsp273p9f
2020-11-23 21:16 ` Ethan Gardener
2020-11-23 22:06 ` Amavect
2020-11-23 23:17 ` Ethan Gardener
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0c9bf097-0048-ef5b-2368-6a5a4b4dca3a@gmail.com \
--to=amavect@gmail.com \
--cc=9front@9front.org \
--cc=ori@eigenstate.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).