Meeting notes: Jan 23

Risk Mitigation paper adjustment
	<<Already in progress, due to a late class>>
	Image management *New Risk*
		Keep an original and do cool things to the copy
	Freehand completion *New Risk*
		Should we cover for "finger-hopping"?
			Probably
		Should we complete a shape, even if it wouldn't work out?
			Yes, that's what Undo is for
			It would be very nice to anticipate the curve…
				Too much computing
				What if they're trying to make a star?
				Maybe in the end if we finish the whole project too quickly
	Cropping
		Should it be done with masking rather than actually cutting out a section?
			It'll work more like the feathering
			You're still going to draw the whole image - even if it's invisible
				Detecting which image is touched may be tricky.
					Image stack object should be given a point and it'll ask about the alpha value.
	Wish we could say that "Team Issues" is closed, but we can't be too sure yet…
	
	Running risk factor: 39%  Previously 41% (See risk sheet, page 2, for full stats)
	Fair amount of argument about the best way to display the risk factor
		Pie?  Line?
		We'll decide later when it's more than 2 lines.
		
	Risk document owner: Stephen


Requirements walkthrough
	Chris is okay with presenting the whole requirements doc

Architecture
	Name everything "K<Component>" to prevent naming issues

	Image transformations:
		Does the image keep its own transformation information?
		Who remembers the feathering value?
		Each image can have a reference to the same feathering transformation
		
	Pipelined Transformations:
		Each image has a list of transformations
			resize, feather, rotate…
		When asked to draw itself, it will run through the transformations
		Saving the result as a composite for quick drawing.
		When the transformations are changed, a flag will be set to recalculate on the next draw invocation.
		Transformations can combine themselves, keeping the queue as empty as possible

	Transformer (Singleton)
		Knows the order that the transformations are supposed to be done.
			Skips the transformations that don't need to be run.
			May be the cause of some overhead, but it'll be very extendable
		The logic of the transformations
	
	Canvas
		We Should stick to the C# basic panel
		Ordered collection of all the images
		Does the grid show up above the images?  Below the images?
			Solve that one later, but the canvas will know
			
	Undo-Functionality
		Memento Pattern
		Everything needs a "copy" method so the state can be saved
		Will need a "MemControl" class somewhere
		
	And we're closing off here.  We'll attack more of the architecture next week