sync

TODO

@@ -1,16 +1,8 @@
 
-- bandalike: consider RGB + RGBA ... we should bandup by adding a black band
-
-  (or white?? unclear)
-
 
 
 
 
-- note member free stuff in vipsobject docs
-
-  should boxed get freed in finalise rather than dispose?
-
 - vipsimage should be cached too, eg.
 
 	VipsImage *a = vips_image_new_from_file( "poop.jpg" );
@@ -20,6 +12,8 @@
 - we should cache on "written" ... we should emit written for all objects, and
   there should be a a vipsarg flag to block updates after written
 
+- we have a "written" method/signal in image.h, move this to object.h
+
 - the lifetime of an object is
 
 	  new
@@ -56,21 +50,19 @@
 
 
 
+- bandalike: consider RGB + RGBA ... we should bandup by adding a black band
+
+  (or white?? unclear)
+
+  not clear if this is a good idea ... eg. when we upband a 1 band to a 2
+  band, should we duplicate the 1 band or add black?
 
 
 
-- lintra_vec next ... how should we do vips_lin() vs. vips_lin_vec()? do we
-  need two separate things?
 
-  perhaps just have vips_lin() as a convenience function
-
-  how about a "squash" param to VipsLin which clips the output type back to
-  the input type? maybe not a great idea
-
-- all things that use sizealike could take a --background param? or an
-  --extend param? maybe not a great idea (maybe handy for convolve affine etc. 
-  though)
+- note member free stuff in vipsobject docs
 
+  should boxed get freed in finalise rather than dispose?
 
 
 
@@ -91,21 +83,6 @@
 
 
 
-
-
-- change the way we wrap vips7 operations
-
-  make im_max() appear in vips8 as "im_max" (we wrap as "max" right now), this
-  will help compatibility when we redo as a class and create "max"
-
-  make vips.c try the vip8 APIs for an operation before falling back to vips7
-
-  ... actually, leave it alone, it can never work well, no point encouraging
-  its use
-
-
-
-
 - we have some serious exif problems
 
   we attach exif as both the original exif data and as a set of broken-out