I've generally tried to keep the image arguments last to make nested compositions of functions easier to read. Since we have to keep frame for backwards compatibilities reasons regardless, I don't think we need to worry about making color-frame's color argument optional.
Robby On Fri, Jun 27, 2014 at 12:38 PM, Kevin Forchione <lyss...@gmail.com> wrote: > > On Jun 22, 2014, at 9:42 PM, Robby Findler <ro...@eecs.northwestern.edu> > wrote: > >> Thanks! I've added these two functions. >> >> Robby >> >> On Sun, Jun 22, 2014 at 12:26 PM, Kevin Forchione <lyss...@gmail.com> wrote: >>> >>> On Jun 21, 2014, at 5:02 PM, Robby Findler <ro...@eecs.northwestern.edu> >>> wrote: >>> >>> What do you think about a variant on center-crop called crop/align >>> that accepts a width, a height, an image, and an x-place and a >>> y-place? >>> >>> That would seem to fit better into the library the way it's currently >>> constructed. >>> >>> For working around the frame issue, how about just a color-frame >>> function that controls the color for now? >>> >>> >>> I agree! That’s even better in terms of use and simplicity. >>> >>> -Kevin > > One question about color-frame’s arguments. I’ve played with it in the latest > push, and it’s > > (color-frame color image) > > with color being first and required. Would it be better to have it 2nd and > default to ‘black, so that by default color-frame reduces to frame? > > -Kevin > _________________________ Racket Developers list: http://lists.racket-lang.org/dev
