Difference between pages "Evaluation Notes - Creating Original Art" and "Selection + crop tool specification"

Revision as of 21:11, 28 March 2007 (view source) Kamila (talk)		Revision as of 11:34, 1 August 2007 (view source) Guiguru (talk) (→‎fixed width/height/size)
Line 1:		Line 1:
−	[[Expert_Evaluation_Notes|read other Expert Evaluation Notes]]	+	==intro==
		+	This is the specification for the rectangle + oval selection, and the
		+	crop tools. It is based on the state of GIMP 2.3.13, and is now updated with the realities of 2.3.18.
−	== introduction ==	+	==on units, sizes and visible==
−	These raw notes are provided as our documentation and for your insight and entertainment. They are not meant to start a flame war. Wait for our complete analysis before reacting.
−	'''task:'''	+	All sizes in this spec are in '''on-screen pixels'''. This means that the zoom level has an influence on everything. A 30x20 in-image rectangle can be displayed on screen as 300x200, and vice versa.
−	creating original art, a collage of found images and wild brushwork.
−	==Open New File==	+	Also the panning of the image has an influence on everything. Only the visible part of the bounding rectangle goes into the size calculations. Example: a 123x45 image rectangle is viewed at 1000%, only the left-most 2/3rd and top half of the rectangle is visible in the image window: 820x225 on-screen pixels go into the calculations ( 123*10*2/3 and 45*10/2).
−	#Image Size: width and height should be chained
−	#Advanced options are hiding the resolution part, which is something we are trying to achieve.
−	#X, Y resolution should be the same by default
−	#Many possible resolution formats, but in 99% you know what ppi you want to achieve.
−	##We can create two radio buttons. one for screen images (72 ppi) and the second for other print resolutions.
−	#With closed advanced options you shall be able to express if it’s print or screen img.
−	#When choosing img for print, the default resolution would be something like 300 ppi, but user could type other value (the same for X, Y resolution). In advanced options user could change X, Y resolution independently.
−	==Open PDF ==	+	===decision time===
−	#It needs Ghostscript, so this should come as an installer option.	+	The right moment to recalculate handle sizes and decide if there is a narrow situation shall be '''after''' through zooming, panning or actual bounding rectangle size change, the on-screen pixel size of the bounding rectangle has changed. It is explicitly '''not''' desirable to do this during zooming, panning or actual bounding rectangle size change.
−	#something wrong with sizing the pages preview
−	# width and height should be chained, what happens if aspect ratio gets altered by the user: squash or cut?
−	==Image window issues ==	+	==handling the bounding rectangle on the canvas==
−	#When closing last image window, GIMP should not quit, an 'empty' image window (grey, or with with Wilber, or tooltip) could keep the instance alive.
−	#When minimizing image window also toolbox window(s) should be minimized. (however that might be disturbing when working on many images at  the same time and shifting between them)
−	#In a task bar user should see just the image windows.
−	#Maybe we could dock dialogs in the main image window. User would be able to have separate dialogs all around, or all in image window.
−	#In View/Dialogs menu user could chose the view mode. We should decide about the default after evaluating a mockup of the all-in-one concept.
−	#Inspector (toolbox) windows are at the moment real windows, and in general they are too 'fat' comparedd to the image window. for an optimal working environment they should have more ‘lightweight’ look, trimmer, more ‘athletic’. We need to limit those big push buttons that are common.
−	==Scanning ==	+	===pending===
−	#We don’t like the fact the user has to install SANE plugin to scan. This should be one-click installation. After installing it should automatically see the scanner.
−	==Aquire ScreenShot==	+	Between being created and being committed (by means of a single mouse click in its area or the enter/return key), a rectangle is called to be in pending state.
−	#GIMP is partially duplicating functionality of the desktop environment, but we appreciate it also takes a screenshot of a single window, or area.
−	#Delay is good idea, but the phrase needs to be changed. Description may depend on the option chosen by radio button. There should be also appropriate tooltips.
−	#Two delays is too much.
−	#We need to show that’s it’s counting down.
−	#Name: take a screenshot of a single window
−	# more complicated options would be available in a separate plugin.
−	==Acquire Scanner/Camera.. ==	+	The algorithm for the size of the corner handles (handle height = bounding rectangle height / 4, CLAMPed by 6 and 50, handle width  = bounding rectangle width  / 4, CLAMPed by 6 and 50) allows fast interaction:
−	#Separate sub-menu item for webcam, scanner, camera.
−	#Right now Source window enables choosing right device, but the Source window would be shown just when there are multiple cameras, or multiple scanners connected.
−	==Layers ==	+	[[image:2.4_basic_corners.png]]
−	We need organizing layers in folders.
−
−	==Layer Modes ==
−	#Being mostly mathematical operations, their names could be clearer to express what really to expect.	+	what is black in this image shall be rendered inverted on the canvas. ''note that at any time the marching ants of a selection edge can obscure an inverted line.''
−	#there are a lot of them, but we know that when using them for a longer time one can know/predict their result.
−	#the browsing of the modes via the up/down keys is crucial just to see what each does
−	general comment: Alpha channel should be more directly editable.	+	Each corner handle shall enable users to resize the bounding rectangle by dragging one of them, where the diagonally opposite corner of the bounding rectangle shall be the anchor point.
−	==Filters==	+	The rectangle cornered by the corner handles shall be the move handle: one big handle where users shall be able to move the bounding rectangle around the canvas by initiating a drag in this handle:
−	we evaluated most of the plugins, and did that within the context of this scenario, for alienating (modifying with an attitude)  graphic material. we looked for the following traits:	+	[[image:2.4_move_area.png‎]]
−	* does the effect fit the scenario, is it universal and combinable;	+	''the gray area shown here is purely for illustration in this spec and shall not be rendered in GIMP''
−	* is the UI straightforward, a straight path between user goal and promised plugin effect;
−	* does the UI encourage experimentation;
−	* is the effect a one-trick pony; if so is it a great pony worth keeping.
−	===Colors menu===	+	Areas between two adjacent corner handles are called side handles.
−	====Colorize====	+	The height of the two horizontal side handles shall be exactly the corner handle height, and their width shall be the (bounding rectangle width - 3 * corner handle width), CLAMPed on the lower side by 6.
−	#Works well, but it wouldn’t make the img realistic. therefore it shouldn’t be grouped with all other major realistic colour filters.
−	#The first 2 sliders should be replaced with a colour wheel. Slider for lightness should remain.
−	===Curves===	+	The width of the two vertical side handles shall be exactly the corner handle width, and their height shall be the (bounding rectangle height - 3 * corner handle height), CLAMPed on the lower side by 6.
−	#All  RGB courves should be visible at the same time, and one should have active nodes for manipulating.
−	#There should be possibility to type in the values of a node.
−	#idea: squeeze levels and curves into some docking panel.
−	====Posterize====	+	All side handles shall be exactly centred on the side they are attached to. If the side of the of the bounding rectangle is an odd number of pixels long, then the attached side handle shall be an odd number of pixels long. Similarly: if even, then even. When this adjustment is needed, it shall be done by increasing the handle size by one pixel.
−	#Nice and straightforward.
−	#effective rather only for low ranges (just below value 33 something really happens).
−	#could expand the lower range and compress the higher range of values on the slider
−	====Invert and Value invert====	+	[[image:2.4_side_handles.png‎]]
−	Nice and quick
−	====Desaturate====	+	''the gray area shown here is purely for illustration in this spec and shall not be rendered in GIMP''
−	#Most of the people don’t know what's the difference between lightness and luminosity.
−	#Maybe change the one of the two to brightness.
−	#It should have preview.
−	===Auto submenu===	+	This all makes the size of the side handles predictable (and thus faster to use each time) where it counts most (their smallest dimension) and uses their largest dimension to leave a gap to reach the corner handles from within.
−	#Probably aimed at photographers, but exactly they wouldn’t trust all-automatic filters.	+	Each side handle shall enable users to resize the bounding rectangle by dragging one of them, moving the side it is attached to, where the mid-point of the opposite side of the bounding rectangle shall be the anchor point.
−	#On other hand, these filters don't do anything spectacular for graphic designers.
−	===Components===	+	What is left within the bounding rectangle are the dead areas, a drag by users starting in these shall do nothing, neither move, nor resize. This is to prevent accidental move when trying to resize, or accidental resize when trying to move:
−	====Channel mixer====	+	[[image:2.4_dead_areas.png‎]]
−	#Values should be in percents.
−	#It works for splendidly for converting to monochrome, to experiment until you like what you see.
−	#For colour modes the UI is not good, it’s difficult to make the experiments, when changing the output channels .
−	#Save options are useful for creating filters. It would be a good idea to have easy access to different pre-sets (‘personal filters’).
−	# the user does not need to worry about files. GIMP can store it in the right place and add presets to a popup menu. user can also manage presets (delete etc.) via this popup menu. Other tools could work in a similar way.
−
−	====Decompose====
−	#Not very useful in this scenario
−	===Map submenu===	+	''the gray area shown here is purely for illustration in this spec and shall not be rendered in GIMP''
−	====Alien Map====	+	In the implementation the dead areas shall be used as ‘bumpers’ to reconcile the rounding-off effects in the sizes of the corner and side handles. The dead areas are simply  what is left over in area of the bounding rectangle.
−	#Does sth radical, it is rather interesting.
−	#No reset button or saving of parameters.
−	#Three check-boxes are not a good idea. Also changing the modes in this way is not good.
−	#Sliders are too technical. We need something that would encourage to experiments, and also give user bigger control over what it does. Now the sliders are too long.
−	#Changing the mode keeps sliders at the same place, which is strange, since the sliders have completely different function.
−	#Different names, not so technical, like instead of ‘red frequency’ – ‘red wobbles’, instead of ‘red phaseshift’- just ‘shift’ or ‘wobble shift’.
−	#unchecking a check box doesn’t mean deactivation of a pair of sliders, but not applying the effect of those setting, so maybe we shall use an eye icon instead.
−	#New default settings (0,7).
−	====Color Exchange====	+	====fixed width/height/size====
−	#The default threshold settings should be above zero, because the else changes are unnoticeable.
−	#In separate color dialog the Hue value changes per 30 when you click at some point, and it doesn’t get set to the clicked point. for sliders where one can see the direct result along the slider track, we should set the value to the clicked point.
−	#other sliders, like the CMYK values, changes per 10, as guidelines prescribe. this is good, because one cannot predict what one gets.
−	====Map Color Range====	+	When users are enforcing fixed width or height in the pending state, the rectangle handles shall reflect this. Showing corner handles does not make sense, because only two of the sides can be adjusted. Therefore these two side handles shall be displayed (fixed height, left; fixed width, right):
−	#The hue direction (cw, ccw) of how the color changes from the first range to the second should be presented.
−	#It’s nice to specify 4 points, but right now it isn’t controllable, because user can’t see what 2 paths through color space is set up.
−	====Gradient Mapping, Palette Mapping====	+	[[image:2.4_constant_wh_handles.png]]
−	Nice and quick
−
−	====Rotate Color====
−	#All values should go from 0 to 360. We like simplicity so we would like to remove the input fields, but maybe that would be ‘too easy’.
−	#There should be smaller icons, better describing what they do.
−	#Units tab should disappear, hue units should probably always be degrees.
−	#Gray mode probable has still some bugs. We are not sure why gray shift is implemented in Color rotation.
−	====Sample Colorize====	+	With no corner handles to compete with, the side handles shall occupy the whole side of the bounding rectangle. The height
−	#Nice effects, but looks sloppy, because of manual update (get sample colors). It should update once per sec while user is sliding around.	+	of the top and bottom handles and the width of the left and right handles shall be calculated as usual. The rest of the bounding rectangle area shall be the move handle:
−	#The names for input/output level should be different.
−	#‘Get sample colors’ button is not well place. Choosing an image in Sample dropdown, should trigger ‘getting sample color’.
−	#The dialog should be rearranged.
−	#There should be Apply, Cancel, OK buttons.
−	general comment: The creating of a gradient for more complex colorising is too difficult right now.	+	[[image:2.4_constant_wh_move.png]]
−	===Color menu revisited===	+	''the gray area shown here is purely for illustration in this spec and shall not be rendered in GIMP''
−	====Colorify ====	+	When users are enforcing fixed size in the pending state, the rectangle handles shall reflect this. Showing corner handles does not make sense. The whole bounding rectangle area shall be one big move handle:
−	#It should have a good color picker instead of few old-fashioned colors.
−	#Doesn’t seem to meet the goals of artists.
−	====Color to Alpha====	+	[[image:2.4_constant_size_no_handles.png]]
−	# in general: the Color picker in all these dialogs should all be as good as the color picker in the toolbox.
−	#user control over this filter should be improved.
−	====Filter Pack Simulation====	+	''the gray area shown here is purely for illustration in this spec and shall not be rendered in GIMP''
−	Very cryptic, no-concept UI. Not relevant these days.
−	====Maximum RGB Value====	+	===highlighting===
−	Direct enough.
−	====Retinex====	+	When the sprite (mouse cursor) hovers over a corner handle, it shall highlight by inwardly doubling its perimeter line, and by hiding the other 3 corner handles:
−	#It’s very good for it’s original intent and experiments, but needs a goal oriented UI.
−	#Technical parameters don’t make sense.
−	#parameters cannot be saved.
−	===Artistic===	+	[[image:2.4_corner_highlight.png‎]]
−	====Apply Canvas====	+	When the sprite hovers over a side handle, it shall highlight along the whole side of the bounding rectangle with a 1-pixel line, to communicate that it moves the side. The other dimension of the highlight rectangle shall be that of the corresponding side handle. Also there shall be a 2-pixel line along the perimeter of the side handle itself. This is important because this is the only opportunity we have to communicate the size of the handle in a non-obstructive way. The two corner handles on the opposite side shall be hidden:
−	Simple enough, although we wouldn’t recommend offer it to professionals. One trick pony. not to be included in GIMP distribution.
−	====Cartoon====	+	[[image:2.4_side_handles_highlight.png‎]]
−	Should stay, easy to control and gives cool effects.
−	====Clothy====	+	====fixed width/height====
−	not good for experimenting, because there is no preview.
−	====Cubism====	+	As an implication of enforcing fixed width or height in the pending state, the side handles shall highlight as shown here:
−	tendency towards kitschy effects. not to be included in GIMP distribution.
−	====Photocopy ====	+	[[image:2.4_constant_wh_highlight.png‎]]
−	edge finding filter with a lot of combination potrential.
−	====GIMPressionist====	+	===rubber-banding===
−	It is powerful, it is an application on its own. but there are too many options too even start experimenting. Why would a user start doing it in one dialog at the same time?
−	====Oilify====	+	When the mouse goes down inside a corner handle and dragging commences, it shall be displayed and the other 3 hidden, to achieve a minimal-obstruction display:
−	One-trick pony.
−	====Predator====	+	[[image:2.4_corner_drag.png‎]]
−	Interesting, but definitely needs a preview.
−	====SoftGlow====	+	When the mouse goes down inside a side handle and dragging commences, it shall display a rectangle along the whole side of the bounding rectangle with a 1-pixel line. The other dimension of this rectangle shall be that of the corresponding side handle. The two corner handles on the opposite side shall be hidden:
−	Good, it does what its name promises.
−	====Van Gogh====	+	[[image:2.4_side_handles_drag.png‎]]
−	#It has 12 parameters and no preview, which is unacceptable.
−	#It doesn’t do what it ‘promises’.
−	#We need to take it out or improve it, so that it does what it says.
−	====Weave====	+	Corner handles shall '''not''' change in size during the rubber-banding of the size of the bounding rectangle. This is necessary to achieve a stable cause-and-effect relationship between the position of the sprite, and the size of the bounding rectangle.
−	It has no preview but quite a lot of parameters. The effect is rather kitschy.	+	* Side handles shall track the dimension of the bounding rectangle on the side aligned with it, while the other side shall '''not''' change in size during the rubber-banding;
		+	* On creation of a new rectangle, the handle size shall be the minimal handle size;
		+	* When either side of a corner handle, or the not-bounding-rectangle-aligned side of a side handle, is equal or greater that the corresponding side of the bounding rectangle, the handle shall not be displayed during rubber-banding.
−	===Map===	+	==cursor keys==
−	====Bump Map====	+	The most important thing about enabling cursor keys for moving/resizing the bounding rectangle is that it shall be exactly the same ''user experience'' as performing the same operation with a mouse click. The only exception to this is that when resizing due to a cursor key press, the rubber-banding display shall be skipped.
−	Interesting, but needs less and better parameters.
−	====Displace====	+	* When the mouse is over one of the corner or side handles, and one of the up/down/right/left cursor keys is pressed, the rectangle shall be resized by one (shift: 15) '''image''' pixel in that direction.
−	The effort spend on trying to understand the parameters is not worth the effect. The parameters are too difficult to understand.	+	*  When the mouse is over the move handle, and one of the up/down/right/left cursor keys is pressed, the rectangle shall be moved by one (shift: 15) '''image''' pixel in that direction.
−	====Fractal Trace====	+	This interaction is not complete until the goal of keeping the sprite stable on the handle has been achieved. We depend on bug #362915 to be fixed, then we can explore feasible solutions.
−	Not useful enough for creating a background.
−	====Illusion====	+	==think small==
−	Straightforward. Either one likes the effect or not. Peter says no, kitschy; Kamila says, that used in a correct way might give good results.
−	====Make Seamless====	+	Both corner and side handles have a minimum size of 6 pixels. This will work for bounding rectangles down to a size of 18 pixels. Here we see rectangles with one and two dimensions of 18 pixels, also showing the side handles:
−	Very simple and straightforward.
−	====Map Object====	+	[[image:2.4_mini_sizes.png]]
−	#Not for Web Designers, also not useful in this scenario.
−	#A plugin with light adding would be a good idea, but a more specialized one.
−	#Material is interesting, but you could make it a seperate plugin.
−	====Paper Tile====	+	''the gray area shown here is purely for illustration in this spec and shall not be rendered in GIMP''
−	#Bad interface, because you need to set the parameters and see what happens.
−	#Does the values have to be connected together?
−	#Shouldn’t stay.
−	====Small Tiles====	+	If the size of one of the sides of the bounding rectangle is below 18 pixels, we have a '''narrow situation'''. This can be caused by actually narrow-sized bounding rectangles, but also by zooming out and panning out of view. The obvious work-arounds for this (zoom in, pan in) are productivity eaters, we need a real solution.
−	#There should be separate vertical and horizontal slider for segments.
−	#Reset works in a odd way.
−	#If there is no important reason why the formula is there, then it should not be displayed.
−	#Useful but the interface should be simplified.
−	====Tile====	+	Move the handles outside. Here we see rectangles with one and two dimensions of 17 pixels:
−	Is there any reason why it should be there? It is rather unnecessary to stay.
−	====Warp====	+	[[image:2.4_maxi_narrow.png]]
−	#Looks powerful but not at all straightforward, there are too many controls.
−	#We need to go back to the person who made it and ask what (s)he wanted to achieve?
−	#If we can make it simple then, then it is ok, we need to find purpose for it.
−	===Render===	+	In a narrow situation, the following specs change:
−	Creates new graphics with no relation to the current image. therefore it does not fit this scenario.
−	===Blur submenu===	+	* The corner handle size shall be 15x15 pixels, always.
−	Simple and straightforward: Blur, Gaussian Blur, Motion, Pixelized. However in Motion Blur the angle should be set not by a slider but rather by a wheel. Most of the plugins having angle parameters should be fitted with a rotating wheel type control.	+	* If the the bounding rectangle has a non-narrow side, the long side of the side handle shall be (bounding rectangle side length - 2 * 15), CLAMPed on the lower side by 18, the short side of the side handle shall be 15 pixels.
		+	* On the narrow sides, the size handles shall simply fill the space between the two corner handles:
−	====Tileable Blur====	+	[[image:2.4_narrow_side_handles.png‎‎]]
−	#life could be as easy as setting vertical and horizontal parameters to set the border, and say how you want it to work.
−	#Also the two names IIR, RLE are wrong, they should say what they really mean  (IIR : for photographic or scanned images, RLE: for computer-generated images).
−	#It appears twice in the menu in Windows version.
−	===Enhance===	+	''the gray area shown here is purely for illustration in this spec and shall not be rendered in GIMP''
−	====Deinterlace====
−	Quite good for adding missing rows when capturing img from camera.
−	====Despectle====	+	There shall be only dead areas on a non-narrow side:
−	Maybe more for experiments than for despectling.
−	====Destripe====	+	[[image:2.4_narrow_dead_areas.png]]
−	Easy and straightforward for adding stripes.
−	====NL Filter====	+	''the gray area shown here is purely for illustration in this spec and shall not be rendered in GIMP''
−	Doesn’t improve the image in expected way, not for photographers.
−
−	====Red Eye Removal====
−	(...)
−	===Filter values issue===	+	The move handle shall be equal to the bounding rectangle:
−	What is better when using a filter second time…
−	—should it keep the last setting?
−	—should it have default ones?
−	We need to answer these questions.
−	===Distorts===	+	[[image:2.4_narrow_move_handle.png]]
−	====Blinds ====
−	too simple for professionals, not worth keeping.
−	====Curve Bend====	+	''the gray area shown here is purely for illustration in this spec and shall not be rendered in GIMP''
−	#This should be done in a direct way by a tool, not a filter.
−	#It should also enable vertical and horizontal changes.
−	Useful probably for creating flags.
−	====Emboss====	+	Highlighting is unchanged:
−	#The effect is interesting, but there should be better description of the parameters.
−	#For the light setting it would be better to have some kind of light rotation.
−	====Erase every other row====	+	[[image:2.4_narrow_highlight.png]]
−	#Gives a good effect; straightforward.
−	#But better controls would make it even better, probable some radio buttons instead of dropdowns.
−	====IWarp====	+	As is dragging:
−	should be done with a tool.
−	====Lens distortion ====	+	[[image:2.4_narrow_drag.png]]
−	#Too subtle effects for this scenario.
−	#(not in Windows/version 2.3.11)
−	====Mosaic====	+	==interaction with the canvas edge==
−	Not useful for this scenario; kitsch alert.
−	====Newsprint====	+	In general it shall be possible to start a crop/selection rectangle outside the canvas, or to take the edges of the bounding rectangle outside the canvas. Below is specified what happens in these cases:
−	#Really good for this task, but it should have better controls, than it has now.
−	#It’s worth to spend time on this filter, great effect.
−	====Page curl====	+	===selection tools===
−	Not useful for this scenario; kitsch alert.
−	====Polar Coordinates====	+	When one or more edges of the bounding rectangle is outside the canvas, then the canvas edge shall clip the effective selection. The interaction shall reflect this by showing the bounding rectangle in whatever size and position that users take it and the effective selection marching ants along the canvas edge where clipped. Especially with the elliptic select tool, this is part of creative workflow.
−	Not useful here, and probably nowhere.
−	====Ripple====	+	''However:''
−	Quite essential distortion mechanism, but needs better parameters
−	====Shift====	+	* If users enforce a fixed ratio of the bounding rectangle and one or more edges of the bounding rectangle is outside the canvas, then all of these edges shall be aligned with the corresponding canvas edges, and the from the resulting new bounding rectangle sizes the ratio enforcement shall be calculated. The interaction shall reflect this by showing the bounding rectangle in the newly calculated position;
−	Straightforward, good enough.	+	* If users enforce a fixed width of the bounding rectangle and the left or right edge of the bounding rectangle is outside the canvas, then this edge shall be aligned with the corresponding canvas edges, and the from the resulting new bounding rectangle sizes the width enforcement shall be calculated. The interaction shall reflect this by showing the bounding rectangle in the newly calculated position; if the fixed width is greater than the actual canvas width, then the full width of the canvas shall be used;
		+	* If users enforce a fixed height of the bounding rectangle and the top or bottom edge of the bounding rectangle is outside the canvas, then this edge shall be aligned with the corresponding canvas edges, and the from the resulting new bounding rectangle sizes the height enforcement shall be calculated. The interaction shall reflect this by showing the bounding rectangle in the newly calculated position; if the fixed height is greater than the actual canvas height, then the full height of the canvas shall be used;
−	====Value Propagate====	+	===crop tool===
−	We are not really sure of its goal, seems not very powerful
−	====Video Plugin====	+	When the 'allow growing' option has been invoked by users, then the crop tool shall be in no way limited by the canvas or layer edge. In the other case:
−	#Should have a real preview.
−	#We should add some sliders for strength of the effect, distance between the lines, it would reduce the number of radio buttons. However we need to pay attention, so that it wouldn’t change into complex cockpit of a jumbo jet.
−	====Waves====	+	When one or more edges of the bounding rectangle is outside the canvas, then all of these edges shall be aligned with the corresponding canvas edges. The interaction shall reflect this by showing the bounding rectangle in the newly aligned position.
−	#No reset button.
−	#Could benefit from more understandable names (size, strength, offset for example)
−	#Users should also have possibility to save the settings.
−	====Whirl and Pinch====	+	For fixed ratio/width/height: see selection tools above.
−	#It could have option for choosing center point of the effect, however this would make it similar to IWarp, and the professional would use IWarp.
−	====Wind====	+	If the 'Current layer only' option has been invoked by users, then all all behaviour specified above shall apply, substituting the layer (edge) for the canvas (edge).
−	#The should be possibility to set the angle of the wind.
−	#We could have a 2-dimensional input control (a square with a movable dot in it) with X,Y standing for Threshold, Strength. Then it would be possible to drag around until you like what you see, input fields should stay for direct input.
−	===Light and Shadow===	+	==the fixed ratio/widht/height/size and the shift key==
−	====Gradient Flare====	+	Between the 'Expand from centre' and Highlight checkbox there shall be the Fixed ratio/width/height/size control:
−	#We need a more direct access to set the effect (the detour via the edit button).
−	#Maybe even you should create Gradient Falre Editor as a separate plugin.
−	#What we like is that you can set up the gradient your way, we see potential, but there are too many tabs, sliders in single window.
−	#The interface has to be improved.
−	#What worries us is dependency on standard gradients.
−	====Lens Flare====	+	[[Image:2.4_constant_ratio_control.png]]
−	#It need some two more sliders for size, and other artistic parameter (maybe for the color).
−	#We wonder if the size is set according to the size of the img. (NO- it does sth quite different than we expected!)
−	====Lighting Effects====	+	It is a checkbox, with ('''new''') a pop-up list in the first row, combined with a single textfield and two icons (portrait; landscape) in the second row. The pop-up list shall contain the items 'Aspect ratio', Width, Height, Size, in that order. The default shall be 'Aspect ratio'.
−	#Using many lights at the same time should have better UI. There are 6 lights, and to switch one off the effect you need to set its type to None. In the dropdown you have no clue which light are used.
−	#Maybe we could make the names resemble the real lights: spot light, soft-box.
−	#The plugin is too complicated for straightforward experimentation – too many parameters.
−	#The workflow to set up a realistic image is cumbersome.
−	#the two mapping tabs deserve their own plugin.
−	====Sparkle====	+	The width and height modes shall not display the icons:
−	#Too many parameters, but can be good, after some improvements.
−	#By default the preview should be checked.
−	====Supernova====	+	[[Image:2.4_constant_wh_controls.png]]
−	#It should be possible to drag or click at the preview for the effect.
−	#Random hue values need better clarification of what they stand for.
−	#It is so much better than the other Light and Shadow filters (has just right nr of parameters).
−	#We could change the name for sth similar to the tooltip (‘add a little star burst to your image’).
−	====Drop Shadow====	+	The size mode is most identical to the ratio mode:
−	#No preview.
−	#There should be possibility to chain offset X/Y values.
−	#Can it be more interactive?
−	====Perspective====	+	[[image:2.4_constant_size_controls.png]]
−	Useful, but it has to be more interactive, there has to be a good preview.
−	====Xach effect====	+	===textfield input===
−	Not useful in this scenario, rather for Web Designers. But still too complicated a dialog and no preview.
−	====Apply Lens====	+	It is extremely important that the textfield shall be a single textfield with no up/down arrows. This allows for quicker input.
−	#The quality gets really bad, pixelated.
−	#Should be moved to lens distortion filters.
−	#We suspect that the same effect can be made with other filters.
−	====Glass Tile====	+	* in ratio mode, the textfield shall accept the formats A/B and A:B, where A and B are two floating point numbers;
−	#Quick and straightforward.	+	* in width and height modes, the textfield shall accept a single floating point number;
−	#However the threshold ranges should be wider, from 10 to 50 is not enough for experiments.	+	* in size mode, the textfield shall accept the formats A*B, AXB and AxB, where A and B are two floating point numbers. A shall be the width, B shall be the height.
−	#why does it not live with the other tile or lens filters?
−	===Noise===	+	Before parsing the input, all white space characters shall be stripped out. The input shall be committed by a <return>, <enter> or a input focus change out of the textfield and shall be one of three kinds:
−	====HSV Noise====	+	# unambiguous user value; User override state shall be entered for this particular mode (ratio, size, etc.) for all images, for the rest of the session; the user entered value shall be used for this mode;
−	#dialog is titled: Scatter HSV? there more examples of this mismatch	+	# unambiguous user clear; apart from that stripped out white space, nothing else was entered in the textfield; this shall enter the default state for this particular mode (ratio, size, etc.) for all images, for the rest of the session; the default value shall be displayed and used for this mode;
−	#we had great random results, but we could not comprehend how we got them.	+	# anything else is ambiguous; no state or value change shall be undertaken; the value displayed before users' text input shall be restored.
−	#although hsv colorspace is quite predictable, it is paradoxically unpredictable how the sliders influence the result one gets.
−	====Hurl====	+	Default values:
−	#No preview makes experimentation impossible.
−	#But in fact there could be just one parameter instead of two and a monochrome option too.
−	====Random Pick====	+	* in ratio mode, the default value for the textfield shall be "1:1" for the selection tools; for the crop tool it shall be <current layer/canvas width>:<current layer/canvas height> when there is no pending crop rectangle and <crop rectangle width >:<crop rectangle height> when there is a pending crop rectangle; this value shall not change during rubber-banding;
−	#It’s more a jitter, not noise, kind of artistic filter.	+	* in width mode, the default value for the textfield shall be <current layer/canvas width>;
−	#It definitely needs more power, plus preview for experimentation.	+	* in height mode, the default value for the textfield shall be <current layer/canvas height>;
		+	* in size mode, the default  value for the textfield shall be "100x100", ''[this is a random value, I am open for suggestions for a more useful default here].''
−	====RGB Noise====	+	====mathematician's Easter egg====
−	#Independent RGB checkbox needs a better name, because it just chains all R, G, B values.
−	#it is predictable what the sliders do, but that does not get you one step further towards your goal, because of the unpredictability of rgb colorspace.
−	#It is not easy to control the effect.
−	====Random Slur====	+	In ratio mode, when the users' input is terminated with a '=' character, the entered ratio shall be simplified to the to lowest integer numbers that faithfully represent the ratio. The '=' character shall not be displayed after siplification. Both the entered ratio and the resulting simplified ratio shall be added as user input for auto-completion.
−	#very similar to Random Pick. same artsy faux oil painting effect.
−	#also not necessary in the standard distribution.
−	====Spread====	+	====auto-completion====
−	#Big difference between realistic and far out range.
−	#We could have a sticky mark for normal range and the far out-nonrealistic range.
−	====Noise Filter Ideas====	+	The textfield shall have auto-completion, Firefox URL-field style. In ratio mode, '/' and ':' shall be treated as fully equivalent. In size mode, '*', 'x' and 'X' shall be treated as fully equivalent. That means that is one is typed, it shall match any other in the previous user input. Only unambiguous user input shall be stored for auto completion re-use for the particular mode. It shall be persisted for a week after being entered or being re-used.
−	#One jitter dialog that controls spread amount, randomisation, nr of pixels, maybe even repeat.
−	#and also just two algorithms for pixel noise. One filter for good, realistic, photographically usable noise (but not fake film grain), and one for non-realistic, random, experimenter noise.
−	===Edge Detect ===	+	===checkbox and the shift key===
−	In general we are not impressed with these tools for the task of detecting edges.
−	====Difference of Gaussian====	+	When the checkbox is checked, the constraint that is set by the user with the ratio/width/height/size pop-up list shall be enforced while rubber-banding a rectangle. Pressing the shift key while rubber-banding shall toggle the checkbox in the other state. Only users shall be able to explicitly toggle the checkbox directly or with the shift key. Under '''no circumstance''' shall GIMP itself ''get smart'' and toggle the checkbox, particularly not as a result of users entering or clearing text in the textbox.
−	#It has potential, maybe with different input parameters
−	#It can lead to interesting effects, but right now it’s difficult to get there. Neither for detection edges and experimentation now, but the potential is there for both tasks.
−	#Better interface might it work.
−	====Edge Detection====	+	The two icons shall be just icons, not inside pushbuttons like in the New file dialog. '''No state''' shall be reflected by the icons. this just leads to unnecessary noise in the interface. Clicking one of the icons shall simply enforce portrait or landscape in the textfield by swapping the two number values when necessary.
−	#We recognize that we can need this filter for further use as input for other filters.
−	#However, it doesn’t make good enough contours.
−	====Laplace====	+	===tool options===
−	Too simple, didn’t really worked on the images we tried.
−	====Neon====	+	From all three tool option panels, all the Fix buttons shall be removed.
−	#Adds some strange cloth pattern.
−	#There could be the 2 dimensional (input square) way to set the values.
−	#For general purpose of experimentation it’s good. It has potential.
−	====Sobel====	+	The Width field shall be greyed-out when either fixed width or fixed size is enforced by the user. The Height field shall be greyed-out when either fixed height or fixed size is enforced by the user.
−	A bit too simple.
−	===Generic===	+	All lines that contain textfields shall be sized such that they just fit inside a tool option panel that is 6 tool icons wide (the default).
−	====Convultion Matrix====	+	The guides pop-up menu left side shall be aligned with the left sides of the checkboxes, the pop-up menu right side shall be aligned with the left sides of the textfields.
−	Not for our scenarios, rather something for mathematicians. not in GIMP distribution.
−	====Dilate  and Erode====	+	For the crop tool there shall be a new checkbox in the options panel: 'allow growing' (default: unchecked). Normally limiting cropping to the exact edges of the layer/canvas has the highest priority, hence the rules above. This checkbox overrides that, and the layer/canvas can be size up by dragging a bigger rectangle around it.
−	#they bring some oil-painting effects, which there are too many of
−	#Should go rather to artistic filters, or just disappear.
−	#No control over it.
−	===Combine===	+	===highlight/darkening of the crop tool===
−	====Depth Merge====	+	Even when the Highlight checkbox is checked, the darkening
−	#Not very useful	+	effect shall not be displayed during rubber-banding. This
−	#It can  be done  better by layer and layer mask.	+	allows for precise adjustments.
−
−	====Film Strip====
−	#One trick pony
−	#Not good enough, too artificial, better would be a real filmstrip.
−
−	==Comparing different approaches==
−	#to support this (trying two or more artistic strategies), we need to introduce a very simple versioning system, with branching.
−	#‘tree of versions’ -each of them would have a stack of layers, which has a stack of treatments.
−	#Saving a point in time would mean labelling it. Labelling the versions, changing the names 1.0,1.1,1.2…
−	#Branches – the structure should support moving the layers between versions.
−	#Side by side comparison by choosing different versions.
−	#Merging two versions: to be discussed later.
−
−	==Wild Brush Work==
−	#There could be filter brushes with parameters in the dialog box. (maybe even scrolling through filters to try them out could be possible).
−	#creating color palettes is convoluted.
−	#What we want to achieve is to paint in the same layer (if one prefers), and be able to control which paint/effect is more prominent in a chosen area, by just 'brushing' on some more of it. this mimics the ambivalence of physical painting: it both mixes with and covers existing paint when you brush it on.
−
−	===Brushes===
−	#users want to adjust their brushes on the fly, just by pressing keys, user should be able to change the parameters.
−	#Brushes need shortcut for: color picker, opacity (not sure about the steps, that should be applied- it should be measured with usability methods), radius/size of brush.
−	#User could also ‘cycle’ through all 4 main paint 'modes' (airbrush, ink, pencil, brush). But opacity and scale of the brush has the absolute priority.
−	#It is important that for these 2 comments that the user would keep his hand on the keyboard in the same position.
−	#When changing paint modes we need to think whether to take care about the continuity of the size/opacity, or not, because the second tool might be a complementary tool.
−
−	===Working with Palettes===
−	#idea: blobs of paint on the edge of your window, just drag a color to this area.
−	#User could add blobs it with eye-dropper, or even could drag an effect (neon filter) on it, and paint with it.
−	#this palette of blobs is easy come, easy go, very temporarily and only for one file.
−	#even allow mixing of colors from blobs on this palette?
−	#color names don’t matter, unless user really want to give a name, then names would appear as tooltips, but user would never be forced to give names.
−
−	==Text==
−	#We should change the Close button into Done in the text input dialog.
−	#When choosing a font, also in the dropdown you should have a possibility to type in the first letter and see the first entry starting with it (like in the textbox beside it).
−	#GIMP text editor- when checking the ‘use selected font’ then the cursor disappears and there is no focus.
−	#Typing directly on layer would be a better solution.
−	#it should be possibility to select an area to fit the text in text. The area would be a text 'column'. However we also like the fact that one click sets the top-left corner of an (unlimited) text block.
−	#It would be useful if the text could wrap around when reaching side edge of the canvas.This has to be optional.
−	#RTL mode seems not to work.
−	#idea: text box concept, user could have possibility to resize the text box and it would not be based on layer dimensions.
−	#When opening a text file only the files with right extensions would be open, and if an error appears, then there should be a good error message saying which file types are supported.
−	#It is difficult to move the text (in the Pick a layer or guide mode of the Move tool), because you need to click exactly in a rendered pixel of the text.
−	#There should be possibility to group the text together for some operation, like color changes. But it should give possibility to keep the sizes different.
−	#Resizing the text –should it be vector or pixel? Pixel- gives possibility to apply filters. User could start with vector, then change to pixel and apply operations/filters, then come back to vector, and all the effects should be still there.
−	#Spacing/kerning—needs to be investigated- typographical requirements.
−	#Still there should not be too many features. not add page layout functionality.
−	#We need to think whether the text tool should always select a piece of already existing text, or always start a new one. Because it’s a problem to find a text when there is a lot of text, but on the other hand if you want to create overlapping text , it is difficult, because you don’t create a new layer, just stick to the old one.
−	#Paths- when creating a path, it should be visible by default.
−	#Bug fixes- the text doesn’t match the path so well.
−	#Create Path from Text creates fine results for deforming texts, substitute of Vector.
−	#Text along path: Why does it always deform the text. probably it needs an option,
−	#The inspector, toolbox buttons could be replaced with heads up display.
−	#menu options for text should not appear in the Layers menu. we need a new concept where these menu items go.
−
−	==Saving==
−	#User shouldn’t be able to use any tool while saving (for ex. a brush). Even if it doesn’t save what got changed while saving.
−	#the most important thing about saving is that one saves '''exactly this picture''', and '''right now'''.
−	#we need a big preview img window, but without rulers, menu bar, etc.
−	#We could set by default one tool while saving- i.e. Zoom tool, to see the quality details.
−	#We don’t like the solution to place quality slider and other settings in the existing image window.
−
−	====saving jpeg for web====
−	#There should be a really big dialog with a big preview. The dialog should be as big as the image window at the moment.
−	#some advanced options are too technical
−	##Priority A options have to be always visible, other should be ordered by categories but in collapsed advanced sections. We need to give them subheadings.
−	##priority A: quality slider, preview, optimized checkbox, maybe progressive (progressive size order – could GIMP know which gives in a result the smallest size)
−	##priority B other saving categories – i.e. smoothing
−	##priority C restart markers, sub sampling, dct method
−	#There is at the moment no Save for Web dialog.
−
−
−	[[User_Scenarios#2._Creating_Original_Art|read User Scenario for these notes]]

---

Revision as of 11:34, 1 August 2007

intro

This is the specification for the rectangle + oval selection, and the crop tools. It is based on the state of GIMP 2.3.13, and is now updated with the realities of 2.3.18.

on units, sizes and visible

All sizes in this spec are in on-screen pixels. This means that the zoom level has an influence on everything. A 30x20 in-image rectangle can be displayed on screen as 300x200, and vice versa.

Also the panning of the image has an influence on everything. Only the visible part of the bounding rectangle goes into the size calculations. Example: a 123x45 image rectangle is viewed at 1000%, only the left-most 2/3rd and top half of the rectangle is visible in the image window: 820x225 on-screen pixels go into the calculations ( 123*10*2/3 and 45*10/2).

decision time

The right moment to recalculate handle sizes and decide if there is a narrow situation shall be after through zooming, panning or actual bounding rectangle size change, the on-screen pixel size of the bounding rectangle has changed. It is explicitly not desirable to do this during zooming, panning or actual bounding rectangle size change.

handling the bounding rectangle on the canvas

pending

Between being created and being committed (by means of a single mouse click in its area or the enter/return key), a rectangle is called to be in pending state.

The algorithm for the size of the corner handles (handle height = bounding rectangle height / 4, CLAMPed by 6 and 50, handle width = bounding rectangle width / 4, CLAMPed by 6 and 50) allows fast interaction:

what is black in this image shall be rendered inverted on the canvas. note that at any time the marching ants of a selection edge can obscure an inverted line.

Each corner handle shall enable users to resize the bounding rectangle by dragging one of them, where the diagonally opposite corner of the bounding rectangle shall be the anchor point.

The rectangle cornered by the corner handles shall be the move handle: one big handle where users shall be able to move the bounding rectangle around the canvas by initiating a drag in this handle:

the gray area shown here is purely for illustration in this spec and shall not be rendered in GIMP

Areas between two adjacent corner handles are called side handles.

The height of the two horizontal side handles shall be exactly the corner handle height, and their width shall be the (bounding rectangle width - 3 * corner handle width), CLAMPed on the lower side by 6.

The width of the two vertical side handles shall be exactly the corner handle width, and their height shall be the (bounding rectangle height - 3 * corner handle height), CLAMPed on the lower side by 6.

All side handles shall be exactly centred on the side they are attached to. If the side of the of the bounding rectangle is an odd number of pixels long, then the attached side handle shall be an odd number of pixels long. Similarly: if even, then even. When this adjustment is needed, it shall be done by increasing the handle size by one pixel.

the gray area shown here is purely for illustration in this spec and shall not be rendered in GIMP

This all makes the size of the side handles predictable (and thus faster to use each time) where it counts most (their smallest dimension) and uses their largest dimension to leave a gap to reach the corner handles from within.

Each side handle shall enable users to resize the bounding rectangle by dragging one of them, moving the side it is attached to, where the mid-point of the opposite side of the bounding rectangle shall be the anchor point.

What is left within the bounding rectangle are the dead areas, a drag by users starting in these shall do nothing, neither move, nor resize. This is to prevent accidental move when trying to resize, or accidental resize when trying to move:

the gray area shown here is purely for illustration in this spec and shall not be rendered in GIMP

In the implementation the dead areas shall be used as ‘bumpers’ to reconcile the rounding-off effects in the sizes of the corner and side handles. The dead areas are simply what is left over in area of the bounding rectangle.

fixed width/height/size

When users are enforcing fixed width or height in the pending state, the rectangle handles shall reflect this. Showing corner handles does not make sense, because only two of the sides can be adjusted. Therefore these two side handles shall be displayed (fixed height, left; fixed width, right):

With no corner handles to compete with, the side handles shall occupy the whole side of the bounding rectangle. The height of the top and bottom handles and the width of the left and right handles shall be calculated as usual. The rest of the bounding rectangle area shall be the move handle:

the gray area shown here is purely for illustration in this spec and shall not be rendered in GIMP

When users are enforcing fixed size in the pending state, the rectangle handles shall reflect this. Showing corner handles does not make sense. The whole bounding rectangle area shall be one big move handle:

the gray area shown here is purely for illustration in this spec and shall not be rendered in GIMP

highlighting

When the sprite (mouse cursor) hovers over a corner handle, it shall highlight by inwardly doubling its perimeter line, and by hiding the other 3 corner handles:

When the sprite hovers over a side handle, it shall highlight along the whole side of the bounding rectangle with a 1-pixel line, to communicate that it moves the side. The other dimension of the highlight rectangle shall be that of the corresponding side handle. Also there shall be a 2-pixel line along the perimeter of the side handle itself. This is important because this is the only opportunity we have to communicate the size of the handle in a non-obstructive way. The two corner handles on the opposite side shall be hidden:

fixed width/height

As an implication of enforcing fixed width or height in the pending state, the side handles shall highlight as shown here:

rubber-banding

When the mouse goes down inside a corner handle and dragging commences, it shall be displayed and the other 3 hidden, to achieve a minimal-obstruction display:

When the mouse goes down inside a side handle and dragging commences, it shall display a rectangle along the whole side of the bounding rectangle with a 1-pixel line. The other dimension of this rectangle shall be that of the corresponding side handle. The two corner handles on the opposite side shall be hidden:

Corner handles shall not change in size during the rubber-banding of the size of the bounding rectangle. This is necessary to achieve a stable cause-and-effect relationship between the position of the sprite, and the size of the bounding rectangle.

• Side handles shall track the dimension of the bounding rectangle on the side aligned with it, while the other side shall not change in size during the rubber-banding;
• On creation of a new rectangle, the handle size shall be the minimal handle size;
• When either side of a corner handle, or the not-bounding-rectangle-aligned side of a side handle, is equal or greater that the corresponding side of the bounding rectangle, the handle shall not be displayed during rubber-banding.

cursor keys

The most important thing about enabling cursor keys for moving/resizing the bounding rectangle is that it shall be exactly the same user experience as performing the same operation with a mouse click. The only exception to this is that when resizing due to a cursor key press, the rubber-banding display shall be skipped.

• When the mouse is over one of the corner or side handles, and one of the up/down/right/left cursor keys is pressed, the rectangle shall be resized by one (shift: 15) image pixel in that direction.
• When the mouse is over the move handle, and one of the up/down/right/left cursor keys is pressed, the rectangle shall be moved by one (shift: 15) image pixel in that direction.

This interaction is not complete until the goal of keeping the sprite stable on the handle has been achieved. We depend on bug #362915 to be fixed, then we can explore feasible solutions.

think small

Both corner and side handles have a minimum size of 6 pixels. This will work for bounding rectangles down to a size of 18 pixels. Here we see rectangles with one and two dimensions of 18 pixels, also showing the side handles:

the gray area shown here is purely for illustration in this spec and shall not be rendered in GIMP

If the size of one of the sides of the bounding rectangle is below 18 pixels, we have a narrow situation. This can be caused by actually narrow-sized bounding rectangles, but also by zooming out and panning out of view. The obvious work-arounds for this (zoom in, pan in) are productivity eaters, we need a real solution.

Move the handles outside. Here we see rectangles with one and two dimensions of 17 pixels:

In a narrow situation, the following specs change:

• The corner handle size shall be 15x15 pixels, always.
• If the the bounding rectangle has a non-narrow side, the long side of the side handle shall be (bounding rectangle side length - 2 * 15), CLAMPed on the lower side by 18, the short side of the side handle shall be 15 pixels.
• On the narrow sides, the size handles shall simply fill the space between the two corner handles:

the gray area shown here is purely for illustration in this spec and shall not be rendered in GIMP

There shall be only dead areas on a non-narrow side:

the gray area shown here is purely for illustration in this spec and shall not be rendered in GIMP

The move handle shall be equal to the bounding rectangle:

the gray area shown here is purely for illustration in this spec and shall not be rendered in GIMP

Highlighting is unchanged:

As is dragging:

interaction with the canvas edge

In general it shall be possible to start a crop/selection rectangle outside the canvas, or to take the edges of the bounding rectangle outside the canvas. Below is specified what happens in these cases:

selection tools

When one or more edges of the bounding rectangle is outside the canvas, then the canvas edge shall clip the effective selection. The interaction shall reflect this by showing the bounding rectangle in whatever size and position that users take it and the effective selection marching ants along the canvas edge where clipped. Especially with the elliptic select tool, this is part of creative workflow.

However:

• If users enforce a fixed ratio of the bounding rectangle and one or more edges of the bounding rectangle is outside the canvas, then all of these edges shall be aligned with the corresponding canvas edges, and the from the resulting new bounding rectangle sizes the ratio enforcement shall be calculated. The interaction shall reflect this by showing the bounding rectangle in the newly calculated position;
• If users enforce a fixed width of the bounding rectangle and the left or right edge of the bounding rectangle is outside the canvas, then this edge shall be aligned with the corresponding canvas edges, and the from the resulting new bounding rectangle sizes the width enforcement shall be calculated. The interaction shall reflect this by showing the bounding rectangle in the newly calculated position; if the fixed width is greater than the actual canvas width, then the full width of the canvas shall be used;
• If users enforce a fixed height of the bounding rectangle and the top or bottom edge of the bounding rectangle is outside the canvas, then this edge shall be aligned with the corresponding canvas edges, and the from the resulting new bounding rectangle sizes the height enforcement shall be calculated. The interaction shall reflect this by showing the bounding rectangle in the newly calculated position; if the fixed height is greater than the actual canvas height, then the full height of the canvas shall be used;

crop tool

When the 'allow growing' option has been invoked by users, then the crop tool shall be in no way limited by the canvas or layer edge. In the other case:

When one or more edges of the bounding rectangle is outside the canvas, then all of these edges shall be aligned with the corresponding canvas edges. The interaction shall reflect this by showing the bounding rectangle in the newly aligned position.

For fixed ratio/width/height: see selection tools above.

If the 'Current layer only' option has been invoked by users, then all all behaviour specified above shall apply, substituting the layer (edge) for the canvas (edge).

the fixed ratio/widht/height/size and the shift key

Between the 'Expand from centre' and Highlight checkbox there shall be the Fixed ratio/width/height/size control:

It is a checkbox, with (new) a pop-up list in the first row, combined with a single textfield and two icons (portrait; landscape) in the second row. The pop-up list shall contain the items 'Aspect ratio', Width, Height, Size, in that order. The default shall be 'Aspect ratio'.

The width and height modes shall not display the icons:

The size mode is most identical to the ratio mode:

textfield input

It is extremely important that the textfield shall be a single textfield with no up/down arrows. This allows for quicker input.

• in ratio mode, the textfield shall accept the formats A/B and A:B, where A and B are two floating point numbers;
• in width and height modes, the textfield shall accept a single floating point number;
• in size mode, the textfield shall accept the formats A*B, AXB and AxB, where A and B are two floating point numbers. A shall be the width, B shall be the height.

Before parsing the input, all white space characters shall be stripped out. The input shall be committed by a <return>, <enter> or a input focus change out of the textfield and shall be one of three kinds:

1. unambiguous user value; User override state shall be entered for this particular mode (ratio, size, etc.) for all images, for the rest of the session; the user entered value shall be used for this mode;
2. unambiguous user clear; apart from that stripped out white space, nothing else was entered in the textfield; this shall enter the default state for this particular mode (ratio, size, etc.) for all images, for the rest of the session; the default value shall be displayed and used for this mode;
3. anything else is ambiguous; no state or value change shall be undertaken; the value displayed before users' text input shall be restored.

Default values:

• in ratio mode, the default value for the textfield shall be "1:1" for the selection tools; for the crop tool it shall be <current layer/canvas width>:<current layer/canvas height> when there is no pending crop rectangle and <crop rectangle width >:<crop rectangle height> when there is a pending crop rectangle; this value shall not change during rubber-banding;
• in width mode, the default value for the textfield shall be <current layer/canvas width>;
• in height mode, the default value for the textfield shall be <current layer/canvas height>;
• in size mode, the default value for the textfield shall be "100x100", [this is a random value, I am open for suggestions for a more useful default here].

mathematician's Easter egg

In ratio mode, when the users' input is terminated with a '=' character, the entered ratio shall be simplified to the to lowest integer numbers that faithfully represent the ratio. The '=' character shall not be displayed after siplification. Both the entered ratio and the resulting simplified ratio shall be added as user input for auto-completion.

auto-completion

The textfield shall have auto-completion, Firefox URL-field style. In ratio mode, '/' and ':' shall be treated as fully equivalent. In size mode, '*', 'x' and 'X' shall be treated as fully equivalent. That means that is one is typed, it shall match any other in the previous user input. Only unambiguous user input shall be stored for auto completion re-use for the particular mode. It shall be persisted for a week after being entered or being re-used.

checkbox and the shift key

When the checkbox is checked, the constraint that is set by the user with the ratio/width/height/size pop-up list shall be enforced while rubber-banding a rectangle. Pressing the shift key while rubber-banding shall toggle the checkbox in the other state. Only users shall be able to explicitly toggle the checkbox directly or with the shift key. Under no circumstance shall GIMP itself get smart and toggle the checkbox, particularly not as a result of users entering or clearing text in the textbox.

The two icons shall be just icons, not inside pushbuttons like in the New file dialog. No state shall be reflected by the icons. this just leads to unnecessary noise in the interface. Clicking one of the icons shall simply enforce portrait or landscape in the textfield by swapping the two number values when necessary.

tool options

From all three tool option panels, all the Fix buttons shall be removed.

The Width field shall be greyed-out when either fixed width or fixed size is enforced by the user. The Height field shall be greyed-out when either fixed height or fixed size is enforced by the user.

All lines that contain textfields shall be sized such that they just fit inside a tool option panel that is 6 tool icons wide (the default).

The guides pop-up menu left side shall be aligned with the left sides of the checkboxes, the pop-up menu right side shall be aligned with the left sides of the textfields.

For the crop tool there shall be a new checkbox in the options panel: 'allow growing' (default: unchecked). Normally limiting cropping to the exact edges of the layer/canvas has the highest priority, hence the rules above. This checkbox overrides that, and the layer/canvas can be size up by dragging a bigger rectangle around it.

highlight/darkening of the crop tool

Even when the Highlight checkbox is checked, the darkening effect shall not be displayed during rubber-banding. This allows for precise adjustments.