mirror of
https://gitlab.gnome.org/GNOME/gimp
synced 2024-10-20 19:43:01 +00:00
ac28d6b929
Mon Jul 5 22:51:37 BST 1999 Austin Donnelly <austin@gimp.org> * TODO: Removed zoom indicator in titlebar, since we already have that. Added more on progress indications, and dodge/burn. New entries for active brushes and named undos.
408 lines
14 KiB
Plaintext
408 lines
14 KiB
Plaintext
Please add things to this file when the need to do them is
|
|
discovered. Explanations of why or how this would be useful are
|
|
even better. Insight into possible ways to implement are even better
|
|
than that.
|
|
===================================================================
|
|
|
|
Add Unsharp Mask to the distribution. The filter is just way too basic
|
|
to leave out.
|
|
|
|
|
|
A few GUI things suggestions...
|
|
|
|
1) Crop tool could have an optional shader for the outside area
|
|
so when you crop, the area outside would show in a darker color /
|
|
user definable color / black / white etc.. (maybe a selector for
|
|
the outside area: ____________
|
|
Outside fill: [|_none_______| = ]
|
|
|.black......|
|
|
|.white......|
|
|
|.user def...|
|
|
|.shade 50%..|
|
|
`------------'
|
|
That would be very handy for cropping scanned photos etc -
|
|
one would see the result much easier apart from the rest.
|
|
|
|
gui/functionality separation
|
|
|
|
both file scope wise and in use, particulary so that
|
|
the gui version of the tool uses the pdb whenever possible
|
|
(for finding bugs, and for macro recording)
|
|
|
|
May be a good idea to actually put the core and the gui in
|
|
separate subdirectories. --sg
|
|
|
|
more configurabilty (eek)
|
|
|
|
I would like to be able to let the user stick arbitrary
|
|
buttons into the toolbox and attach arbitrary functions to
|
|
them. --sg
|
|
|
|
What about a second button-bar? We dont have icons to add to the
|
|
main toolbar anyway, so it would be hard to distinguish what
|
|
button does what (they are small -> text wont fit).
|
|
Look at my mockup:
|
|
http://tigert.gimp.org/files/temp/wilber_palette.gif
|
|
It might work in such way that
|
|
1. you click add -> new button
|
|
2. then right click on it -> you would get the normal <Image>-menu
|
|
(like when clicking right mousebutton over an image) from which
|
|
you could select the plugin/tool to assign to this button.
|
|
3. To apply the thing to an image you first click on the
|
|
button and the statusbar would show something like 'click
|
|
on an image to apply function xxxx' -> click an image to
|
|
assign the tool an image and apply it.
|
|
Now this is just an idea, but it might solve the 'which image do
|
|
we want to apply things to? -problem.
|
|
Also see http://www.home.unix-ag.org/simon/gimp/gimpbuttons.html
|
|
Simon Budig has an experiment similar to this. Maybe it would
|
|
make sense to implement something like this?
|
|
--tigert
|
|
|
|
fix stuff so that the tile size could actually be changed eventually
|
|
|
|
Currently gimp core is mostly setup to use a potentially
|
|
variable tilesize, but lots of plugins and some internal stuff
|
|
are hardcoded to expect 64x64 tiles. This is good for 8-bit
|
|
images on x86, but with potential of deep images and other
|
|
platforms, having this variable could be a real gain in
|
|
performance tweaking.
|
|
|
|
This will be hard because the XCF file format assumes 64x64
|
|
tiles. XCF load/save will have to be written to retile
|
|
images, or the XCF file format redesigned. --sg
|
|
|
|
previews in file save (for jpeg compression, etc):
|
|
|
|
Currently there is no easy way to see the effects of
|
|
compression or other image saving effects before actually
|
|
saving and reloading an image.
|
|
|
|
keybindings for simple "binary" tools:
|
|
|
|
(for ex, flip should flip horiz normal, and shift+click to
|
|
shift vertically). The more that can be done by power-users
|
|
without having to delve through dialogs the better. This is
|
|
mostly implemented already.
|
|
|
|
curve deal in the gradient editor?:
|
|
|
|
It could be useful to have a curve widget for each of the
|
|
color channels or hsv. For example, you have a custom palette
|
|
you like, but you want it to get dark from left to right. You
|
|
pop up the "Value" curve and make a curve getting darker.
|
|
|
|
(Note: this would require a complete rewrite of the gradient
|
|
_engine_, not just the editor. --sg)
|
|
|
|
some degree of drawing tools, straight line, etc:
|
|
|
|
Perhaps large parts of gfig could be salvaged for this. Its
|
|
not something "paint" programs traditionaly do, but there
|
|
usefulnes is obvious. square/circle/ellipse are already there
|
|
basically (just make a wrapper to select and stroke). need a
|
|
better straigh line drawing ui though.
|
|
|
|
Macro recording and better scripting support:
|
|
|
|
This pretty much is going to require the aforementioned
|
|
gui/func seperation. More stuff needs to be triggered via pdb
|
|
to make thsi a possibilty.
|
|
|
|
More Xinput stuff ( gradient brushes, pen "strokes" ?):
|
|
|
|
This is very important for "artist" types. The more
|
|
value-added utility we can make for Xinput stuff the better.
|
|
|
|
Redesign of the Blend Tool dialog? (it's rather large...)
|
|
|
|
"Fit text to selection":
|
|
|
|
make selection, scale text to fit it... A suggestion from
|
|
Xach, Perhaps instead of rendering the text and font size
|
|
exactly, make a bounding box of it, then scale the bounding
|
|
box as approriate. When the box size is chosen, figure out the
|
|
best-fit font size and render it.
|
|
|
|
instead of rendering into a preview, render preview directly
|
|
onto the image.
|
|
|
|
(Text should be redone entirely, with a native T1/TTF
|
|
interpreter. Using X to render text is cheap but nasty. --sg)
|
|
|
|
Done via a perl script hack -sjb
|
|
|
|
a complete groundup rewrite of iscissors:
|
|
|
|
Isciissors in theory are very useful. 1.0 iscissors basically
|
|
dont work though. It has also been mentioned that the gui from
|
|
.54 was much better.
|
|
|
|
(austin has some of 0.54 ported. If intrested, mail sjburges@gimp.org
|
|
or yosh@gimp.org for sources, as austin is on an extended leave)
|
|
|
|
progress bars on long proccesses:
|
|
|
|
Xcf loading/saving, transforms, complicated blend's etc. The
|
|
user gets no feedback about what is going on. This is bad.
|
|
|
|
(Maybe run core image ops from the idle loop? We already do
|
|
this for curves et al. --sg)
|
|
|
|
We have some of this in place thanks to Aspirin and Austin now.
|
|
--Yosh
|
|
|
|
Currently, long-term ops like blend run from a recursive event
|
|
loop, not the idle loop like they should. This should be cleaned up a
|
|
little. -- Austin.
|
|
|
|
status bars on image window:
|
|
|
|
(maybe swallow plug-in progress bars, show current x,y, file
|
|
type, etc...)
|
|
|
|
This is mostly done.
|
|
|
|
- optionally show that information in the toolbar ?
|
|
- probably dragable to the toolbar and vice versa
|
|
(still being debated what belongs in there -SJB)
|
|
|
|
"open into layer" and new image from cut buffer stuff should perhaps
|
|
be in core?:
|
|
|
|
This would be "Paste into New" and/or "Copy to New". Should be
|
|
simple. Theres a script to do this, but the functionailty is
|
|
so simple it perhaps would eb best to do in core.
|
|
|
|
drag & drop for layers:
|
|
|
|
(both in the dialog, and from image to image). Changing
|
|
postion of layers now is quite a pain. The onyl choices are to
|
|
raise by one, and lower by one. It would be much nicer to be
|
|
able to click & drag a layer to its new spot in the stack.
|
|
|
|
Handle Out of Space Better!
|
|
|
|
Also should handle out-of-space on swap device better.
|
|
(Couldn't be much worse.) --sg
|
|
|
|
Automagically guess whats a good tilecache size:
|
|
|
|
Not sure how to do this. maybe offer suggestions in the
|
|
preference dialog or install.
|
|
|
|
BETTER FONT SUPPORT!
|
|
|
|
even if we have to go around X. and a better font selector
|
|
too. Perhaps the new gtk font selector could be used. It seems
|
|
handy. The actual support may require integration of type1lib
|
|
or freetype or similar. Probabaly be an extension, gimp could
|
|
fall back to X font rendering if need be.
|
|
|
|
Refresh font list while running.
|
|
|
|
(There's a good argument for making all text operations run
|
|
thru an extension. --sg)
|
|
|
|
ability to get an exact count of the total number of colors in the
|
|
image:
|
|
|
|
Xpm plugin has an algo to do this. Perhaps it should be in the
|
|
core.
|
|
|
|
indexed/color reducing to arbitrary number of colors:
|
|
|
|
Current convert.c is limited to indexing to 8-bit palettes or
|
|
less. Dont know what would be involved in making it work for
|
|
larger palettes. convert.c has some deep magic involved in it,
|
|
so who knows.
|
|
|
|
(Related: indexed images with more than 8 bits depth. --sg)
|
|
|
|
Folding box for the toolbar:
|
|
|
|
So you can have it be 9x3 like now, or 1x27, or
|
|
whatever... gyve has rough outlines of a widget to do this...
|
|
(belive msw is working on this)
|
|
|
|
optimize transform_core (special cases, fft stuff?, optimizations only
|
|
raph understands, etc...)
|
|
|
|
brush-shaped cursors:
|
|
|
|
Possible solutions, generate cursors on the fly, use shaped
|
|
pixmaps, possibly just draw directly on the preview, any other
|
|
ideas? Raphs caanvas might offer the oppurtunity to do this
|
|
in color and anti-aliased.
|
|
|
|
active brushes:
|
|
Use module system to dynamically load new brush types, eg
|
|
Raph's(?) watercolour brushes, pixmap brushes, or image hose
|
|
style brushes. Need to define a proper API for hooking.
|
|
Maybe really want to define new tool types, rather than new brush
|
|
types.
|
|
|
|
pixmap brushes:
|
|
|
|
Should be simple. maybe need a new format that would include
|
|
data/mask (probabaly just use a xcf). Once its loaded in as a
|
|
tempbuf, a few tweaks in the paint tools ought to handle
|
|
it. Should it be a new tool? jsut a new brush type for old
|
|
paint to ls?
|
|
|
|
Quickmask/paintable selections:
|
|
|
|
Any ideas on the best way to do the ui? The fundamentals of
|
|
beng able to do this are already there. Just need a good way to
|
|
present it.
|
|
|
|
let pdb stuff register under the layers_dialog menu:
|
|
|
|
Lots of potential in scripts to do layer/channel manip. Might
|
|
as well let them register on those menus.
|
|
|
|
some sort of mdi for dialogs so you could tab them together or
|
|
pull them apart:
|
|
|
|
Would be nice to be able to pile all the dialogs into one big
|
|
notebook. (think msw is working on this)
|
|
|
|
make color picker able to choose from any color on the screen.
|
|
|
|
This sounds really simple. Any ideas?
|
|
|
|
dodge/burn/sponge/smudge tools:
|
|
|
|
several people have commented on the need for this. Anyone
|
|
know how to do it well?
|
|
|
|
Maybe integrate iwarp stuff into 'convolve' tool (or into a separate
|
|
one)? Iwarp gui could be put into the tool options dialog
|
|
-tigert
|
|
|
|
Calvin has committed dodge/burn/smudge stuff recently (5/July/1999).
|
|
|
|
big cad style cross-hairs cursor:
|
|
guides come close, but we probabaly dont wont somethign like
|
|
that again.
|
|
|
|
more info available to the user in general (current brush, etc)
|
|
|
|
some sort of image locking:
|
|
so we don't munge images by doing >1 ops on them at once.
|
|
For plugins in particular, may also simplifie some of the tool
|
|
redesign.
|
|
|
|
Suggestion from Ville Hautamaki (CW):
|
|
Pattern groups
|
|
Especially once patterns are demand-loaded. It would be
|
|
very conveint to say "load all the wood patterns",
|
|
or even just "set 1" etc.
|
|
|
|
Probably have a "Preview" button too that performs the transformation
|
|
without interpolation:
|
|
As it stands, transforms can be very slow and feedback to the
|
|
user is smalld. A preiview would save much time and maek the action
|
|
more accururate.
|
|
|
|
Selections should always be bezierifyable.
|
|
Um, not sure about this one. Selections can be a mask, in which case
|
|
the bezeirifying of it makes little sense to me..
|
|
|
|
I'll admit it'd be nice for "normal" selections. -sjb
|
|
|
|
Selections should be transformable:
|
|
(e.g. rotate an elliptical selection; the selection, not it's
|
|
content!!).
|
|
This shouldnt be too hard. Perhaps just need to add the hooks
|
|
for the selection info (usually in TileManager structs) to
|
|
be passed to the existent image ops.
|
|
|
|
Have a possibility to add a text as selection:
|
|
If selections would be editable as described above, we'd
|
|
then have editable vector-text. Is this possibel with type1 fonts?
|
|
|
|
option to create New Indexed image (with the choice of pattern foo) ?
|
|
|
|
Integrate gimp-16 stuff?
|
|
Eventually will happen.
|
|
see http://film.gimp.org/
|
|
|
|
Better use of wm hints.
|
|
|
|
Not sure where the line between dialogs and windows
|
|
lies, but it's something to look into.
|
|
|
|
Make file load/save errors not worthy of existence.
|
|
|
|
Right now the errors from the file plugins pop
|
|
up in weird places, at weird times, and are often
|
|
basically useless. This is bad.
|
|
|
|
Image pager/explorer
|
|
|
|
Basically similar in idea to a pager on a virtual desktop
|
|
wm, except a large image is the pager. Pop up a small preview
|
|
of the image, with a higlighted rectangle indicaing the currently
|
|
viewable area. User can then move around in the preview and the
|
|
highlighted area becomes the on screen viewable part. May
|
|
also be useful in file loading, where one could see a preview of a
|
|
large image and then jsut select a subset toa ctually load into
|
|
mem.
|
|
|
|
Code to set built in icons or icon path?
|
|
|
|
Is this the wm's job or soemthing internal?
|
|
|
|
|
|
Action/active/Procedural Layers
|
|
|
|
People seem to want them. For some ops it would be painfully
|
|
easy. For alot of stuff i havent a clue. Anyone have a good plan
|
|
on how to potentialy implement this?
|
|
|
|
generic preview code in libgimp for use by plugins
|
|
|
|
All plugins should have a preview. it would be nice if there
|
|
were code in libgimp to make this easier. Possibly just
|
|
generalize a good exmaple of preview code (quartics?) and
|
|
slap it in libgimp. Maybe throw some of the gck stuff in there
|
|
too. Or possibly make a new plugin helper lib combining
|
|
gck, megawidget, preview code, etc.
|
|
|
|
"All" plugins might be too extreme. Some plugins (autostretch
|
|
contrast) have little need for an interface, and exist IMHO
|
|
better w/o one..
|
|
|
|
Undo groups
|
|
|
|
basically for snapshots for the UNDO stack instead of realying on
|
|
everything to be recorded. Particualr useful in scripts.
|
|
|
|
named undo
|
|
Each pushing of an undo operation should include a textual
|
|
string for human consumption. That way, the "undo" menu
|
|
option can list exactly what will be undone. Also allows
|
|
meaningful undo history display, so you can undo multiple
|
|
levels in one go.
|
|
|
|
gradient map layer
|
|
|
|
map values from current gradient to value/intensity
|
|
(good for a plugin I think)
|
|
|
|
tools
|
|
|
|
Make tools listen for gimage dirty signals to fix munging.
|
|
When a tool caches image data privately, you need to reset
|
|
when the image gets dirty.
|
|
|
|
Grid
|
|
|
|
A gridding, and a snap to gridding. Basically a way of turning on
|
|
and off a grid, and setting the grid size. Then also a way of starting
|
|
to draw at a grid intersection and then end drawing at another
|
|
intersection.
|
|
(this was suggested to me by email -- Sven)
|
|
|