Options and Futures Paint
Paint tool
I miss a free good paint tool for X-Windows. I'm currently
using xpaint, which annoys me by (a) being too simple,
(b) being too buggy,
and (c) simply terminating when it runs out of memory.
Editor writers, if your program runs out of memory, give the user
a chance to save the files. This has been a public service
announcement. Thank you.
Perhaps the lack of a free industrial-strength paint tool is that
writing a paint tool, like the interest in visual programming,
is a rite of passage for beginning programmers; a simple paint
tool seems to be conceptually easy to program and to design.
A good paint tool quickly turns into a product.
Masking
The first problem everybody seems to be having with paint tools
is integrating geometry and pixel-oriented graphics.
What I would like to try is an approach similar to that regular
graphic artists use when they airbrush: cut the shape out of a foil
and then use the brush in the shape. That way, you
get both clear lines and intuitive artistic control.
The mask that one works through is editable just like a regular
drawing; one can use masks to make masks...
Plus, I get to steal from Xerox for the interfaces; they have
some experience with transparent tools, some of that should carry
to transparent documents.
(The equivalent of masking in 3D is texturizing. Paul
Haeberli has a paper about that.)
Polylines
Usually, paint tools let me draw shapes by specifying points through which a
curve is fit, or by specifying points that are simply connected.
Depending on which mode I choose, I get a wobbly cloud or a star.
What I really want to do is have one shape where I can, for each point,
specify whether this is a corner (like for a star) or just a point to lay
a spline through.
Functions
When I "draw" a pixel, I apply a function, from all planes to all
planes.
For example, drawing a pink line on one plane means copying pixels
from the pink plane to the line plane.
The function absolutely needs to be programmable.
I don't know yet how to make this both fast and understandable, but
it needs to be.
What is displayed on screen, of course, is also the result of
applying a function.
Perhaps have a graph of planes. At the nodes of the graph, functions
determine the output planes (above) from the input planes (below).
The functions are mathematical: if the input doesn't change, the
output doesn't change either. (Give optimization a chance.)
The graph is displayed, browse- and editable.
Viewing something on a screen is a function in a node; it outputs a
screen. If you add stuff above the screen, you simply don't see it.
By moving the screen around in the graph, you can look at different
aspects of the drawing.
Are there interaction primitives (like "drag-and-drop") for moving
things around in graphs? There are directories, but those are kind
of limited. I wonder what being able to quickly manipulate graphs
would feel like...
Pens
Pens are a function that maps the input coordinates of the user's
pointing device to invocations of the drawing function.
Those are the real first function.
The usual pixel-toggling drawing function then determines a shape
(e.g., a line) and applies the drawing function to the shape.
Others might draw parametrized geometry (a square, a circle with a
certain diameter.)
Again others might apply their own, more complicated functions parametrized
with time, e.g. to simulate the movement of a brush.
Spraycan
A spraycan injects color into the image.
That color absolutely needs to be mixed into the colors that are
already there - the sprinkling of colored pixels that is frequently
used to implement the spraycan is totally useless.
Parametrizable images
Transparency is a special case of parametrizable images.
One needs to support transparency, of course, and one needs to support
alpha factors, but what I would really like to do is support arbitrary
parametrizable images - have a paint program that outputs, if necessary,
a function rather than a fixed image.
I think one needs to look for larger-than-element parameters in
many things, not just in painted images. Take fonts,
for example; ``handwritten'' fonts should be composed from the
individual letters parametrized by the larger rhythm of the
line, with the strokes of the previous character, perhaps even
with the frequency of the word in the text.
Help lines
Another thing that would fall naturally out of the mask idea is
the possibility to have auxiliary elements - perspective lines, geometric
constructions, etc. - that are not part of the finished picture, but
that can be visible on screen. Since that, too, would be
just another plane, it can be edited like any other part of the picture.
Foreign environments
Editing 24-bit color images on an 8-bit screen, or color images on a
black and white screen, is not fun, but it should be possible.
The 24-bit/8-bit problem could be solved by having a color table fish-eye
view - the currently focused area is displayed with accurate color values,
while the remainder gets dithered into the allocated colors.
Screen appearance
The image elements of the interface need to be editable, in particular their
color. Editing a dark grey on dark blue picture in front of a bright
blue frame is painful. I would see more if the contrast wouldn't
distract me.
The beta channel
Three RGB values a 8 bit each fill 24 bits; what to do with the remaining
8 in an 32-bit word? The alpha channel says how transparent the
current color is, and already makes for some neat tricks. How about using
only 5 bits for the alpha channel and allocating the remaining 3 to a
beta channel that specifies the diameter, in pixels, of the area
used to calculate the pixel value? That would be a way of creating
"blurry" transparent areas...