On July 21, 2018 8:21:10 AM "Ethan A. Gardener" <[email protected]> wrote:
I just had to crop a bunch of images in the Gimp, and recalled how much I
prefer doing it in Plan 9; it's so much less frustrating. In the Gimp, it's
either a matter of estimating numbers (for a quick, casual job on visual
media), or select, copy, paste into new window. In the latter case, when
you save it, you have to find the directory and the file8749832710473name;
not fun. Also, I'm not practised at this; I'm no good at cropping with my
brain, so I had to zoom, resize the window, and select very carefully so
selecting didn't move the image in the window.
In Plan 9, which isn't even made for the job, it's not without its
frustrations, but it's got fewer of them than the Gimp. Open the image in
page; use the plumber or otherwise enter the full path so you can
copy/paste it later. Zoom and adjust the window as you like. In another
window, grep for the filename (or the directory, or whatever,) in
/dev/wsys/*/label, and type cd and send the directory part. (Of course,
copy/paste or send the file name.) Then:
crop -i 4 window | topng > path/filename.png
This is the part where you'll likely want to copy the full original path.
That's one done. On to the next image, which presumably is open in the same
instance of page so you don't have to cd or anything. `cat label` to get
its full name and path. (It's possible only 9front's page puts the path in
the label, I don't know.)
To be fair, if you're using a command line, you might as well be using
ImageMagick (not criticizing your points or anything, just playing devil's
advocate).
It's an operating system with few pretensions and only clunky image editing
tools, versus a powerful two-decade-mature image editing suite. Loading and
saving the files is no worse in Plan 9 than it is in the Gimp with its
oh-so-modern file selector, and the actual cropping part is easier in Plan 9!
If anyone's waiting for news of my OS where everything is done from an
interpreter prompt, I got distracted for a while but I'm on it again now.
I'm staying with Forth but looking at alternatives to swap drop and roll --
I mean stack manipulation primitives. Not to start a discussion here, but
I've decided it will have a single tree of names for all permanent storage
despite supporting architectures without a filesystem. Disk blocks could be
a directory of numbers under /b0, /b1 etc. OFW's non-volatile environment
variables could be a single-level directory under /nv. Actual local
filesystems, including the host's, could go under /f. Perhaps other
resources could go in the same tree as virtual files, but I'm not building
that bridge until I see the river. It's off topic for this list, so perhaps
mail replies to me privately?
While I'm replying here, might as well point out that, if you're going to
do this, I think one thing that could maybe be interesting would be for the
files to potentially contain rich data, not just plain text? Kind of like
TempleOS or systemd's journal does.
Any suggestions for a mailing list provider? My primary requirement is low
maintenance. I see many projects use Google Groups, but would like
suggestions for others if you have them.
Google Groups and Freelist are the best. Google Groups has a terrible UI
but also has better spam filters IME.
--
The lyf so short, the craft so long to lerne. -- Chaucer
