Re: gdk_pixbuf::xpm_image_save patch

[Hans Breuer <hans breuer org>]

At 17:39 29.10.00 -0500, Owen Taylor wrote:
>
>Hans Breuer <hans breuer org> writes:
>
>> ... 
>> What about wrapping it with G_OS_WIN32 ?
>
>Definitely not - there is no reason it should be win32 specific,
>and our goal should be to reduce inter-platform dependencies
>as much as possible.
> 
Ok, agreed.

>> Btw: could you comment on the other things the patch was adressing?
>
> - The module prototypes changes are fine.
>
> - As far as mkstemp goes, I think the strategy I discussed with
>   Tor was to add a g_mkstemp function in glib.
>
Maybe I'll adress this in my next Glib patch.
 
> - The HAVE_UNISTD conditional and the inclusion of io.h look  
>   OK, though it might be nice to identify what unistd.h
>   was being included for as a comment next to it so we can
>   see why it doesn't need to be included everywhere.
>
Will do.

> - The file open mode changes are probably OK; fopen (..., "rb")
>   is standard ANSI unlike the horror of O_BINARY.
>
>I think that was all the other changes - if you make a patch
>with just those and not the saving patch, it might be useful.
> 
Yeah. If you wouldn't mind I could even commit these changes to cvs myself.
I've got an account - mainly for my win32 Dia port. (It would be my first
direct Gtk+ commit, but there are already some patches from me in the Win32
part.
And I'm trying to make recent Gtk+ working again on Win32, which simply
requires to build gdk-pixbuf first.

>The GIMP's XPM plugin does handle saving. It does have the same
>problem as mentioned above, but it at least gives the person
>some more flexibility in using it.
>
>So this should be a good option on win32. I'm pretty certain
>that some of the other image manipulation suites such as
>netpbm have been ported to Win32 or at least to djgpp

although I wouldn't have netpbm called an "image manipulation suite" :-)

>or cygwin, though using command line utilities without
>a real shell isn't that much fun.
>
Totally agreed.

>The goal of adding saving to gdk-pixbuf is not to give it enough
>capabilities of something like the GIMP, but rather to allow
>programs that need to incidentally save an image or two to
>do so simply.
>
although IHMO the much cleaner way to generalize would be in the library.
Instead of just another implementation of application specific XPM code ...

>I don't think the XPM format is really suitable for this
>sort of black-box, forget-about-the-details saving.
>
Ok. Forget about the gdk_pixbuf::xpm_image_save.

>> But aren't XPMs used as general image resource format in every *ix program.
>> Do you think this would be replaced by inline PNGs in the near future?
>
>In GTK+-2.0, we have a special inline-rgb format and a utility
>for creating these files; this probably will be the standard
>for small images. (It isn't especially space-efficient, but
>better than XPM and allows storing the image data in the 
>read-only/shared storage)
>
Do you really think all the Gtk users will convert their XPMs to inlined PNGs?
(Which forces just another tool dependency.)

Are there plans to drop the XPM support in Gdk ?

Thanks again for the even faster response,

	Hans

-------- Hans "at" Breuer "dot" Org -----------
Tell me what you need, and I'll tell you how to 
get along without it.                -- Dilbert