Hi,

Raphaël Quinet writes:

With the release of 1.2.4-pre2, we are getting closer to the final 1.2.4. Like I did a few months ago when 1.2.3 was released, I searched Bugzilla and the various ChangeLog files in order to get a list of significant changes between the future 1.2.4 release and the previous version.

thanks, great work!

I am posting this now, just in case someone would have the foolish idea of releasing 1.2.4 while I am away during the X-Mas break... On the other hand, bug #83362 is still open and makes it illegal to distribute 1.2.4 as it is. Are there any volunteers to solve this problem?

I'd also like to see this one being addressed:

Saving .xcf on full filesystem hangs GIMP http://bugzilla.gnome.org/show_bug.cgi?id=101340

doesn't seem overly complicated since there's only one call to fwrite() in app/xcf.c which needs to have its return_value to be checked. The larger part of the problem is to propate the error up from xcf_write_int8(). Volunteers for this one?

Salut, Sven

On 18 Dec 2002, Sven Neumann wrote:

Hi,

Raphaël Quinet writes:

I'd also like to see this one being addressed:

Saving .xcf on full filesystem hangs GIMP http://bugzilla.gnome.org/show_bug.cgi?id=101340

doesn't seem overly complicated since there's only one call to fwrite() in app/xcf.c which needs to have its return_value to be checked. The larger part of the problem is to propate the error up from xcf_write_int8(). Volunteers for this one?

I'll volunteer. I've lost a lot of work to this bug.

Rockwalrus

Date: Wed, 18 Dec 2002 18:12:21 +0100 From: =?ISO-8859-1?B?UmFwaGHrbA==?= Quinet

With the release of 1.2.4-pre2, we are getting closer to the final 1.2.4. Like I did a few months ago when 1.2.3 was released, I searched Bugzilla and the various ChangeLog files in order to get a list of significant changes between the future 1.2.4 release and the previous version.

Here are the changes that I identified so far. There are many other things mentioned in the ChangeLog, but I think that these are the most significant ones. I am even thinking about deleting the last two or three items because the list is already a bit long.

* The print plug-in is now using libgimpprint-4.2, which is distributed as a separate package (bug #80941). It is more stable and more portable than previous versions (bug #87428). If you do not have libgimpprint on your system, you have to download it from http://gimp-print.sourceforge.net/ and install it before building The GIMP, else use --disable-print.

I guess this means that we (Gimp-print) should start figuring out how to factor this out of our distribution.

On another note, someone's working on a more generalized printing GUI based on the Print plugin code. This may not make it into 4.2, but if it does the result will be that there will be a libgimpprintui, and the Print plugin will shrink rather dramatically in code volume. From an operational standpoint, it would most likely share settings with any other application that used this library.

Saving .xcf on full filesystem hangs GIMP http://bugzilla.gnome.org/show_bug.cgi?id=101340

doesn't seem overly complicated since there's only one call to

fwrite()

in app/xcf.c which needs to have its return_value to be checked. The larger part of the problem is to propate the error up from xcf_write_int8().

Note that just checking write() or fwrite() return values may not be enough: some filesystems delay the error indictation until close() is called on the fd. So this bug may well be influenced by the filesystem GIMP is writing to at the time.

Just a detail to bear in mind...

Austin

Hi,

Raphaël Quinet writes:

Note that just checking write() or fwrite() return values may not be enough: some filesystems delay the error indictation until close() is called on the fd. So this bug may well be influenced by the filesystem GIMP is writing to at the time.

Yes, this is very important! Checking only the return value of fwrite() and ignoring the return value of close() is a recipe for disaster. You should also bear in mind that some filesystems (even the good old ext2) may behave differently if quotas are enabled.

please reopen the bug-report then.

Salut, Sven

On 20 Dec 2002, Sven Neumann wrote:

Hi,

Raphaël Quinet writes:

Note that just checking write() or fwrite() return values may not be enough: some filesystems delay the error indictation until close() is called on the fd. So this bug may well be influenced by the filesystem GIMP is writing to at the time.

Yes, this is very important! Checking only the return value of fwrite() and ignoring the return value of close() is a recipe for disaster. You should also bear in mind that some filesystems (even the good old ext2) may behave differently if quotas are enabled.

please reopen the bug-report then.

No need; we check fclose()'s return value in both branches now.

Rockwalrus