Re: [9front] mothra: proposal

Re: [9front] mothra: proposal

[ori]

I'll split this into separate patches for separate review/testing,
and we can decide how to proceed change by change. It's going to
take me a few days.
 
>> 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'll post a tweaked version, keeps the bluegreen background
for the url section, and removes the lines between the menu
items.

>> 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.)

I think you underestimate yourself. And, yes, if we have a
"dark mode", I'd want to remove '-b'.

> 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

Mm. we can probably read the 'parsed/url' before plumbing, but
I'm more interested in being able to plumb non-url text from
the page.

Re: [9front] mothra: proposal

[Stanley Lieber]

On March 19, 2020 11:00:23 PM EDT, ori@eigenstate.org wrote:
>
>I'll split this into separate patches for separate review/testing,
>and we can decide how to proceed change by change. It's going to
>take me a few days.
> 
>>> 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'll post a tweaked version, keeps the bluegreen background
>for the url section, and removes the lines between the menu
>items.
>
>>> 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.)
>
>I think you underestimate yourself. And, yes, if we have a
>"dark mode", I'd want to remove '-b'.
>
>> 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
>
>Mm. we can probably read the 'parsed/url' before plumbing, but
>I'm more interested in being able to plumb non-url text from
>the page.

my plumb rules open urls in a fresh instance of mothra. my most frequent use of the plumb menu item is as a poor man's "open in new window," but i'm definiely interested in being able to plumb arbitrary text selections as well.

sl

Re: [9front] mothra: proposal

[umbraticus]

Default colours work for me, and I haven't checked out how libtheme
works, but it occured to me that programs often have an array of
colours, which you could prime with an rc list thus:

; colours = (ff aaaaaaff ffffffff) myprog	# -b

Sure, you need to look at the source to work out which colour is
which, but you don't have to edit it and recompile, just put your
weird preferences in a script.  If that's what you're into.
envcolours() could go in the lib... eg: (excuse my spelling)

#include <u.h>
#include <libc.h>
#include <draw.h>
enum{ONE, TWO, THREE, NCOL};
ulong rgb[NCOL] = {[ONE] 0xff0000ff, [TWO] 0x00ff00ff, [THREE] 0x0000ffff};
void envcolours(Image **a, int n){
	char *s;
	int i;
	if(s = getenv("colours"))
		for(i = 0, s = strtok(s, " "); i < n && s != nil; i++, s = strtok(nil, " "))
			rgb[i] = strtoul(s, nil, 16);
}
void main(int, char**){
	Image *col[NCOL];
	Rectangle r;
	int i;
	if(initdraw(nil, nil, "colours") < 0) sysfatal("initdraw: %r");
	r = Rect(0, 0, 1, 1);
	envcolours(col, NCOL);
	for(i = 0; i < NCOL; i++)
		if((col[i] = allocimage(display, Rect(0,0,1,1), RGBA32, 1, rgb[i])) == nil)
			sysfatal("allocimage: %r");
	r = screen->r;
	i = Dy(r) / 6;
	draw(screen, r, col[ONE], nil, ZP);
	r = insetrect(r, i);
	draw(screen, r, col[TWO], nil, ZP);
	r = insetrect(r, i);
	draw(screen, r, col[THREE], nil, ZP);
	flushimage(display, 1);
	sleep(5000);
}

umbraticus

Re: [9front] mothra: proposal

[ori]

Finally got around to preparing patches, which should apply
cleanly on top of 9front mothra. However:

> 	3.) implement -b flag for dark mode, white-on-black text.[2]
> 		a.) similar to rio -b, and vt -b.
> 			1.) users are free to implement any desired
> 			schemes beyond default and -b by configuring
> 			the included .c files.

I didn't see this change in the tarballs. There just seemed to
be two different mothras, one with black and one with white
schemes.

Patches attached:

font.patch: Change font back to original.
panel.patch: Reduce drawing clutter from libpanel
monochrome.patch; Make the color scheme monochrome (all-white)
plumb.patch: add plumber

TODO:
  - Make libpanel render a bit more in the style of rio and
    everything else.
  - Merge in a version of mothra with -b, if I get it.

Re: [9front] mothra: proposal

[ori]

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

Finally got around to preparing patches, which should apply
cleanly on top of 9front mothra. However:

> 	3.) implement -b flag for dark mode, white-on-black text.[2]
> 		a.) similar to rio -b, and vt -b.
> 			1.) users are free to implement any desired
> 			schemes beyond default and -b by configuring
> 			the included .c files.

I didn't see this change in the tarballs. There just seemed to
be two different mothras, one with black and one with white
schemes.

Patches attached:

font.patch: Change font back to original.
panel.patch: Reduce drawing clutter from libpanel
monochrome.patch; Make the color scheme monochrome (all-white)
plumb.patch: add plumber

TODO:
  - Make libpanel render a bit more in the style of rio and
    everything else.
  - Merge in a version of mothra with -b, if I get it.

[-- Attachment #2: Type: text/plain, Size: 1633 bytes --]

 From b28c15f43defdd85969d9fe4e9d5a9fb540239fb
From: Ori Bernstein <ori@eigenstate.org>
Date: Sun, 12 Apr 2020 11:32:48 -0700
Subject: [PATCH] restore original default fonts.

our dejavusans is fuzzy as hell, and it sucks.
users can easily choose their own fonts and
recompile.

diff -urN a/rdhtml.c b/rdhtml.c
--- a/rdhtml.c	Sun Apr 12 11:55:30 2020
+++ b/rdhtml.c	Sun Apr 12 11:32:48 2020
@@ -13,25 +13,26 @@
 	Font *font;
 	int space;
 }fontlist[4][4]={
-	"dejavusans/unicode.12", 0, 0,
-	"dejavusans/unicode.12", 0, 0,
-	"dejavusans/unicode.14", 0, 0,
-	"dejavusans/unicode.16", 0, 0,
+/* original */
+	"lucidasans/unicode.7", 0, 0,
+	"lucidasans/unicode.8", 0, 0,
+	"lucidasans/unicode.10", 0, 0,
+	"lucidasans/unicode.13", 0, 0,
 
-	"dejavusansit/unicode.12", 0, 0,
-	"dejavusansit/unicode.12", 0, 0,
-	"dejavusansit/unicode.14", 0, 0,
-	"dejavusansit/unicode.16", 0, 0,
+	"lucidasans/italicunicode.7", 0, 0,
+	"lucidasans/italicunicode.8", 0, 0,
+	"lucidasans/italicunicode.10", 0, 0,
+	"lucidasans/italicunicode.13", 0, 0,
 
-	"dejavusansbd/unicode.12", 0, 0,
-	"dejavusansbd/unicode.12", 0, 0,
-	"dejavusansbd/unicode.14", 0, 0,
-	"dejavusansbd/unicode.16", 0, 0,
+	"lucidasans/boldunicode.7", 0, 0,
+	"lucidasans/boldunicode.8", 0, 0,
+	"lucidasans/boldunicode.10", 0, 0,
+	"lucidasans/boldunicode.13", 0, 0,
 
-	"terminus/unicode.12", 0, 0,
-	"terminus/unicode.14", 0, 0,
-	"terminus/unicode.16", 0, 0,
-	"terminus/unicode.18", 0, 0,
+	"lucidasans/typeunicode.7", 0, 0,
+	"pelm/unicode.8", 0, 0,
+	"lucidasans/typeunicode.12", 0, 0,
+	"lucidasans/typeunicode.16", 0, 0,
 };
 
 Font *pl_whichfont(int f, int s, int *space){

[-- Attachment #3: Type: text/plain, Size: 6564 bytes --]

 From 8167f136aa08f34ef45577978b6bfda75f334d86
From: Ori Bernstein <ori@eigenstate.org>
Date: Sun, 12 Apr 2020 11:58:12 -0700
Subject: [PATCH] remove useless panel decoration.

stop underlining hyperlinks, and instead make them blue.

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.

diff -urN a/libpanel/draw.c b/libpanel/draw.c
--- a/libpanel/draw.c	Sun Apr 12 11:32:48 2020
+++ b/libpanel/draw.c	Sun Apr 12 11:58:12 2020
@@ -19,7 +19,7 @@
 	plldepth=ldepth;
 	pl_white=allocimage(display, Rect(0,0,1,1), screen->chan, 1, 0xFFFFFFFF);
 	pl_light=allocimagemix(display, DPalebluegreen, DWhite);
-	pl_dark =allocimage(display, Rect(0,0,1,1), screen->chan, 1, DPurpleblue);
+	pl_dark=allocimage(display, Rect(0,0,1,1), screen->chan, 1, DPurpleblue);
 	pl_black=allocimage(display, Rect(0,0,1,1), screen->chan, 1, 0x000000FF);
 	pl_hilit=allocimage(display, Rect(0,0,1,1), CHAN1(CAlpha,8), 1, 0x80);
 	if(pl_white==0 || pl_light==0 || pl_black==0 || pl_dark==0) return 0;
@@ -38,6 +38,13 @@
 }
 Rectangle pl_boxoutline(Image *b, Rectangle r, int style, int fill){
 	if(plldepth==0) switch(style){
+	case SUP:
+	case TUP:
+		pl_relief(b, pl_white, pl_white, r, BWID);
+		r=insetrect(r, BWID);
+		if(fill) draw(b, r, pl_white, 0, ZP);
+		else border(b, r, SPACE, pl_white, ZP);
+		break;
 	case UP:
 		pl_relief(b, pl_black, pl_black, r, BWID);
 		r=insetrect(r, BWID);
@@ -68,6 +75,13 @@
 		break;
 	}
 	else switch(style){
+	case SUP:
+	case TUP:
+		pl_relief(b, pl_white, pl_white, r, BWID);
+		r=insetrect(r, BWID);
+		if(fill) draw(b, r, pl_light, 0, ZP);
+		else border(b, r, SPACE, pl_white, ZP);
+		break;
 	case UP:
 		pl_relief(b, pl_white, pl_black, r, BWID);
 		r=insetrect(r, BWID);
@@ -97,7 +111,10 @@
 		else border(b, r, SPACE, pl_white, ZP);
 		break;
 	}
-	return insetrect(r, SPACE);
+	switch(style){
+	case SUP: return insetrect(r, SPACE-SPACE);
+	default: return insetrect(r, SPACE);
+	}
 }
 Rectangle pl_outline(Image *b, Rectangle r, int style){
 	return pl_boxoutline(b, r, style, 0);
diff -urN a/libpanel/event.c b/libpanel/event.c
--- a/libpanel/event.c	Sun Apr 12 11:32:48 2020
+++ b/libpanel/event.c	Sun Apr 12 11:58:12 2020
@@ -9,8 +9,10 @@
 	plkbfocus=g;
 }
 void plkeyboard(Rune c){
-	if(plkbfocus)
+	if(plkbfocus){
 		plkbfocus->type(plkbfocus, c);
+		flushimage(display, 1);
+	}
 }
 
 /*
@@ -45,4 +47,5 @@
 			g->flags&=~REMOUSE;
 		g->lastmouse=hit;
 	}
+	flushimage(display, 1);
 }
diff -urN a/libpanel/pldefs.h b/libpanel/pldefs.h
--- a/libpanel/pldefs.h	Sun Apr 12 11:32:48 2020
+++ b/libpanel/pldefs.h	Sun Apr 12 11:58:12 2020
@@ -17,7 +17,9 @@
  * States, also styles
  */
 enum{
-	UP,
+	SUP,	// scrollbar
+	TUP,	// textview
+	UP,	// deprecated
 	DOWN1,
 	DOWN2,
 	DOWN3,
diff -urN a/libpanel/popup.c b/libpanel/popup.c
--- a/libpanel/popup.c	Sun Apr 12 11:32:48 2020
+++ b/libpanel/popup.c	Sun Apr 12 11:58:12 2020
@@ -65,6 +65,7 @@
 			if(g->state!=DOWN){
 				if(pp->save!=0){
 					draw(g->b, p->r, pp->save, 0, p->r.min);
+					flushimage(display, 1);
 					freeimage(pp->save);
 					pp->save=0;
 				}
diff -urN a/libpanel/rtext.c b/libpanel/rtext.c
--- a/libpanel/rtext.c	Sun Apr 12 11:32:48 2020
+++ b/libpanel/rtext.c	Sun Apr 12 11:58:12 2020
@@ -175,7 +175,9 @@
 	Point lp, sp;
 	Rectangle dr;
 	Image *bb;
+	Image *pl_blue;
 
+	pl_blue=allocimage(display, Rect(0,0,1,1), RGB24, 1, 0x0000FFFF);
 	bb = b;
 	if(backup==0 || backup->chan!=b->chan || rectinrect(r, backup->r)==0){
 		freeimage(backup);
@@ -195,7 +197,6 @@
 		&& dr.min.x<r.max.x){
 			if(t->b){
 				draw(b, insetrect(dr, BORD), t->b, 0, t->b->r.min);
-				if(t->flags&PL_HOT) border(b, dr, 1, display->black, ZP);
 				if(t->flags&PL_STR) {
 					line(b, Pt(dr.min.x, dr.min.y), Pt(dr.max.x, dr.max.y),
 						Endsquare, Endsquare, 0,
@@ -214,7 +215,10 @@
 					pl_stuffbitmap(t->p, bb);
 			}
 			else{
-				string(b, dr.min, display->black, ZP, t->font, t->text);
+				if(t->flags&PL_HOT)
+					string(b, dr.min, pl_blue, ZP, t->font, t->text);
+				else
+					string(b, dr.min,display->black, ZP, t->font, t->text);
 				if(t->flags&PL_SEL)
 					pl_highlight(b, dr);
 				if(t->flags&PL_STR){
@@ -227,15 +231,6 @@
 					sp = Pt(dr.max.x, y);
 				} else
 					sp = ZP;
-				if(t->flags&PL_HOT){
-					int y = dr.max.y - 1;
-					if(lp.y != y)
-						lp = Pt(dr.min.x, y);
-					line(b, lp, Pt(dr.max.x, y),
-						Endsquare, Endsquare, 0,
-						display->black, ZP);
-					lp = Pt(dr.max.x, y);
-				} else
 					lp = ZP;
 				continue;
 			}
diff -urN a/libpanel/scrollbar.c b/libpanel/scrollbar.c
--- a/libpanel/scrollbar.c	Sun Apr 12 11:32:48 2020
+++ b/libpanel/scrollbar.c	Sun Apr 12 11:58:12 2020
@@ -16,7 +16,7 @@
 void pl_drawscrollbar(Panel *p){
 	Scrollbar *sp;
 	sp=p->data;
-	sp->interior=pl_outline(p->b, p->r, p->state);
+	sp->interior=pl_outline(p->b, p->r, SUP); /* SUP was p->state */
 	pl_sliderupd(p->b, sp->interior, sp->dir, sp->lo, sp->hi);
 }
 int pl_hitscrollbar(Panel *g, Mouse *m){
diff -urN a/libpanel/textview.c b/libpanel/textview.c
--- a/libpanel/textview.c	Sun Apr 12 11:32:48 2020
+++ b/libpanel/textview.c	Sun Apr 12 11:58:12 2020
@@ -47,7 +47,7 @@
 	Point size;
 
 	tp=p->data;
-	r=pl_outline(p->b, p->r, UP);
+	r=pl_outline(p->b, p->r, TUP);
 	twid=r.max.x-r.min.x;
 	if(twid!=tp->twid){
 		tp->twid=twid;
@@ -80,7 +80,7 @@
 	if(oldhitword==oldhitfirst)
 		pl_passon(oldhitword, m);
 	if(m->buttons&OUT)
-		p->state=UP;
+		p->state=PASSIVE;
 	else if(m->buttons&7){
 		p->state=DOWN;
 		tp->buttons=m->buttons;
@@ -100,7 +100,7 @@
 	}
 	else{
 		if(p->state==DOWN) hitme=1;
-		p->state=UP;
+		p->state=PASSIVE;
 	}
 	if(tp->hitfirst!=oldhitfirst || tp->hitword!=oldhitword){
 		plrtseltext(tp->text, tp->hitword, tp->hitfirst);
@@ -214,7 +214,7 @@
 	Textview *tp;
 	tp=v->data;
 	v->flags=flags|LEAF;
-	v->state=UP;
+	v->state=PASSIVE;
 	v->draw=pl_drawtextview;
 	v->hit=pl_hittextview;
 	v->type=pl_typetextview;
diff -urN a/libpanel/textwin.c b/libpanel/textwin.c
--- a/libpanel/textwin.c	Sun Apr 12 11:32:48 2020
+++ b/libpanel/textwin.c	Sun Apr 12 11:58:12 2020
@@ -136,7 +136,7 @@
 	er=t->text+last;
 	for(r=t->text+first,lp=t->loc+(first-t->top);r!=er;r++,lp++){
 		if(lp->y+t->hgt>t->r.max.y){
-			fprint(2, "chr %C, index %ld of %d, loc %d %d, off bottom\n",
+			fprint(2, "chr %C, index %lld of %d, loc %d %d, off bottom\n",
 				*r, lp-t->loc, t->bot-t->top, lp->x, lp->y);
 			return;
 		}

[-- Attachment #4: Type: text/plain, Size: 1039 bytes --]

 From 75ccd7dd8c6bb8b38312fb23dfa522e045a72f51
From: Ori Bernstein <ori@eigenstate.org>
Date: Sun, 12 Apr 2020 11:59:40 -0700
Subject: [PATCH] make mothra monochrome.

diff -urN a/libpanel/draw.c b/libpanel/draw.c
--- a/libpanel/draw.c	Sun Apr 12 11:58:12 2020
+++ b/libpanel/draw.c	Sun Apr 12 11:59:40 2020
@@ -17,9 +17,10 @@
 static Image *pl_white, *pl_light, *pl_dark, *pl_black, *pl_hilit;
 int pl_drawinit(int ldepth){
 	plldepth=ldepth;
+	/* mono */
 	pl_white=allocimage(display, Rect(0,0,1,1), screen->chan, 1, 0xFFFFFFFF);
-	pl_light=allocimagemix(display, DPalebluegreen, DWhite);
-	pl_dark=allocimage(display, Rect(0,0,1,1), screen->chan, 1, DPurpleblue);
+	pl_light=allocimage(display, Rect(0,0,1,1), screen->chan, 1, 0xFFFFFFFF);
+	pl_dark=allocimage(display, Rect(0,0,1,1), screen->chan, 1, 0x555555FF);
 	pl_black=allocimage(display, Rect(0,0,1,1), screen->chan, 1, 0x000000FF);
 	pl_hilit=allocimage(display, Rect(0,0,1,1), CHAN1(CAlpha,8), 1, 0x80);
 	if(pl_white==0 || pl_light==0 || pl_black==0 || pl_dark==0) return 0;

[-- Attachment #5: Type: text/plain, Size: 1994 bytes --]

 From 0f8e8c98177be7133908c55d68e816741d019f5c
From: Ori Bernstein <ori@eigenstate.org>
Date: Sun, 12 Apr 2020 12:07:37 -0700
Subject: [PATCH] Add plumb menu

diff -urN a/mothra.c b/mothra.c
--- a/mothra.c	Sun Apr 12 11:59:40 2020
+++ b/mothra.c	Sun Apr 12 12:07:37 2020
@@ -95,6 +95,7 @@
 	"moth mode",
 	"snarf",
 	"paste",
+	"plumb",
 	"search",
 	"save hit",
 	"hit list",
@@ -936,6 +937,7 @@
 		return url->fullname;
 	return url->reltext;
 }
+
 Url *copyurl(Url *u){
 	Url *v;
 	v=emalloc(sizeof(Url));
@@ -944,11 +946,13 @@
 	v->basename = strdup(u->basename);
 	return v;
 }
+
 void freeurl(Url *u){
 	free(u->reltext);
 	free(u->basename);
 	free(u);
 }
+
 void seturl(Url *url, char *urlname, char *base){
 	url->reltext = strdup(urlname);
 	url->basename = strdup(base);
@@ -956,6 +960,7 @@
 	url->tag[0] = 0;
 	url->map = 0;
 }
+
 Url* selurl(char *urlname){
 	Url *last;
 
@@ -1167,7 +1172,9 @@
 	plpaste(p);
 }
 void hit3(int button, int item){
+	char buf[1024];
 	char name[NNAME];
+	char *s;
 	Panel *swap;
 	int fd;
 	USED(button);
@@ -1199,9 +1206,27 @@
 		paste(plkbfocus);
 		break;
 	case 4:
-		search();
+		if(plkbfocus==nil || plkbfocus==cmd){
+			if(text==nil || text->snarf==nil || selection==nil)
+				return;
+			if((s=text->snarf(text))==nil)
+				s=smprint("%s", urlstr(selection));
+		}else
+			if((s=plkbfocus->snarf(plkbfocus))==nil)
+				return;
+		if((fd=plumbopen("send", OWRITE))<0){
+			message("can't plumb");
+			free(s);
+			return;
+		}
+		plumbsendtext(fd, "mothra", nil, getwd(buf, sizeof buf), s);
+		close(fd);
+		free(s);
 		break;
 	case 5:
+		search();
+		break;
+	case 6:
 		if(!selection){
 			message("no url selected");
 			break;
@@ -1221,11 +1246,11 @@
 		fprint(fd, "<p><a href=\"%s\">%s</a>\n", urlstr(selection), urlstr(selection));
 		close(fd);
 		break;
-	case 6:
+	case 7:
 		snprint(name, sizeof(name), "file:%s/hit.html", mkhome());
 		geturl(name, -1, 1, 0);
 		break;
-	case 7:
+	case 8:
 		if(confirm(3))
 			exits(0);
 		break;

Re: [9front] mothra: proposal

[Stanley Lieber]

On April 12, 2020 3:21:15 PM EDT, ori@eigenstate.org wrote:
>Finally got around to preparing patches, which should apply
>cleanly on top of 9front mothra. However:
>
>> 	3.) implement -b flag for dark mode, white-on-black text.[2]
>> 		a.) similar to rio -b, and vt -b.
>> 			1.) users are free to implement any desired
>> 			schemes beyond default and -b by configuring
>> 			the included .c files.
>
>I didn't see this change in the tarballs. There just seemed to
>be two different mothras, one with black and one with white
>schemes.
>
>Patches attached:
>
>font.patch: Change font back to original.
>panel.patch: Reduce drawing clutter from libpanel
>monochrome.patch; Make the color scheme monochrome (all-white)
>plumb.patch: add plumber
>
>TODO:
>  - Make libpanel render a bit more in the style of rio and
>    everything else.
>  - Merge in a version of mothra with -b, if I get it.

thanks! i did not actually implement -b, as such. my concept was roughly: mothra.white as default, and mothra.black as -b. the only difference between my mothra.white and mothra.black is (should be) the display colors.

sl

Re: [9front] mothra: proposal

[sl]

> Patches attached:
> 
> font.patch: Change font back to original.
> panel.patch: Reduce drawing clutter from libpanel
> monochrome.patch; Make the color scheme monochrome (all-white)
> plumb.patch: add plumber

working well here.

sl

Re: [9front] mothra: proposal

[Ethan Gardener]

On Fri, Mar 20, 2020, at 1:27 AM, sl@stanleylieber.com wrote:
>
> >>>	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.)

i'm much more opposed to flags than theming, personally. I've set a lot of x programs to dark colors, and some of them can't be done with files or x resources. i don't like to start a whole bunch of programs and leave them running, (or rather, i didn't at the time,) so i had these wrapper scripts which started programs with the options i wanted. (not just color, other things too.) writing those scripts was irritating, especially when i had to make a new one. 


> 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.

it could have been worse, you could have started with sam-samterm communications. i couldn't even begin to make heads or tails of that.

Re: [9front] mothra: proposal

[Stanley Lieber]

On March 18, 2020 7:49:16 PM EDT, sl@stanleylieber.com wrote:
>i've been maintaining forks of mothra for years.  i don't anticipate
>making more big changes any time soon, and i have zero time to
>continue applying the changes from 9front to my several forks.
>
>i propose to backport the following changes from my forks to 9front:
>
>	1.) restore original default fonts.
>		a.) our dejavusans is fuzzy as hell, and it sucks.
>			1.) users can easily choose their own fonts
>			and
>			recompile.
>
>	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.
>
>	3.) implement -b flag for dark mode, white-on-black text.[2]
>		a.) similar to rio -b, and vt -b.
>			1.) users are free to implement any desired
>			schemes beyond default and -b by configuring
>			the included .c files.
>
>caveat: i do not have a lot of faith in my own ability to backport
>these changes cleanly.
>
>volunteers are welcome.
>
>sl
>
>[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

forgot:

4.) plumb menu item.

sl

Re: [9front] mothra: proposal

[ori]

> On March 18, 2020 7:49:16 PM EDT, sl@stanleylieber.com wrote:
>>i've been maintaining forks of mothra for years.  i don't anticipate
>>making more big changes any time soon, and i have zero time to
>>continue applying the changes from 9front to my several forks.
>>
>>i propose to backport the following changes from my forks to 9front:

Thanks for doing the work. I'll take a look at the code soon,
but a first set of comments after testing it out:

>>	1.) restore original default fonts.
>>		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.

>>	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. 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.

>>	3.) implement -b flag for dark mode, white-on-black text.[2]
>>		a.) similar to rio -b, and vt -b.
>>			1.) users are free to implement any desired
>>			schemes beyond default and -b by configuring
>>			the included .c files.

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 know that this way lies bikeshedding. *sigh*.

>>caveat: i do not have a lot of faith in my own ability to backport
>>these changes cleanly.
>>
>>volunteers are welcome.
>>
>>sl
>>
>>[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.

> forgot:
> 
> 4.) plumb menu item.
> 
> sl

The plumb menu is a definite yes from me.

Re: [9front] mothra: proposal

[sl]

>>>		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