Re: [9front] [PATCH] rio: resize border and scrollbar based on font

Re: [9front] [PATCH] rio: resize border and scrollbar based on font

[Romano]

Thanks for the feedback, moody.

While it may be a band-aid, it does improve things from where I sit.
When I drawterm from a mac w/2560x1664 resolution, it's unbearable
with the default font. So I'm currently using /n/ttf/unifont.ttf.32/font
which makes everything pretty usable. The one thing that bothered me
was the scrollbar, and then I noticed the border width was super thin
too so tweaked that.

If this just modified the scroll bar to account for the font size,
would that be more palatable to you?

I also can't imagine trying to go through all programs to see which
rely on a specific rio border-width. It would be nice to address that
along with magnification. But I think this is a start, and makes things
more bearable at least for me.

Anyway, what do you think about just modifying the scroll bars? And
do you have thoughts on how to do scaling generally?

- Romano

Re: [9front] [PATCH] rio: resize border and scrollbar based on font

[Kristo]

On 10.5.2024 9.13, Romano wrote:
> I also can't imagine trying to go through all programs to see which
> rely on a specific rio border-width.

Rio was probably the first 9 program that I ever hacked on and I do recall
that modifying the border size did unfortunately mess up some programs. If
I had to guess now I'd say it was mothra. A lot of code has changed since
then though, sorry I don't have a machine to test with at the moment.

Kristo

Re: [9front] [PATCH] rio: resize border and scrollbar based on font

[Stanley Lieber]

On May 10, 2024 9:27:50 AM EDT, Kristo <kristo.ilmari@gmail.com> wrote:
>On 10.5.2024 9.13, Romano wrote:
>> I also can't imagine trying to go through all programs to see which
>> rely on a specific rio border-width.
>
>Rio was probably the first 9 program that I ever hacked on and I do recall
>that modifying the border size did unfortunately mess up some programs. If
>I had to guess now I'd say it was mothra. A lot of code has changed since
>then though, sorry I don't have a machine to test with at the moment.
>
>Kristo
>

mycroftiv's grio has border widths implemented as command flags. i remember seeing some weird behavior around the edges of some programs when i used it to diddle those values.

if existing programs rely on bad assumptions, it's worth adjusting them to remove the bad assumptions. sometimes you just have to do this, even though it can be a lot of tedious work.

that's why it's also worth figuring out where the best place to cut is. one of plan 9's strong suits has always been careful choices about what to omit, with various small pieces thoughtfully interacting to maximum effect, sometimes going too far, and sometimes not going far enough. the important thing is to think before cutting.

my experience with general scaling is that it seems nice when the physical screen geometry and the desired resolution don't result in a fuzzy mess, but this doesn't happen very often. specifying border size alone on the command line doesn't address all the other bibs and bobs like menus and scrollbars (fortunately,  rio isn't overly ornate). and of course, many programs manage their own unique scrollbars, menus, fonts, etc., usually hardcoded.

i can't help but admire the choice of cuts in sigrid's /dev/theme. if gui programs were modified to honor this convention, they wouldn't need to be altered again in the future. and a theme file seems like a good place to get specific about border sizes, etc. for example, the stuff phil9 has been woking on (mongrel, vdir, etc.) already honor /dev/theme.

alternately, maybe we need some kind of heuristic based on screen resolution? this would probably not make everybody happy, either, but might get us close enough to subjective visual consistency to call the game.

sl

Re: [9front] [PATCH] rio: resize border and scrollbar based on font

[Jacob Moody]

On 5/10/24 01:13, Romano wrote:
> Thanks for the feedback, moody.
> 
> While it may be a band-aid, it does improve things from where I sit.
> When I drawterm from a mac w/2560x1664 resolution, it's unbearable
> with the default font. So I'm currently using /n/ttf/unifont.ttf.32/font
> which makes everything pretty usable. The one thing that bothered me
> was the scrollbar, and then I noticed the border width was super thin
> too so tweaked that.

I do not like merging hacks, I want to find solutions. This is only
a problem when using the system over drawterm from a mac.
I am not interested in merging this as is.

> 
> If this just modified the scroll bar to account for the font size,
> would that be more palatable to you?

No, I don't want rio having code for scaling.

> 
> I also can't imagine trying to go through all programs to see which
> rely on a specific rio border-width. It would be nice to address that
> along with magnification. But I think this is a start, and makes things
> more bearable at least for me.

I don't want to merge "a start" just because it exists, let's us figure
the correct solution to the problem. If all this discussion is going to be
is you hamfisting this despite all these problems for it just being "well
it kinda works not really but its a start" then we're going nowhere.

> 
> Anyway, what do you think about just modifying the scroll bars? And
> do you have thoughts on how to do scaling generally?


I find scaling based on the font a bit silly. Maybe some $scale or
something would make more sense to me, and be more general to every
program. I do not like this solution though, I am rejecting this patch.

Re: [9front] [PATCH] rio: resize border and scrollbar based on font

[Romano]

For whatever reason, I'm getting delayed mails from the mailing list. I
haven't investigated further.

> I do not like merging hacks, I want to find solutions. This is only
> a problem when using the system over drawterm from a mac.

No, it also is when I hook up my extrawide LG monitor, not via drawterm.
I gave one example. I also want to find general solutions but I don't
want to make the perfect the enemy of the good: sometimes things may not
be the best, but they do help with a large chunk of the problem. That's
probably why there are so many commits already to 9front that are self-
described hacks: they're not ideal, but they are better than before.

> If all this discussion is going to be
> is you hamfisting this despite all these problems for it just being "well
> it kinda works not really but its a start" then we're going nowhere.

That's not what I said: it works for me, not "it kinda works not really".
And it's not me ham-fisting (which is the first time I've seen it used as a
verb not an adjective) the patch by giving more details about how it helps
in my setup. That's not "all this discussion" is about. I think there has
been a good discussion, particularly the suggestion about using environment
variables and /dev/theme. Whether or not either of those is an approach that
would be acceptable is another matter.

> I find scaling based on the font a bit silly. Maybe some $scale or
> something would make more sense to me, and be more general to every
> program.

I agree, but it was addressing a good chunk of the problem I had at hand
so figured something is better than nothing. The thoughts about /dev/theme and
using environment variables are better than my submission, for sure, as
they're more general. But yeah, a general scaling UI would be nice. Some
programs might never be so general, like vnc. That's why I created the vnc
auto-scaling patch (which I'm glad was not rejected), because that was
scratching my most immediate itch at the time.

> I do not like this solution though, I am rejecting this patch.

Thank you for your consideration. At least if anyone has a large monitor
and finds this helpful while the ideal solution is hammered out, it's
here for the taking.

Re: [9front] [PATCH] rio: resize border and scrollbar based on font

[Jacob Moody]

On 5/10/24 13:43, Romano wrote:
> For whatever reason, I'm getting delayed mails from the mailing list. I
> haven't investigated further.
> 
>> I do not like merging hacks, I want to find solutions. This is only
>> a problem when using the system over drawterm from a mac.
> 
> No, it also is when I hook up my extrawide LG monitor, not via drawterm.
> I gave one example. I also want to find general solutions but I don't
> want to make the perfect the enemy of the good: sometimes things may not
> be the best, but they do help with a large chunk of the problem. That's
> probably why there are so many commits already to 9front that are self-
> described hacks: they're not ideal, but they are better than before.

This is not just a one time hack however, this sets a precedent.
If we allow scaling patches for rio then do we also for acme and sam
and mothra and every other graphical program? I don't want to make
perfect the enemy of good but I also don't want to just make conventions
without thinking about them properly.

I don't think bad conventions in the tree create an environment that is
better then before.

> 
>> If all this discussion is going to be
>> is you hamfisting this despite all these problems for it just being "well
>> it kinda works not really but its a start" then we're going nowhere.
> 
> That's not what I said: it works for me, not "it kinda works not really".
> And it's not me ham-fisting (which is the first time I've seen it used as a
> verb not an adjective) the patch by giving more details about how it helps
> in my setup. That's not "all this discussion" is about. I think there has
> been a good discussion, particularly the suggestion about using environment
> variables and /dev/theme. Whether or not either of those is an approach that
> would be acceptable is another matter.

You are not listening to what I said, your patch does not work. I pointed
out that there are assumptions about the rio border size. You *will* break programs with this.
You don't just get to decide to ignore that problem and break people's shit. This is why I
called what you did ham-fisting, this patch is clumsy and pushing for its inclusion after being
told how clumsy it is is not how we do things here.

By "all the discussion" I was referring to your previous email which basically boiled down to
"yes I know there are issues but it works on my machine". You ask for review, I give it to you
then you reject my review by giving anecdotal evidence and saying you can't be bothered to fix
graphical programs that have assumptions about the border width. Again this is not how we do shit here.

/dev/theme is not merged so you can not hang your solution off of that if you'd like it merged.
Here's how I would approach this:
1. fix code assumptions about rio's border size, or use an environment variable or something.
2. Attempt a transparent scaling, perhaps something in libdraw that just stupidly does 2x upscaling of draw ops
   a. evaluate how much this sucks, maybe it works fine maybe it creates a shit experience idk
3. Failing that we give up and add $scale and make it every programs problem to distinguish what should be scalled (things like UI elements) vs not (fonts and images)

I don't see any other appetizing option at the moment, perhaps someone else does.

Re: [9front] [PATCH] rio: resize border and scrollbar based on font

[ori]

Quoth Jacob Moody <moody@posixcafe.org>:
> /dev/theme is not merged so you can not hang your solution off of that if you'd like it merged.
> Here's how I would approach this:
> 1. fix code assumptions about rio's border size, or use an environment variable or something.

This is probably a good idea regardless of the rest. Bonus if
the fix made programs completely ignorant of, and oblivious to,
border widths.

> 2. Attempt a transparent scaling, perhaps something in libdraw that just stupidly does 2x upscaling of draw ops
>    a. evaluate how much this sucks, maybe it works fine maybe it creates a shit experience idk
> 3. Failing that we give up and add $scale and make it every programs problem to distinguish what should be scalled (things like UI elements) vs not (fonts and images)
> 
> I don't see any other appetizing option at the moment, perhaps someone else does.
> 

It strikes me that font size may not be the worst thing to hang
the scaling off of; outside of Plan 9, many things draw in units
of 'em', which is the width of a capital 'M' in the current type
face.

There are issues around that (what do we do when we scale a 1 pixel
line by 37%?), and I don't know how to solve them.

With scaling, there's a lot of options we can take for behavior,
and all of it sucks in one way or another.

The one option we have implemented now ("implement for a reasonable
range of display densitys, and don't scale") is the only one that
doesn't degrade quality. From there, we start to make tradeoffs.

	- What do we do with images?
	- What do we want to do with non-integer scale multiples?
	- How about a mix of images and text? should we scale the
	  images? how? (imagine, eg, a mapping program)
	- If we have multiple monitors (yeah, not implemented yet,
	  but I *really* want it), how should scaling behave?
	- Do we want antialiasing in devdraw to make fractional line
	  widths look acceptable.

I haven't put a ton of thought into this. It may be possible to
get a viable tradeoff with some split between libdraw and devdraw,
but there's nothing that jumps out to me as obviously correct.

Re: [9front] [PATCH] rio: resize border and scrollbar based on font

[sl]

> For whatever reason, I'm getting delayed mails from the mailing
> list.  I haven't investigated further.

we use upas mlmgr(1).

what happens is, it processes outgoing messages in batches, and chokes
when one fails for whatever reason.  when this happens, all the rest
of the messages in the batch are also postponed.

over the years we have improved performance some by tweaking scripts
and making sure the mailing list runs on a fast disk, but to my
knowledge nobody has yet worked on the actual mlmgr(1) stuff directly.

sl

Re: [9front] [PATCH] rio: resize border and scrollbar based on font

[Romano]

I looked back over my replies and I couldn't see where I was pushing
for inclusion.  I thanked you for your feedback to begin with.  I
wasn't rejecting your review but I wanted to understand some of your
feedback better.  I understood what you were saying in regards to it
not being accepted.

But based on your last response I think you didn't understand what I
was saying, or rather the context in which I was saying what I was
saying.  Perhaps when I wrote, "But I think this is a start, and
makes things more bearable at least for me." you took that as me
pushing for inclusion?  Or in my last reply re: not letting the
perfect be the enemy of the good?  In my responses, I was explaining
how it was useful for me, and of course that's anecdotal: patches
often are.  I thought my question before my "more bearable " comment
re: just the scrollbars and my followup questions after (all in the
same email) would make it clear I wasn't pushing for inclusion. But
that didn't mean that I thought the discussion was over regarding
different paths forward. Your last response made it clear to me that
you (and perhaps others) thought I was pushing for inclusion. Sorry
about that.

My last email response was with the understanding that I knew it was
rejected and I wasn't trying to force its inclusion.  I did have
comments regarding what was considered hacky and how I've seen commits
accepted that do (knowingly) break assumptions/previous interfaces.
Things that I've seen done around here.

Anyway, in an attempt not to be misunderstood in the future I will try
the following boilerplate response: "
Thank you for reviewing.  I understand by your response that the patch
is rejected by you.  However, I have some related follow-up questions
and comments.  I don't expect any reply, especially if you consider my
follow-ups have already been addressed.  I also don't want to make you
think I am pushing for the patch as written to be included: I am not.

So having said that, ...  [my follow-ups] ..."

In the past I have followed up on patches I sent to the mailing list
but which were never commented on. I was told earlier (I think in
January, IIRC) that if no comment had bern given after a week it's
okay to follow-up.

And I often have seen messages here like "patches welcome" and
also lambasting those who ask about something to be changed given a
response akin to "talk is cheap, show me the code." So up until now I
have figured showing at least some effort with a patch (which might
very well be rejected) is better than just asking about scaling and
sizing.

Again, thank you for all you have helped me with on this list and on
gridchat.

Re: [9front] [PATCH] rio: resize border and scrollbar based on font

[Romano]

sl wrote:
> we use upas mlmgr(1).

> what happens is, it processes outgoing messages in batches, and chokes
> when one fails for whatever reason.  when this happens, all the rest
> of the messages in the batch are also postponed.

Ah yes, I seem to remember a couple years ago you (and perhaps ori, IIRC)
were trying to nail down the cause. The issue only became markedly worse
for me in the last month or so, I want to say.

Thanks for noticing my comment, sl, and thanks for all the management of
9front infrastructure you do (not least of which is the FQA). I'd be
completely (and not just mostly!) lost without it.

Re: [9front] [PATCH] rio: resize border and scrollbar based on font

[Jacob Moody]

On 5/10/24 23:31, Romano wrote:
> I looked back over my replies and I couldn't see where I was pushing
> for inclusion.  I thanked you for your feedback to begin with.  I
> wasn't rejecting your review but I wanted to understand some of your
> feedback better.  I understood what you were saying in regards to it
> not being accepted.
> 
> But based on your last response I think you didn't understand what I
> was saying, or rather the context in which I was saying what I was
> saying.  Perhaps when I wrote, "But I think this is a start, and
> makes things more bearable at least for me." you took that as me
> pushing for inclusion?  Or in my last reply re: not letting the
> perfect be the enemy of the good?  In my responses, I was explaining
> how it was useful for me, and of course that's anecdotal: patches
> often are.  I thought my question before my "more bearable " comment
> re: just the scrollbars and my followup questions after (all in the
> same email) would make it clear I wasn't pushing for inclusion. But
> that didn't mean that I thought the discussion was over regarding
> different paths forward. Your last response made it clear to me that
> you (and perhaps others) thought I was pushing for inclusion. Sorry
> about that.


Yes the "its a start" and other phrases that read as excuses about
the state of code read as an argument for inclusion. I get quite frustrated
when I give feedback about code and it is selectively ignored, like what I said
about fixing the existing graphical programs assumptions about the border. You
also were still asking about including just including the scrollbar changes, again
after I said that we need to figure out what the interface is instead of just committing
code. Perhaps push is too strong of a word, but you clearly were still presenting reasons
why it should be included.

> 
> My last email response was with the understanding that I knew it was
> rejected and I wasn't trying to force its inclusion.  I did have
> comments regarding what was considered hacky and how I've seen commits
> accepted that do (knowingly) break assumptions/previous interfaces.
> Things that I've seen done around here.

It is only done with careful consideration and extra care must be taken
to modifications of fan favorites like rio. I am telling you that this
is "moving the water dish" too much but you don't seem to want to believe me.
The fact that it happens sometimes does not give you a blanket excuse to do
it whenever you want.

The reason I was not super enthusiastic to scale based on font was because
this would change the existing rio environment for people who currently use
a larger font. Like this is a pretty big "taste" change.

> 
> Anyway, in an attempt not to be misunderstood in the future I will try
> the following boilerplate response: "
> Thank you for reviewing.  I understand by your response that the patch
> is rejected by you.  However, I have some related follow-up questions
> and comments.  I don't expect any reply, especially if you consider my
> follow-ups have already been addressed.  I also don't want to make you
> think I am pushing for the patch as written to be included: I am not.
> 
> So having said that, ...  [my follow-ups] ..."

Arguing for and/or making excuses for code reads as you pushing that
things are "Ok as is" and I interpret this as pushing for inclusion as is.
You don't need boiler plates just stop doing that if you don't actually
think the patch is good as is.

> 
> In the past I have followed up on patches I sent to the mailing list
> but which were never commented on. I was told earlier (I think in
> January, IIRC) that if no comment had bern given after a week it's
> okay to follow-up.

Sure, this was not a follow-up this was an argument against the issues
I raised against the patch implementation.

> 
> And I often have seen messages here like "patches welcome" and
> also lambasting those who ask about something to be changed given a
> response akin to "talk is cheap, show me the code." So up until now I
> have figured showing at least some effort with a patch (which might
> very well be rejected) is better than just asking about scaling and
> sizing.

Sure, now we have a whole discussion about how to implement this.
You just have to continue working on it, patches are rarely ever
good enough on first cut to be included. Patches are posted, people
give feedback and folks go back and add that feedback to their code.
You are missing this part where you got back and work on the suggestions
made about the code, I know you've done it before for patches so I am not
sure why you seem to averse to it now.

At the end of the day you have code for yourself now for you to use.
You've solved the problem for yourself.

> 
> Again, thank you for all you have helped me with on this list and on
> gridchat.

I don't have anything against you my dude. This conversation just had big
"take it or leave it" energy about the state of the code. Excuses for
why merging code that was going to break other graphical programs was ok,
merging conventions that we may or may not actually want to commit to.
Saying "well if anyone else wants this diff here it is". Can you really
not see how I would interpret this as wanting to continue with how the
code is?

I am really not interested in sitting here and arguing intent, I stated
my issues with how the conversation has gone. I don't know what to say
if you really can not see how I arrived at these interpretations.


- Moody

Re: [9front] [PATCH] rio: resize border and scrollbar based on font

[hiro]

> This is not just a one time hack however, this sets a precedent.
> If we allow scaling patches for rio then do we also for acme and sam
> and mothra and every other graphical program?

doesn't acme already support font-based scaling?

Re: [9front] [PATCH] rio: resize border and scrollbar based on font

[hiro]

> There are issues around that (what do we do when we scale a 1 pixel
> line by 37%?), and I don't know how to solve them.

In boario a second pixelline will blink in and out of existence for
37% of each second to achieve time domain dithering.

Re: [9front] [PATCH] rio: resize border and scrollbar based on font

[hiro]

i'm glad people are invested into the code they wrote, but as ori and
moody explained in depth doing a significant improvent to the current
lack of scaling would require huge amount of changes in many unrelated
components.

if you want to make it more probable that rio is ever replaced, I
think you should think of improving our overall graphics system. you
could work on this in parallel to all the current limited
rio/libdraw/devdraw graphical programs. i think it's not possible for
a single person to do though.

My reason is that rio sucks, and devdraw sucks, mainly bec. both
depend on each other in a clunky way. Given that this is already a
second-system I'm quite surprised how little apparent thought went
into this design. So yeah, I propose a third-system that takes a more
educated approach concentrating on actually making simple graphics/UI
abstractions, as opposed to making a demo/example/benchmark
application for concurrency and parallelism in an incomplete
multiprocessor system.
Just be careful with those overly abstract and generic graphics
toolkits, they are often way more complicated what would be needed to
replace rio/libdraw/devdraw.

Re: [9front] [PATCH] rio: resize border and scrollbar based on font

[Romano]

[-- Attachment #1: Type: text/plain, Size: 215 bytes --]

On Sat May 11 09:32:38 -0700 2024, moody@posixcafe.org wrote:
> Yes the "its a start" and other phrases that read as excuses about
> the state of code read as an argument for inclusion.
> ...

Thank you, understood.

[-- Attachment #2: Type: message/rfc822, Size: 16383 bytes --]

From: Jacob Moody <moody@posixcafe.org>
To: 9front@9front.org
Subject: Re: [9front] [PATCH] rio: resize border and scrollbar based on font
Date: Sat, 11 May 2024 10:00:57 -0500
Message-ID: <10658a6d-38bc-4b49-bc13-c42cc0113034@posixcafe.org>

On 5/10/24 23:31, Romano wrote:
> I looked back over my replies and I couldn't see where I was pushing
> for inclusion.  I thanked you for your feedback to begin with.  I
> wasn't rejecting your review but I wanted to understand some of your
> feedback better.  I understood what you were saying in regards to it
> not being accepted.
> 
> But based on your last response I think you didn't understand what I
> was saying, or rather the context in which I was saying what I was
> saying.  Perhaps when I wrote, "But I think this is a start, and
> makes things more bearable at least for me." you took that as me
> pushing for inclusion?  Or in my last reply re: not letting the
> perfect be the enemy of the good?  In my responses, I was explaining
> how it was useful for me, and of course that's anecdotal: patches
> often are.  I thought my question before my "more bearable " comment
> re: just the scrollbars and my followup questions after (all in the
> same email) would make it clear I wasn't pushing for inclusion. But
> that didn't mean that I thought the discussion was over regarding
> different paths forward. Your last response made it clear to me that
> you (and perhaps others) thought I was pushing for inclusion. Sorry
> about that.


Yes the "its a start" and other phrases that read as excuses about
the state of code read as an argument for inclusion. I get quite frustrated
when I give feedback about code and it is selectively ignored, like what I said
about fixing the existing graphical programs assumptions about the border. You
also were still asking about including just including the scrollbar changes, again
after I said that we need to figure out what the interface is instead of just committing
code. Perhaps push is too strong of a word, but you clearly were still presenting reasons
why it should be included.

> 
> My last email response was with the understanding that I knew it was
> rejected and I wasn't trying to force its inclusion.  I did have
> comments regarding what was considered hacky and how I've seen commits
> accepted that do (knowingly) break assumptions/previous interfaces.
> Things that I've seen done around here.

It is only done with careful consideration and extra care must be taken
to modifications of fan favorites like rio. I am telling you that this
is "moving the water dish" too much but you don't seem to want to believe me.
The fact that it happens sometimes does not give you a blanket excuse to do
it whenever you want.

The reason I was not super enthusiastic to scale based on font was because
this would change the existing rio environment for people who currently use
a larger font. Like this is a pretty big "taste" change.

> 
> Anyway, in an attempt not to be misunderstood in the future I will try
> the following boilerplate response: "
> Thank you for reviewing.  I understand by your response that the patch
> is rejected by you.  However, I have some related follow-up questions
> and comments.  I don't expect any reply, especially if you consider my
> follow-ups have already been addressed.  I also don't want to make you
> think I am pushing for the patch as written to be included: I am not.
> 
> So having said that, ...  [my follow-ups] ..."

Arguing for and/or making excuses for code reads as you pushing that
things are "Ok as is" and I interpret this as pushing for inclusion as is.
You don't need boiler plates just stop doing that if you don't actually
think the patch is good as is.

> 
> In the past I have followed up on patches I sent to the mailing list
> but which were never commented on. I was told earlier (I think in
> January, IIRC) that if no comment had bern given after a week it's
> okay to follow-up.

Sure, this was not a follow-up this was an argument against the issues
I raised against the patch implementation.

> 
> And I often have seen messages here like "patches welcome" and
> also lambasting those who ask about something to be changed given a
> response akin to "talk is cheap, show me the code." So up until now I
> have figured showing at least some effort with a patch (which might
> very well be rejected) is better than just asking about scaling and
> sizing.

Sure, now we have a whole discussion about how to implement this.
You just have to continue working on it, patches are rarely ever
good enough on first cut to be included. Patches are posted, people
give feedback and folks go back and add that feedback to their code.
You are missing this part where you got back and work on the suggestions
made about the code, I know you've done it before for patches so I am not
sure why you seem to averse to it now.

At the end of the day you have code for yourself now for you to use.
You've solved the problem for yourself.

> 
> Again, thank you for all you have helped me with on this list and on
> gridchat.

I don't have anything against you my dude. This conversation just had big
"take it or leave it" energy about the state of the code. Excuses for
why merging code that was going to break other graphical programs was ok,
merging conventions that we may or may not actually want to commit to.
Saying "well if anyone else wants this diff here it is". Can you really
not see how I would interpret this as wanting to continue with how the
code is?

I am really not interested in sitting here and arguing intent, I stated
my issues with how the conversation has gone. I don't know what to say
if you really can not see how I arrived at these interpretations.


- Moody

Re: [9front] [PATCH] rio: resize border and scrollbar based on font

[Romano]

[-- Attachment #1: Type: text/plain, Size: 1097 bytes --]


On Fri May 10 23:32:59 -0700 2024, Romano wrote:
> sl wrote:
> > we use upas mlmgr(1).
> 
> > what happens is, it processes outgoing messages in batches, and chokes
> > when one fails for whatever reason.  when this happens, all the rest
> > of the messages in the batch are also postponed.
> 
> Ah yes, I seem to remember a couple years ago you (and perhaps ori, IIRC)
> were trying to nail down the cause. The issue only became markedly worse
> for me in the last month or so, I want to say.
> 
> Thanks for noticing my comment, sl, and thanks for all the management of
> 9front infrastructure you do (not least of which is the FQA). I'd be
> completely (and not just mostly!) lost without it.

Just wanted to close the loop here, so to speak. The issue appears to be on
my side: my mail provider is only passing me mailing list e-mails every couple
of hours! The reason I suspect this is because I'm experiencing the same
thing with the 9fans mailing list. I looked at the raw headers, and it looks
like the mail provider's spam filtering might be to blame. I'm going to
try some knob turning.

[-- Attachment #2: Type: message/rfc822, Size: 11717 bytes --]

From: Romano <unobe@cpan.org>
To: 9front@9front.org
Subject: Re: [9front] [PATCH] rio: resize border and scrollbar based on font
Date: Fri, 10 May 2024 21:34:59 -0700
Message-ID: <52040989C1CE07858F410C6067CFC740@smtp.pobox.com>

sl wrote:
> we use upas mlmgr(1).

> what happens is, it processes outgoing messages in batches, and chokes
> when one fails for whatever reason.  when this happens, all the rest
> of the messages in the batch are also postponed.

Ah yes, I seem to remember a couple years ago you (and perhaps ori, IIRC)
were trying to nail down the cause. The issue only became markedly worse
for me in the last month or so, I want to say.

Thanks for noticing my comment, sl, and thanks for all the management of
9front infrastructure you do (not least of which is the FQA). I'd be
completely (and not just mostly!) lost without it.

Re: [9front] [PATCH] rio: resize border and scrollbar based on font

[Jacob Moody]

Sure that would be better. I had also mentioned $scale variable
elsewhere in this thread. If we want to make this the responsibility
of client programs then I think some environment variable is the way
to communicate it.

On 5/11/24 11:27, hiro wrote:
> khm already mentioned that if you don't want arguments you can use
> some /env files instead.
> 
> On Fri, May 10, 2024 at 4:11 PM Jacob Moody <moody@posixcafe.org> wrote:
>>
>> On 5/10/24 01:20, Kurt H Maier wrote:
>>> On Thu, May 09, 2024 at 07:14:06PM -0500, Jacob Moody wrote:
>>>>
>>>> we do not currently do any sort of scaling in the UI for larger displays.
>>>> I think we should be looking at a more general solution to this problem,
>>>
>>> scrollbars and borders should be arguments passed to rio and then
>>> exposed in env or elsewhere
>>>
>>> every other attempt at 'general solutions' to ui scaling have been
>>> miserable goddamn failures and I really really don't want to live
>>> through it again
>>>
>>> khm
>>
>> Alright then where's you're code for a solution here? I don't
>> want arguments to every fucking program for scaling.
>>

Re: [9front] [PATCH] rio: resize border and scrollbar based on font

[hiro]

i agree. and it's not even 9front specific. i have scaling issues on
every OS i ever tried. The solution is simple: 1600x1200 works
perfectly on anything that actually matters. By accident I found this
solution decades ago, only after switching to modern displays and back
I realized that I already found perfection back then.

On Fri, May 10, 2024 at 6:44 PM Stuart Morrow <morrow.stuart@gmail.com> wrote:
>
> > one way or another,  screens are getting more and more pixels. i used to complain about the opposite problem: on low resolution screens, the borders are HUGE.
> >
> > sl
>
> I'm happier with certain screens plain being off-limits than having a
> million ad-hoc patches.

Re: [9front] [PATCH] rio: resize border and scrollbar based on font

[hiro]

if they have too MANY pixels just don't buy them.
you have that option now.

On Fri, May 10, 2024 at 6:12 PM Stanley Lieber <sl@stanleylieber.com> wrote:
>
> On May 10, 2024 11:28:12 AM EDT, Stuart Morrow <morrow.stuart@gmail.com> wrote:
> >> > I don't want arguments to every fucking program for scaling.
> >>
> >> I agree, but there is no other way to achieve it correctly, on any
> >> operating system.  I'd rather we just didn't bother
> >>
> >> khm
> >
> >Just use AI
> >
>
> one way or another,  screens are getting more and more pixels. i used to complain about the opposite problem: on low resolution screens, the borders are HUGE.
>
> sl

Re: [9front] [PATCH] rio: resize border and scrollbar based on font

[hiro]

khm already mentioned that if you don't want arguments you can use
some /env files instead.

On Fri, May 10, 2024 at 4:11 PM Jacob Moody <moody@posixcafe.org> wrote:
>
> On 5/10/24 01:20, Kurt H Maier wrote:
> > On Thu, May 09, 2024 at 07:14:06PM -0500, Jacob Moody wrote:
> >>
> >> we do not currently do any sort of scaling in the UI for larger displays.
> >> I think we should be looking at a more general solution to this problem,
> >
> > scrollbars and borders should be arguments passed to rio and then
> > exposed in env or elsewhere
> >
> > every other attempt at 'general solutions' to ui scaling have been
> > miserable goddamn failures and I really really don't want to live
> > through it again
> >
> > khm
>
> Alright then where's you're code for a solution here? I don't
> want arguments to every fucking program for scaling.
>

Re: [9front] [PATCH] rio: resize border and scrollbar based on font

[Stuart Morrow]

On Fri, 10 May 2024 at 17:43, Stuart Morrow <morrow.stuart@gmail.com> wrote:
> million ad-hoc patches

in the distribution.

Re: [9front] [PATCH] rio: resize border and scrollbar based on font

[Stuart Morrow]

> one way or another,  screens are getting more and more pixels. i used to complain about the opposite problem: on low resolution screens, the borders are HUGE.
>
> sl

I'm happier with certain screens plain being off-limits than having a
million ad-hoc patches.

Re: [9front] [PATCH] rio: resize border and scrollbar based on font

[Stanley Lieber]

On May 10, 2024 11:28:12 AM EDT, Stuart Morrow <morrow.stuart@gmail.com> wrote:
>> > I don't want arguments to every fucking program for scaling.
>>
>> I agree, but there is no other way to achieve it correctly, on any
>> operating system.  I'd rather we just didn't bother
>>
>> khm
>
>Just use AI
>

one way or another,  screens are getting more and more pixels. i used to complain about the opposite problem: on low resolution screens, the borders are HUGE.

sl

Re: [9front] [PATCH] rio: resize border and scrollbar based on font

[Stuart Morrow]

> > I don't want arguments to every fucking program for scaling.
>
> I agree, but there is no other way to achieve it correctly, on any
> operating system.  I'd rather we just didn't bother
>
> khm

Just use AI

Re: [9front] [PATCH] rio: resize border and scrollbar based on font

[Kurt H Maier]

On Fri, May 10, 2024 at 09:10:29AM -0500, Jacob Moody wrote:
> 
> Alright then where's you're code for a solution here?

I'm not a programmer.

> I don't want arguments to every fucking program for scaling.

I agree, but there is no other way to achieve it correctly, on any
operating system.  I'd rather we just didn't bother

khm

Re: [9front] [PATCH] rio: resize border and scrollbar based on font

[Stanley Lieber]

On May 10, 2024 10:33:49 AM EDT, Stanley Lieber <sl@stanleylieber.com> wrote:
>On May 10, 2024 10:21:55 AM EDT, ori@eigenstate.org wrote:
>>Quoth Stanley Lieber <sl@stanleylieber.com>:
>>> On May 10, 2024 10:10:29 AM EDT, Jacob Moody <moody@posixcafe.org> wrote:
>>> >On 5/10/24 01:20, Kurt H Maier wrote:
>>> >> On Thu, May 09, 2024 at 07:14:06PM -0500, Jacob Moody wrote:
>>> >>>
>>> >>> we do not currently do any sort of scaling in the UI for larger displays.
>>> >>> I think we should be looking at a more general solution to this problem,
>>> >> 
>>> >> scrollbars and borders should be arguments passed to rio and then
>>> >> exposed in env or elsewhere
>>> >> 
>>> >> every other attempt at 'general solutions' to ui scaling have been
>>> >> miserable goddamn failures and I really really don't want to live
>>> >> through it again
>>> >> 
>>> >> khm
>>> >
>>> >Alright then where's you're code for a solution here? I don't
>>> >want arguments to every fucking program for scaling.
>>> >
>>> >
>>> 
>>> rio provides the borders, so every program in that rio that uses rio's borders would inherit the same settings.
>>> 
>>> sl
>>
>>this is, unfortunately, not true, and is one of the uglier
>>warts in rio.
>>
>>Both rio and the programs agree by convention that rio will
>>paint into the outermost 4 pixels of the window.
>>
>>Programs will explicitly subtract 4 pixels from their drawing
>>region, which rio will later paint over. Unless they're running
>>outside of rio, in which case they will subtract off 0 pixels.
>>
>>
>
>i don't think this really contradicts what i said (the programs are still tacitly relying on rio's border behavior), but yeah, this falls under that situation where a lot of stuff kind of hodge-podge decides how much of rio's behavior to anticipate, and what to throw away in favor of managing its own graphical business.
>
>sl
>

haha, wait, i see what you mean. four pixels is four pixels. 

sl

Re: [9front] [PATCH] rio: resize border and scrollbar based on font

[Stanley Lieber]

On May 10, 2024 10:21:55 AM EDT, ori@eigenstate.org wrote:
>Quoth Stanley Lieber <sl@stanleylieber.com>:
>> On May 10, 2024 10:10:29 AM EDT, Jacob Moody <moody@posixcafe.org> wrote:
>> >On 5/10/24 01:20, Kurt H Maier wrote:
>> >> On Thu, May 09, 2024 at 07:14:06PM -0500, Jacob Moody wrote:
>> >>>
>> >>> we do not currently do any sort of scaling in the UI for larger displays.
>> >>> I think we should be looking at a more general solution to this problem,
>> >> 
>> >> scrollbars and borders should be arguments passed to rio and then
>> >> exposed in env or elsewhere
>> >> 
>> >> every other attempt at 'general solutions' to ui scaling have been
>> >> miserable goddamn failures and I really really don't want to live
>> >> through it again
>> >> 
>> >> khm
>> >
>> >Alright then where's you're code for a solution here? I don't
>> >want arguments to every fucking program for scaling.
>> >
>> >
>> 
>> rio provides the borders, so every program in that rio that uses rio's borders would inherit the same settings.
>> 
>> sl
>
>this is, unfortunately, not true, and is one of the uglier
>warts in rio.
>
>Both rio and the programs agree by convention that rio will
>paint into the outermost 4 pixels of the window.
>
>Programs will explicitly subtract 4 pixels from their drawing
>region, which rio will later paint over. Unless they're running
>outside of rio, in which case they will subtract off 0 pixels.
>
>

i don't think this really contradicts what i said (the programs are still tacitly relying on rio's border behavior), but yeah, this falls under that situation where a lot of stuff kind of hodge-podge decides how much of rio's behavior to anticipate, and what to throw away in favor of managing its own graphical business.

sl

Re: [9front] [PATCH] rio: resize border and scrollbar based on font

[Stanley Lieber]

On May 10, 2024 10:20:19 AM EDT, Jacob Moody <moody@posixcafe.org> wrote:
>On 5/10/24 09:16, Stanley Lieber wrote:
>> On May 10, 2024 10:10:29 AM EDT, Jacob Moody <moody@posixcafe.org> wrote:
>>> On 5/10/24 01:20, Kurt H Maier wrote:
>>>> On Thu, May 09, 2024 at 07:14:06PM -0500, Jacob Moody wrote:
>>>>>
>>>>> we do not currently do any sort of scaling in the UI for larger displays.
>>>>> I think we should be looking at a more general solution to this problem,
>>>>
>>>> scrollbars and borders should be arguments passed to rio and then
>>>> exposed in env or elsewhere
>>>>
>>>> every other attempt at 'general solutions' to ui scaling have been
>>>> miserable goddamn failures and I really really don't want to live
>>>> through it again
>>>>
>>>> khm
>>>
>>> Alright then where's you're code for a solution here? I don't
>>> want arguments to every fucking program for scaling.
>>>
>>>
>> 
>> rio provides the borders, so every program in that rio that uses rio's borders would inherit the same settings.
>> 
>> sl
>
>There are assumptions about the window size in other places of the code, that's what I was talking about.
>Look at /sys/include/draw.h:/BorderWidth/, there is code that currently relies on it being 4 pixels as a constant.
>
>

oh yeah, i know, i've run into this all over the place.

the ml may be distributing our messages out of order. check out my longer reply to this thread whenever you get it.

sl

Re: [9front] [PATCH] rio: resize border and scrollbar based on font

[ori]

Quoth Stanley Lieber <sl@stanleylieber.com>:
> On May 10, 2024 10:10:29 AM EDT, Jacob Moody <moody@posixcafe.org> wrote:
> >On 5/10/24 01:20, Kurt H Maier wrote:
> >> On Thu, May 09, 2024 at 07:14:06PM -0500, Jacob Moody wrote:
> >>>
> >>> we do not currently do any sort of scaling in the UI for larger displays.
> >>> I think we should be looking at a more general solution to this problem,
> >> 
> >> scrollbars and borders should be arguments passed to rio and then
> >> exposed in env or elsewhere
> >> 
> >> every other attempt at 'general solutions' to ui scaling have been
> >> miserable goddamn failures and I really really don't want to live
> >> through it again
> >> 
> >> khm
> >
> >Alright then where's you're code for a solution here? I don't
> >want arguments to every fucking program for scaling.
> >
> >
> 
> rio provides the borders, so every program in that rio that uses rio's borders would inherit the same settings.
> 
> sl

this is, unfortunately, not true, and is one of the uglier
warts in rio.

Both rio and the programs agree by convention that rio will
paint into the outermost 4 pixels of the window.

Programs will explicitly subtract 4 pixels from their drawing
region, which rio will later paint over. Unless they're running
outside of rio, in which case they will subtract off 0 pixels.

Re: [9front] [PATCH] rio: resize border and scrollbar based on font

[Jacob Moody]

On 5/10/24 09:16, Stanley Lieber wrote:
> On May 10, 2024 10:10:29 AM EDT, Jacob Moody <moody@posixcafe.org> wrote:
>> On 5/10/24 01:20, Kurt H Maier wrote:
>>> On Thu, May 09, 2024 at 07:14:06PM -0500, Jacob Moody wrote:
>>>>
>>>> we do not currently do any sort of scaling in the UI for larger displays.
>>>> I think we should be looking at a more general solution to this problem,
>>>
>>> scrollbars and borders should be arguments passed to rio and then
>>> exposed in env or elsewhere
>>>
>>> every other attempt at 'general solutions' to ui scaling have been
>>> miserable goddamn failures and I really really don't want to live
>>> through it again
>>>
>>> khm
>>
>> Alright then where's you're code for a solution here? I don't
>> want arguments to every fucking program for scaling.
>>
>>
> 
> rio provides the borders, so every program in that rio that uses rio's borders would inherit the same settings.
> 
> sl

There are assumptions about the window size in other places of the code, that's what I was talking about.
Look at /sys/include/draw.h:/BorderWidth/, there is code that currently relies on it being 4 pixels as a constant.

Re: [9front] [PATCH] rio: resize border and scrollbar based on font

[Stanley Lieber]

On May 10, 2024 10:10:29 AM EDT, Jacob Moody <moody@posixcafe.org> wrote:
>On 5/10/24 01:20, Kurt H Maier wrote:
>> On Thu, May 09, 2024 at 07:14:06PM -0500, Jacob Moody wrote:
>>>
>>> we do not currently do any sort of scaling in the UI for larger displays.
>>> I think we should be looking at a more general solution to this problem,
>> 
>> scrollbars and borders should be arguments passed to rio and then
>> exposed in env or elsewhere
>> 
>> every other attempt at 'general solutions' to ui scaling have been
>> miserable goddamn failures and I really really don't want to live
>> through it again
>> 
>> khm
>
>Alright then where's you're code for a solution here? I don't
>want arguments to every fucking program for scaling.
>
>

rio provides the borders, so every program in that rio that uses rio's borders would inherit the same settings.

sl

Re: [9front] [PATCH] rio: resize border and scrollbar based on font

[Jacob Moody]

On 5/10/24 01:20, Kurt H Maier wrote:
> On Thu, May 09, 2024 at 07:14:06PM -0500, Jacob Moody wrote:
>>
>> we do not currently do any sort of scaling in the UI for larger displays.
>> I think we should be looking at a more general solution to this problem,
> 
> scrollbars and borders should be arguments passed to rio and then
> exposed in env or elsewhere
> 
> every other attempt at 'general solutions' to ui scaling have been
> miserable goddamn failures and I really really don't want to live
> through it again
> 
> khm

Alright then where's you're code for a solution here? I don't
want arguments to every fucking program for scaling.

Re: [9front] [PATCH] rio: resize border and scrollbar based on font

[Kurt H Maier]

On Thu, May 09, 2024 at 07:14:06PM -0500, Jacob Moody wrote:
> 
> we do not currently do any sort of scaling in the UI for larger displays.
> I think we should be looking at a more general solution to this problem,

scrollbars and borders should be arguments passed to rio and then
exposed in env or elsewhere

every other attempt at 'general solutions' to ui scaling have been
miserable goddamn failures and I really really don't want to live
through it again

khm

Re: [9front] [PATCH] rio: resize border and scrollbar based on font

[sl]

> Additionally this is a bandaid to an otherwise general problem. That being
> we do not currently do any sort of scaling in the UI for larger displays.
> I think we should be looking at a more general solution to this problem,
> I'd prefer to not have to make UI scaling become the onerous of every
> single graphical program.

yes, please.

sl

Re: [9front] [PATCH] rio: resize border and scrollbar based on font

[Jacob Moody]

I don't think this will work how you want it to.
There are unfortunately assumptions in other parts of the code regarding the
rio border size so we can not change it on the fly without communicating it to
that other code.

Additionally this is a bandaid to an otherwise general problem. That being
we do not currently do any sort of scaling in the UI for larger displays.
I think we should be looking at a more general solution to this problem,
I'd prefer to not have to make UI scaling become the onerous of every
single graphical program.

[9front] [PATCH] rio: resize border and scrollbar based on font

[Romano]

when using large fonts the scroll bar is aberrantly small, as is
the border size. initialize the border widths and scroll widths
based on the font size. set a minimum value based on existing
hard-coded values.
---
diff 025a2d172ebfe36bc0da32f5712dd250916c73f1 e51d4aa069548de51d0e88a6d621d278e9138cd0
--- a/sys/src/cmd/rio/dat.h
+++ b/sys/src/cmd/rio/dat.h
@@ -46,11 +46,11 @@
 
 enum
 {
-	Selborder		= 4,		/* border of selected window */
-	Unselborder	= 1,		/* border of unselected window */
-	Scrollwid 		= 12,		/* width of scroll bar */
-	Scrollgap 		= 4,		/* gap right of scroll bar */
-	BIG			= 3,		/* factor by which window dimension can exceed screen */
+	Minselborder	= 4,		/* minimum border of selected window */
+	Minunselborder	= 1,		/* minimum border of unselected window */
+	Minscrollwid 	= 12,		/* minimum width of scroll bar */
+	Minscrollgap 	= 4,		/* minimum gap right of scroll bar */
+	BIG		= 3,		/* factor by which window dimension can exceed screen */
 	TRUE		= 1,
 	FALSE		= 0,
 };
@@ -341,3 +341,8 @@
 int		messagesize;		/* negotiated in 9P version setup */
 int		shiftdown;
 int		debug;
+int 		Borderwid;		/* border width of window */
+int 		Selborder;		/* border of selected window */
+int 		Unselborder;		/* border of unselected window */
+int 		Scrollwid;		/* width of scroll bar */
+int 		Scrollgap;		/* gap right of scroll bar */
--- a/sys/src/cmd/rio/data.c
+++ b/sys/src/cmd/rio/data.c
@@ -185,6 +185,16 @@
 };
 
 void
+fontinit(void)
+{
+	Borderwid = ceil(stringwidth(font, "0") / 4) > Borderwidth ? ceil(stringwidth(font, "0") / 4) : Borderwidth;
+	Selborder = ceil(stringwidth(font, "0") / 2) > Minselborder ? ceil(stringwidth(font, "0") / 2) : Minselborder;
+	Unselborder = ceil(stringwidth(font, "0") / 8) > Minunselborder ? ceil(stringwidth(font, "0") / 8) : Minunselborder;
+	Scrollwid = ceil(stringwidth(font, "0") * 1.5) > Minscrollwid ? ceil(stringwidth(font, "0") * 1.5) : Minscrollwid;
+	Scrollgap = ceil(stringwidth(font, "0") / 2) > Minscrollgap ? ceil(stringwidth(font, "0") / 2) : Minscrollgap;
+}
+
+void
 iconinit(void)
 {
 	background = allocimage(display, Rect(0,0,1,1), screen->chan, 1, 0x777777FF);
--- a/sys/src/cmd/rio/fns.h
+++ b/sys/src/cmd/rio/fns.h
@@ -16,6 +16,7 @@
 void	error(char*);
 void	killprocs(void);
 int	shutdown(void*, char*);
+void	fontinit(void);
 void	iconinit(void);
 void	*erealloc(void*, uint);
 void *emalloc(uint);
--- a/sys/src/cmd/rio/rio.c
+++ b/sys/src/cmd/rio/rio.c
@@ -182,6 +182,7 @@
 		fprint(2, "rio: can't open display: %r\n");
 		exits("display open");
 	}
+	fontinit();
 	iconinit();
 
 	exitchan = chancreate(sizeof(int), 0);
@@ -951,10 +952,10 @@
 	}
 	if(col != nil){
 		r = canonrect(r);
-		drawedge(&b[0], col, Rect(r.min.x, r.min.y, r.min.x+Borderwidth, r.max.y));
-		drawedge(&b[1], col, Rect(r.min.x+Borderwidth, r.min.y, r.max.x-Borderwidth, r.min.y+Borderwidth));
-		drawedge(&b[2], col, Rect(r.max.x-Borderwidth, r.min.y, r.max.x, r.max.y));
-		drawedge(&b[3], col, Rect(r.min.x+Borderwidth, r.max.y-Borderwidth, r.max.x-Borderwidth, r.max.y));
+		drawedge(&b[0], col, Rect(r.min.x, r.min.y, r.min.x+Borderwid, r.max.y));
+		drawedge(&b[1], col, Rect(r.min.x+Borderwid, r.min.y, r.max.x-Borderwid, r.min.y+Borderwid));
+		drawedge(&b[2], col, Rect(r.max.x-Borderwid, r.min.y, r.max.x, r.max.y));
+		drawedge(&b[3], col, Rect(r.min.x+Borderwid, r.max.y-Borderwid, r.max.x-Borderwid, r.max.y));
 	}
 	lastcol = col;
 }
--- a/sys/src/cmd/rio/wctl.c
+++ b/sys/src/cmd/rio/wctl.c
@@ -100,13 +100,13 @@
 	 * that includes the border on each side with an extra pixel
 	 * so that the text is still drawn
 	 */
-	if(Dx(r) < 100 || Dy(r) < 2*(Borderwidth+1)+font->height)
+	if(Dx(r) < 100 || Dy(r) < 2*(Borderwid+Unselborder)+font->height)
 		return 0;
 	/* window must be on screen */
 	if(!rectXrect(screen->r, r))
 		return 0;
 	/* must have some screen and border visible so we can move it out of the way */
-	if(rectinrect(screen->r, insetrect(r, Borderwidth)))
+	if(rectinrect(screen->r, insetrect(r, Borderwid)))
 		return 0;
 	return 1;
 }
@@ -148,8 +148,8 @@
 	static int i = 0;
 	int minx, miny, dx, dy;
 
-	dx = min(600, Dx(screen->r) - 2*Borderwidth);
-	dy = min(400, Dy(screen->r) - 2*Borderwidth);
+	dx = min(600, Dx(screen->r) - 2*Borderwid);
+	dy = min(400, Dy(screen->r) - 2*Borderwid);
 	minx = 32 + 16*i;
 	miny = 32 + 16*i;
 	i++;
--- a/sys/src/cmd/rio/wind.c
+++ b/sys/src/cmd/rio/wind.c
@@ -353,7 +353,7 @@
 
 	w->i = i;
 	w->mc.image = i;
-	r = insetrect(i->r, Selborder+1);
+	r = insetrect(i->r, Selborder+Unselborder);
 	w->scrollr = r;
 	w->scrollr.max.x = r.min.x+Scrollwid;
 	w->lastsr = ZR;
@@ -1249,7 +1249,7 @@
 
 	w = emalloc(sizeof(Window));
 	w->screenr = i->r;
-	r = insetrect(i->r, Selborder+1);
+	r = insetrect(i->r,Selborder+Unselborder);
 	w->i = i;
 	w->mc = *mc;
 	w->ck = ck;