From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Thu, 19 Mar 2020 21:27:16 -0400
From: sl@stanleylieber.com
To: 9front@9front.org
Subject: Re: [9front] mothra: proposal
In-Reply-To: <4683315B9C3DE021CEF6ED7969DA706A@eigenstate.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: transactional extensible CSS-aware standard method-oriented database 
Message-ID: <20200320012716.OfhD4afRUsqI283bTvaGHR8ysB4qXRf_JSwgV_b6lRg@z>

>>>		a.) our dejavusans is fuzzy as hell, and it sucks.
>>>			1.) users can easily choose their own fonts
>>>			and
>>>			recompile.
> 
> Hm. It looks fine on my screen -- but, sure.

it looked fine on my screen when i first made it, too; but that was in
drawterm, iirc running on windows.  if i understand correctly, the os was
making up for whatever makes it look fuzzy on native 9front.  namely,
weird interactions between how ttf2subf attempts to deal with antialiasing
and whatever is painting stuff on the screen.

the font itself was converted from ttf using a pre-cinap version of ttf2subf.

>>>	2.) backport my changes to libpanel to remove useless panel
>>>	borders and fake shadow lines.  stop underlining hyperlinks,
>>>	and instead make them blue.[0][1]
>>>		a.) perhaps in a saner manner.
>>>			1.) currently, lines, borders, bullet points,
>>>			etc., are defined in all sorts of different
>>>			places, not even entirely inside of libpanel.
>>>			i made no attempt to address this.  in rio,
>>>			we ended up putting all the color definitions
>>>			into one file, for easy modification.
> 
> I'm mostly ok with this, though I'm not a big fan of losing the
> "command" vs "body" visual distinction.

there are still a couple of lines separating those sections:

	http://plan9.stanleylieber.com/mothra/img/20200319.png

but i'm not opposed to tweaking this.  my biggest desire is to
minimize the ui's decoration, and emphasize the content.


> I also see lines drawn
> between menu items. I may want to tweak it a bit more to match
> the look of rio/sam windows.

that's fine with me, too.


>>>	3.) implement -b flag for dark mode, white-on-black text.[2]
>>>		a.) similar to rio -b, and vt -b.
>
> I don't like theming, but I like the propagation of dark mode
> flags even less. If we want this, libdraw needs to signal to
> programs which colors they should use, without a '-b' flag.

i'm not capable of implementing this.  also, by this logic we'd
need to change existing behavior of rio ad vt.  would we delete
the existing flags?  i'm not married to -b, but i'm also not
advocating full-blown theming.  (fwiw, i also don't quite
understand the vehement objection to it; standardizing it
in one library seems like the right approach.)


>>>[0] http://plan9.stanleylieber.com/src/mothra.white.tgz
>>>[1] http://plan9.stanleylieber.com/src/mothra.black.tgz
>>>[2] http://plan9.stanleylieber.com/mothra/img/20200310.png
> 
> Sending this out in the form of patches would make it easier
> to see what's changed.

there are extensive changes in my stuff, some not related to what
we're talking about above.  i don't think it would be especially
easier to understand my attempts to parse it all out, since you
can also just diff each one on your own machine.  it's been so
long since i wrote this stuff, and i barely understood what i
was doing anyway, that you will probably understand my code
better than i did/do, myself.

to think, many years ago i thought mothra would be a good entry
point to c.  my changes to it are still the most c i've ever
written in one place.


>> forgot:
>> 
>> 4.) plumb menu item.
>> 
>> sl
> 
> The plumb menu is a definite yes from me.

caveat:

mothra sometimes only knows relative urls (because some web
pages only offer relative urls as links), and relies on webfs
to figure out the correct request to match whatever it clicks
on.  this sometimes breaks plumbing, as i implemented it.

sl