From: Amavect <amavect@gmail.com>
To: ori@eigenstate.org, 9front@9front.org
Subject: Re: [9front] rio: resize flash patch
Date: Tue, 24 Nov 2020 18:21:24 -0600 [thread overview]
Message-ID: <edfb69e5-da89-6b4c-7522-9c08c87b6f9b@gmail.com> (raw)
In-Reply-To: <288D9AF57CE80B394F1E5B40EA69B2D4@eigenstate.org>
On 11/24/2020 5:35 PM, ori@eigenstate.org wrote:
> Thinking about this a bit more -- I *think* I'm ok with
> documenting that the holder of /dev/mouse is responsible
> for refreshing on resize.
>
> If that's not something we want to do, it should also be
> possible to write a message to wctl to claim responsibility
> for refreshing a window, and making that explicit.
>
More accurately, that if /dev/mouse is open, then rio will not refresh
the window image on resize (except for the border), for the reason that
/dev/mouse sends resize messages.
I have thought about what the Right Thing should be. Neither mouse nor
wctl should be related to the act of drawing to the screen. That's
/dev/draw's responsibility. But rio's design is to not exactly stand
between the program and /dev/draw, so rio can't know anything.
Maybe this is one reason (among many) why I've never seen a text
terminal get replaced with a gui program anywhere else...
Thanks,
Amavect
next prev parent reply other threads:[~2020-11-25 4:13 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
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 [this message]
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=edfb69e5-da89-6b4c-7522-9c08c87b6f9b@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).