Re: gdk_pixbuf::xpm_image_save patch

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
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 "at" Breuer "dot" Org -----------
Tell me what you need, and I'll tell you how to 
get along without it.                -- Dilbert

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]