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.)
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?
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.
--
The lyf so short, the craft so long to lerne. -- Chaucer
