gimp/TODO

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.
===================================================================

A few GUI things suggestions...

   1) Zoom-indicator to titlebar [   Foo.xcf.gz-1.0 (50%, RGB) ]

   2) 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

fix the palette dialogs

	(it would be nice to be able to actually edit
	palettes and the like), also replace that menubox with a clist or
	something. Right now, the palette dialog is unresizeable, and
	mostly useless for anything other than picking colors.
	Import/Export options for palettes here would be good to.

	Palettes should become a first-class core data structure (like
	layers) with their own PDB interface.  (Goes with below.)  --sg

	* User opinion: The menubox has one big advantage: it is 
	_small_ in size. The problem with _lots_ of palette files is
	known. But is it possible to make the menubox make
	submenus if it gets longer than the screen? Isnt this more 
	like a gtk-issue? * --tigert

integrate palette saving into core

	An option to save a current images pallete to a file is
	handy. Theres currently a plugin to do this, but for
	integration it might be better in the core.

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

file new dialog stuff   (i'm working on this...Adrian)

	1. default to size of cut buffer
	2. add units and resolution options
	3. make x,y values have dropdowns for last 5 or so used sizes
	4. maybe an estimate of how much ram the image will take?
	5. maybe some "preset" common image sizes? 
	     -> 
		* 468x60 banner ad
		* 88x31 banner ad (Netscape NOW! -button for example)
		* A4, A5, A6, US Letter etc.. sizes so that they take 
                  the chosen resolution into account ("Hm. I need to make
		  an A4 sized pic in 300DPI...") --tigert
	6. resolution/units need to be exported to the whole app
	(probabaly in gimage.c) so size/scale, text tool, etc can
	use them.

export filters:

	This is one that would make some alot of sense intuitively,
	and could be very convenient for scripting. Currently, theres no
	"one step" way to save images easily. This feaure would be
	useful for example in the Mail plugin, where it could flatten,
	convert, etc the image in one step.

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.

save/restore state of major dialogs:

	Gimp currently has no way to save the state of the gimp
	desktop. Perhaps some of the gnome session management stuff
	could be useful here. It should be exported to the PDB too.

	Saving of window geometry is now there. --Sven

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.

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.

paths, and better beziers would be a nice touch:

	Being able to load, save bezier paths, and convert from bezier
	to selection, and selection to bezier would be very
	benificial. This combined with a working iscissors would make
	for extremely flexible selection mechanisms.

	Probably integrate the paths into the Layers&Channels dialog?

	Code for this is there, but the interface is considered by many
	to be poor -- Yosh

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.

natural media tools (raph?)

A "Revert To" menu options:

	Open a image, munge it around a whole bunch, decide you dont
	like the results, and you dont have enough undo
	steps. File->revert would easily reload the file from disk.

	Implemented now, needs testing -- Yosh

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)

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.

Interactive resizing/scaling of layers (maybe with handles on the edges)

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

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

"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.

more indicators of current status:

	(X,Y position, selection size and placement etc ), maybe in
	another dialog, maybe a status bar?  Lots of request for
	this.

	This is mostly done. --Sven

Clean up swapfiles: 

        Gimp is prone to leaving large swapfiles lying around. Perhaps
	on startup or exit it could clean up unclaimed
	swapfiles. Problem: how to tell a unclaimed swap file (one
	could be in use by another gimp). Maybe add a unique id to the
	swap file?

	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.

an artist palette type of color selector:

	(maybe based on raphs watercolor deal?)  notebooked with the
	regular color selector? (believe seth is working on this).

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.

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?

	Also, set a radius for color picker to pick an "average" from

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

session management

	Well, what we have right now is the following:
	Dialog geometries are always saved and restored. Dialogs that were
	opened on last save (or last exit if "Save window positions on exit" 
	is choosen in the Preferences) are reopened on startup if you
	call the gimp with command-line option -r or if you have 
	"Always try to resore session" checked in Preferences.
	This allows to create a preferred gimp desktop, exit to have it 
	saved. If you toggle "Save window positions on exit" off now, the 
	settings will stay forever.

	The device status is saved and restored too, with a similar scheme.

Text Tool
	More complete font selection
	Multiple lines and alignment
	Kerning, hints, etc.

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.

Overwork the transform tools UI:
	It would be nice if the transformation wouldn't automatically
	start when releasing the mouse. Instead have a window that
	shows the currently choosen transformation numerically
	(e.g. Scale X: 0.75 | Scale Y: 1.00). The transformation
	should be editable there and with handles on the
	outline. Perform the transformation when "OK" is clicked in
	the dialog or when you doubleclick(?) into the image.

	The new transform tool UI is almost there, and it rocks!! --Sven

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.

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/

A way to define a default comment

	larry is working on named data attachments for images. More
	or less a generic way to define image comments and other
	embedded info. 

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.

abiltiy to specify which gimprc to parse on commandline

	Some people need to be able to use different gimprc on
	different machines (for ex, 8-bit vs 24 bit display).

Undo groups

	basically for snapshots for the UNDO stack instead of realying on
	everything to be recorded. Particualr useful in scripts.

gradient map layer/paint mode

	map values from current gradient to value/intensity

script-fu

	proper font selector instead of typing the silly thing in
	maybe a color history too...

	Well, the script-fu interface has seen a few extensions and Adrian
	is working on adapting the scripts to the new interface.

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)