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

Revision as of 18:31, 19 March 2007 (view source) Guiguru (talk) (→‎Image window issues)		Revision as of 11:34, 1 August 2007 (view source) Guiguru (talk) (→‎fixed width/height/size)
Line 1:		Line 1:
−	== introduction ==	+	==intro==
−	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:'''	+	This is the specification for the rectangle + oval selection, and the
−	creating original art, a collage of found images and wild brushwork.	+	crop tools. It is based on the state of GIMP 2.3.13, and is now updated with the realities of 2.3.18.
−	==Open New File==	+	==on units, sizes and visible==
−	#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 ==	+	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.
−	#It needs Ghostscript, so this should come as an installer option.	+	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).
−	#something wrong with sizing the pages preview
−	==Image window issues ==	+	===decision time===
−	#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 ==	+	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.
−	#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==	+	==handling the bounding rectangle on the canvas==
−	#GIMP is partially duplicating functionality of a system, but we appreciate it also takes a print screen 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 print screen of a single window
−	#Other options would be available in a plugin.
−	==Acquire Scanner/Camera.. ==	+	===pending===
−	#Separate interface item for webcam, scanner, camera.
−	#Right now Source window enables choosing right device, but the Source window would be shown just when there are more cameras, or scanners connected.
−
−	==Layers ==
−	We need organizing layers in folders.
−
−	==Layer Modes ==
−	Their names should be as explicit as possible. We know there are a lot of them, but when using them for a longer time you can now/predict their result.	+	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.
−
−	Alpha channel should be more treatable.	+	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:
−	==Posterize==	+	[[image:2.4_basic_corners.png]]
−	Nice and straightforward, but effective rather only for low ranges (just below value 33 something really happens).	+	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.''
−	==Colorize==	+	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.
−	#Works well, but it wouldn’t make the img realistic.
−	#Maybe it shouldn’t be grouped with all other major colour filters.
−	#The first 2 sliders should be replaced with colour wheel. Slider for lightness should remain.
		+	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:
−	=Filters=	+	[[image:2.4_move_area.png‎]]
		+	''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.
−	==Auto Filters==	+	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.
−	#Probable aimed at photographers, but they wouldn’t trust those filters.	+	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.
−	#On contrary those filters make nothing spectacular for graph designers.
−	==Components==	+	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.
−	===Channel mixer===	+	[[image:2.4_side_handles.png‎]]
−	#Values should be in percents.
−	#It works for monochrome, to stop when 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’). Other tools could work in a similar way.
−	#Not yet solution for experimentation.
−
−	===Decompose===
−	#Not very useful in this scenario
−	==Adjust==	+	''the gray area shown here is purely for illustration in this spec and shall not be rendered in GIMP''
−	Does nothing interesting.	+	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.
−	==Map==	+	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.
−	===Alien Map===	+	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:
−	#Does sth radical, it is rather interesting.
−	#No reset button or saving.
−	#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 experiment, and also give user bigger control over what he 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, like instead of ‘red frequency’ – ‘red wobbles’, instead of ‘red phaseshift’- just ‘shift’ or ‘wobble shift’.
−	#Now using check box doesn’t mean deactivation, but invisible effect of those setting, so maybe we shall put an eye icon.
−	#New settings for default (0,7).
−	===Color Exchange===	+	[[image:2.4_dead_areas.png‎]]
−	#There should be different threshold set above zero, because the changes are unnoticeable.
−	#In color dialog Hue value changes per 30 when you click at some point, and it doesn’t stop in clicked point.
−	#In CMYK values changes per 10, but there is a reason for that. In CMYK you don’t see colors, on the right- HSV you see colors, and you chose exact color. ‘Look and feel wall.’
−	===Map Color Range===	+	''the gray area shown here is purely for illustration in this spec and shall not be rendered in GIMP''
−	#The direction of how the color changes from the first range to the second should be presented.
−	#It’s nice to specify 4 points, but tight now it isn’t controllable, because user can’t see what color points are included.
−	===Gradient Mapping, Palette Mapping===	+	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.
−	Nice and quick	+	====fixed width/height/size====
−
−	===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 probable always be degrees.
−	#Gray mode probable has still some bugs. We are not sure why gray shift is implemented in Color rotation.
−	===Sample Colorize===	+	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):
−	#Nice effects, but looks sloppy, because of bad update. It should update once per sec while user is sliding around.
−	#It seems the preview sometimes differ from the result.
−	#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’.
−	#Mulit tonning idea (?)
−	#Problems with show selection.(?)
−	#The dialog should be rearranged.
−	#There should be Apply, Cancel, OK buttons.
−
−	The creating a gradient for more complex colorizing is too difficult now.	+	[[image:2.4_constant_wh_handles.png]]
−	==Color Filters==	+	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:
−	===Colorify ===	+	[[image:2.4_constant_wh_move.png]]
−	#It should have good color picker instead of few custom colors.
−	#Doesn’t seem to meet the goals of photographers.
−	#Make the inspector ‘invisible’, when you use them they are too prominent.They could be black&white for a big contrast.
−	===Invert and Value invert===	+	''the gray area shown here is purely for illustration in this spec and shall not be rendered in GIMP''
−	Nice and quick	+	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:
−	===Desaturate===	+	[[image:2.4_constant_size_no_handles.png]]
−	#Most of the people don’t distinguish lightness and luminosity.
−	#It should have preview.
−	#Maybe change the names to brightness too.
−	===Color to Alpha===	+	''the gray area shown here is purely for illustration in this spec and shall not be rendered in GIMP''
−	#Color picker in general in all these dialogs should all be as good as the one in the color picker in toolbox.
−	#Controllability of it should be improved.
−	===Filter Pack Simulation===	+	===highlighting===
−	Very badly implemented in UI. Not relevant.	+	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:
−	===Maximum RGV Value===	+	[[image:2.4_corner_highlight.png‎]]
−	Direct enough.	+	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:
−	===Retinex===	+	[[image:2.4_side_handles_highlight.png‎]]
−	#It’s very good for it’s original intent and experiments, but needs goal oriented UI.
−	#Technical parameters don’t make a use if you don’t write the parameters on some paper.
		+	====fixed width/height====
−	==Artistic==	+	As an implication of enforcing fixed width or height in the pending state, the side handles shall highlight as shown here:
−	===Apply Canvas===	+	[[image:2.4_constant_wh_highlight.png‎]]
−	Simple enough, although we wouldn’t recommend it to professionals. One trick pony.	+	===rubber-banding===
−	===Cartoon===	+	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:
−	Should stay, easy to control and gives nice effects.	+	[[image:2.4_corner_drag.png‎]]
−	===Clothy===	+	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:
−	Rather not good for experimenting, because there is no preview.	+	[[image:2.4_side_handles_drag.png‎]]
−	===Cubism===	+	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.
−	Shouldn’t stay in core GIMP.	+	==cursor keys==
−	===Photocopy ===	+	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.
−	Nice effects. We should keep it, however it is not very artistic.
−	===GIMPrassionist===	+	* 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.
−	It is powerful, but there are too many options too even start experimenting.Why would a user start doing it in one dialog at the same time?	+	*  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.
−	===Oilify===	+	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.
−	One trick pony.
−	===Predator===	+	==think small==
−	Interesting, but definitely needs a preview.
−	===SoftGlow===	+	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:
−	Good, it does what it shows
−	===Van Gogh===	+	[[image:2.4_mini_sizes.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 do what it says.
−	===Weave===	+	''the gray area shown here is purely for illustration in this spec and shall not be rendered in GIMP''
−	It has no preview but quite a lot of parameters. The effect is rather kitsch.
−	==MAP==	+	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.
−	===Bump Map===	+	Move the handles outside. Here we see rectangles with one and two dimensions of 17 pixels:
−	Interesting, but needs less and better parameters.
−	===Displace===	+	[[image:2.4_maxi_narrow.png]]
−	The effort spend on trying to understand the parameters is not worth the effect. The parameters are too difficult to understand.
−	===Fractal Trace===	+	In a narrow situation, the following specs change:
−	Not useful enough for creating bg.
−	===Illusion===	+	* The corner handle size shall be 15x15 pixels, always.
−	Straightforward. Either the like the effect or not. Peter says- no, Kamila says, that used in a correct way might give good results.	+	* 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:
−	===Make Seamless===	+	[[image:2.4_narrow_side_handles.png‎‎]]
−	Very simple and straightforward.
−	===Map Object===	+	''the gray area shown here is purely for illustration in this spec and shall not be rendered in GIMP''
−	#Not for Web Desinger, not in this scenario.
−	#A plugin with light adding would be a good idea, but a specialized one.
−	#Material is interesting, but you could make it a new plugin.
−	===Paper Tile===	+	There shall be only dead areas on a non-narrow side:
−	#Bad interface, because you need to set the things and see what happens.
−	#Does the values have to be connected together?
−	#Shouldn’t stay.
−	===SmallTiles===	+	[[image:2.4_narrow_dead_areas.png]]
−	#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===	+	''the gray area shown here is purely for illustration in this spec and shall not be rendered in GIMP''
−	Is there any reason why it should be there? It is rather unnecessary to stay.
−	===Warp===	+	The move handle shall be equal to the bounding rectangle:
−	#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 he wanted to achieve?
−	#If we can make it simple then, then it is ok, we need to find purpose for it.
−	==Render==	+	[[image:2.4_narrow_move_handle.png]]
−	Create new graphic without taking care about  the image. New things are being drawn for the user. That is not very professional.
−	(...)
−	==Blur==	+	''the gray area shown here is purely for illustration in this spec and shall not be rendered in GIMP''
−	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 implement wheel.
−	===Tileable Blur===	+	Highlighting is unchanged:
−	#It can have vertical and horizontal parameter 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==	+	[[image:2.4_narrow_highlight.png]]
−	===Deinterlace===
−	Quite good for adding missing rows when capturing img form camera.
−	===Despectle===	+	As is dragging:
−	Maybe more for experiments than for despectling.
−	===Destripe===	+	[[image:2.4_narrow_drag.png]]
−	Easy and straightforward for adding stripes.
−	===NL Filter===	+	==interaction with the canvas edge==
−	Doesn’t improve the image in expected way, not for photographers.
−
−	===Red Eye Removal===
−	(...)
−	==Filter values issue==	+	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:
−	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==	+	===selection tools===
−	===Blinds ===	+
−	Rather not for professionals, not in this scenario at least.	+	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.
−	===Curve Bend===	+
−	#This should be done in a direct way by a tool, not a filter.	+	''However:''
−	#It should also enable vertical and horizontal changes.	+
−	Useful probable for creating flags.	+	* 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;
−	===Emboss===	+	* 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;
−	#The effect is interesting, but there should be better description of the parameters.	+	* 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;
−	#For the light setting it would be better to have some kind of light rotation.	+
−	===Erase every other row===	+	===crop tool===
−	#Gives a good effect; straightforward.	+
−	#But better controls would make it even better, probable some radio buttons instead of dropdowns.	+	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:
−	===IWarp===	+
−	It should be done by a brush.	+	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.
−	===Lens distortion ===	+
−	#Too settle here (?)	+	For fixed ratio/width/height: see selection tools above.
−	#(not in Windows/version 2.3.11)	+
−	===Mosaic===	+	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).
−	Not useful for this scenario; kitsch alert.	+
−	===Newsprint===	+	==the fixed ratio/widht/height/size and the shift key==
−	#Really good for this task, but it should have better controls, than now.	+
−	#It’s worth to spend time on this filter, great effect.	+	Between the 'Expand from centre' and Highlight checkbox there shall be the Fixed ratio/width/height/size control:
−	===Page curl===	+
−	Not useful for this case; kitsch alert.	+	[[Image:2.4_constant_ratio_control.png]]
−	===Polar Coordinates===	+
−	Not useful here, and probable nowhere.	+	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'.
−	===Ripple===	+
−	Quite essential distortion mechanism, but needs some better parameters	+	The width and height modes shall not display the icons:
−	===Shift===	+
−	Straightforward, good enough.	+	[[Image:2.4_constant_wh_controls.png]]
−	===Value Propagate===	+
−	We are not really sure of its goal, seems not very powerful	+	The size mode is most identical to the ratio mode:
		+
		+	[[image:2.4_constant_size_controls.png]]
		+
		+	===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:
		+
		+	# 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;
		+	# 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;
		+	# 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.

---

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.