plumb rules for page

plumb rules for page

[mycroftiv]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 1673 bytes --]

I was playing around with sharing plumber between different machines
and found something I don't understand in the default 'basic' plumber
ruleset as it relates to 'page'.  Relevant excerpt from
/sys/lib/plumb/basic follows:

# image files go to page
type is text
data matches '[a-zA-Z¡-￿0-9_\-.,/]+'
data matches '([a-zA-Z¡-￿0-9_\-.,/]+)\.(jpe?g|JPE?G|gif|GIF|tiff?|TIFF?|ppm|PPM|bit|BIT|png|PNG|pgm|PGM|bmp|BMP|yuv|YUV)'
arg isfile	$0
plumb to image
plumb client page -wi

# page bookmarks
type is text
data matches '(([a-zA-Z¡-￿0-9_\-.,/]+)\.(ps|PS|eps|EPS|pdf|PDF|dvi|DVI|doc|DOC|epub|EPUB|cb[tz]|CB[TZ]))!(.+)'
arg isfile	$1
data set	$file
attr add	addr=$4
plumb to image
plumb start page -wij $0 $file

# postscript/pdf/dvi/doc go to page but not over the a plumb port
# the port is here for reference but is unused
type is text
data matches '[a-zA-Z¡-￿0-9_\-.,/]+'
data matches '([a-zA-Z¡-￿0-9_\-.,/]+)\.(ps|PS|eps|EPS|pdf|PDF|dvi|DVI|doc|DOC|epub|EPUB|cb[tz]|CB[TZ])'
arg isfile	$0
plumb to postscript
plumb start page -w $file

My question is, why do we send image files to a running page over the
plumb port, but not ps/pdf type files?  We send page bookmarks to
running page via the plumb port, but not standard files.  It is clear
from the comments that this is a delibrate decision, is there a good
reason for it?  From my perspective, the "plumb to postscript" in the
final ruleset shown here should be "plumb to image" to make all the
behavior consistent.

It's obviously a trivial point and easy to change if you want to, but
if there isn't a justification for this divergence in behavior,
perhaps we should just standardize it?

-mycroftiv

Re: [9front] plumb rules for page

[Steve Simon]

The effect is useful.

if you plumb multiple images (e.g. from nedmail) then they appear in a single instance
of page as different pages withing page (if you get my meaning). merging multiple
PDFs could get confusing, and having multiple page instances each containing
just one image could be frustrating.

it is non-othogonal but feels ok (to me) in reality.

-Steve

Re: [9front] plumb rules for page

[Stanley Lieber]

i very much prefer a separate instance of page(1) for each document:

- pdf (and other large files) often get stuck, don’t render properly, or otherwise muck up the instance.

- documents (especially images) are rarely the same size, so the existing window’s dimensions are rarely adequate.

- it’s usually desirable to be able to see all, or at least some of the open documents on the screen at the same time.

on my systems i also plumb urls to a new mothra in a new window.

i can imagine uses for always opening items in the same window, but for me they’re rare.

sl

Re: [9front] plumb rules for page

[Ethan Grammatikidis]

On Fri, Jan 19, 2018, at 3:53 PM, Steve Simon wrote:
> 
> it is non-othogonal but feels ok (to me) in reality.

Indeed. I've done a lot of thinking about window systems over the years, stemming from my desire for orthogonality and frustration with exactly this sort of thing. While I don't have the details in mind now, I remember concluding orthogonality is actually undesirable in this case of "opening files" with a multiplexed display. I think it's impossible to write one rule to cover all reasonable use cases. At least with the plumber we have considerable control over the exact behavior.


-- 
The lyf so short, the craft so long to lerne. -- Chaucer

Re: [9front] plumb rules for page

[Ethan Grammatikidis]

Incidentally, when I was using 9front as much as I could, I would open a separate rio window with its own instance of the plumber for each of my projects or areas of interest. If using multiple reference books within one window, I would start additional plumbers. In this use, opening things in the existing window was sometimes optimal and usually the least bad case. (I really believe there is no good solution for all reasonable cases.)