[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

a patch for xpaint

I've written a new operator/tool for xpaint. Do have a look, it's 
as free as xpaint. Here's the READMEquill from   xpaint2.5.1quill.tar
on my page at http://cqi.com/~humbubba

Howdy :o)

Rick Hohensee       http://cqi.com/~humbubba   rickh@capaccess.org
humbubba@cqi.com    colorg on IRC ( EFnet )    D.C. area, USA

Nov. 1997

This archive contains xpaint 2.51 with a bunch of modifications
I wrote, featuring the "quill" operator. 

While working on quill I got a bit carried away and made some
other changes to xpaint. I changed some of the text in various 
widgets to words which seem more self-explanatory to me,
I extended the intro section of the help text, and I painted a
bunch of new tool icons, usually using the tool the icon
represents, at least in part. I think this makes xpaint more inviting. 

quill does velocity emulation of mouse motion. It eliminates the
straight line segments you get with the pencil-related tools 
when you move the mouse quickly. xpaint+quill is the only free
paint program I know of that does mouse motion smoothing.

quill is at demo level at this point. It only works with a solid
color in the primary palette, it doesn't do undo, it has no help,
and it only has one "nib". It acts kind of like ink. It "bleeds" a
bit a slow speeds, and skips a bit at high speeds. It does some
really wacky sinusoidal aliasing with "snap" on. But it's quite 
usable, and adds substantially to xpaint's freehand capability.  

quill got an accolade already. I sent some quill output ( with
flood-filling with fractal fill, sig.gif) to a guy on IRC and he said
"This is xpaint?"   "Looks nice."       ( thanks, webart :o)

My method to calculate a curve between mouse-motion event points
must use XDrawPoints, rather than the "higher-level" X calls
most of the other xpaint tools use. This means more X calls for 
the same amount of ink, and then there's the curve calculation.
This also means our nib, which is the quill analog of a brush,
has to be presented to X as an array. Stubs for more nibs are
in place, since the array I give XDrawPoints is a sub-array of
a 5-nib array. ( You may notice some compiler warnings related to 
this.) The data is there for nibs of 5 different slopes,
up to 16 pixels in size/length. The current nib is 60 degrees off of
horizontal, with an extra pixel on the side to make quill strokes
more connected for flood-filling. The nib data is set up for
the XDrawPoints CoordModePrevious mode.
The curving algorithm is a kludge of my very own. It's all integer,
and now uses shifts instead of multiplies and divides in the inner-most
loop. This cost us an additional for-loop to set up the "divisor". 
It's quite fast enough on my 486, except with fatbits. I fear
what adding undo capability would do to it's performance though.
It would generate a huge undo buffer, I suspect. And bigger nibs
might slow it down, but only in linear proportion to size.

I just compiled this and it works. When I'm done writing this file
I'm gonna go do a    make clean   and make a .tgz out of the dir,
without this file. Then I'm gonna tar  the .tgz with this file. 
If you unpacked the archive and you got this file and a sub-archive
I'm telling the truth (I might also stick some .gifs in at this level). 
If so, you should be able to unpack the sub-archive,
cd into it's top dir, and do   make  . Maybe you'll have to do xmkmf
first, also. My box is a 486 Linux 2.0.30.  xpaint uses only standard X
libs, e.g. the Xaw stuff. I use gcc.

click on the purple-and-red icon and paint. If the default output
looks a little raw, hit it with the despeckle filter. On my box
I like to decelerate the mouse by 2 or 4, e.g.    xset m 1/2  
(or is it -m ?). I have several mouse speeds in my window manager's
"hotlist" popup.

Because I need gainful employment, and quill is resume-ware.
Because free paint programs, and Linux, need a feature like quill.
Because I'm very into calligraphic pens. I am an accomplished doodler.
Because I need something to point at that I wrote in C. ( I prefer
	Forth, when it's feasible.) 
Because this pertains to some other ideas I have.
Because I hope this will proliferate better than some of my more arcane 
	work has.
Because this is more "real" than connecting mouse motion event points
	with straight lines.

WHY-icon tweaks
Because it was fun and easy.
Because xpaint didn't indicate it's power to someone just glancing at it.
Because I'm interested in documentation and self-documentation, personally
	and as a possible specialty. 

I hope the authors of xpaint find some of this worth keeping. I hope also,
that someone more familiar with the Xt and Xaw stuff will give me some tips
on fleshing out the features of quill, or just go ahead and do it. I guess
I'm an old-fashioned bit-banger. I don't enjoy OOPs at all. I could just make 
each nib a separate operator( in fact, many Linux users could), but that would 
be bloat, which xpaint avoids admirably. 

Here's a few ideas that I have no plans to do, but that I suspect someone more
familiar with the totality of xpaint and the X libs might be able to do with 
a not-huge effort, and without bloat. 
	Break up the menus on the painting/canvas window manu bar by the separators
		in the pull-downs. There's plenty of room for more menu buttons
		on the canvas window. Menu titles? "canvas" "clipboard", "region"
		"filters", "resize" "view" etc. This would also be a good 
		place for a "mousespeed" widget. 
	A translucent clipboard paste ( did I overlook that?) could serve as 
		the poor man's "channels", and might be more intuitive.
	If xpaint could load and store specific parts of a file isn't it only a
		short hop from there to a (full color) bitmapped font editor?
	Isn't the "save palette" widget set missing a function? Or shouldn't
		load palette delete the current palette before loading?
 	You might as well de-optionize fractal-fill. It's nyce.
	and on and on...

quill has taught me a couple things, or confirmed some things. X is pretty
lucid. C makes all of Linux your canvas, but I still dream of a Forth OS.
make  only has to   make   the parts that didn't work on the last go-round,
so re-compiling a part of a big program isn't as bad as one might think.

THANKS to Koblas, Torsten and all other contributors for such a nice program
at such a nice price.

COPYRIGHT quill 19971104 Richard Allen Hohensee
quill is a derived work of xpaint. This distribution of the quill operator 
sourcecode and the associated icons and other changes to operator.c and ops.h are 
hereby released for any redistribution, subject to author aknowledgement, said
authorship aknowledgement being readable by an end-user at some point in said

If you use my curve algorithm, do mention me, eh? After all, I didn't
patent it :o)

Rick Hohensee       http://cqi.com/~humbubba   rickh@capaccess.org
humbubba@cqi.com    colorg on IRC ( EFnet )    D.C. area, USA

TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .

Reply to: