Hi all,

It's been a while since the last mail about the blockers for the 2.0 prereleases, so here it is.

Bug # Summary

78064 Entering large dimensions in Scale Image causes fatal error
113033 Thumbnail PDB API for Plug-Ins 125115 Gimp will not work with GTK 2.4 125141 Deprecate libgimpmisc
125142 Make libgimp 64 bit clean
125144 Text transforms
58507 Translators should mentioned somewhere (maybe in help->about like in nautilus) 66367 Improved animoptimize for RLE or LZW compression 116606 gradients not saved until quit 118547 Convert Text Layer To Pixels / Render Text Layer 122707 Text: can't make smaller boundary size of block

That's 11, as opposed to 11 the last time. Many of the bugs are in the same state as a couple of weeks ago.

There is one new blocker (build with GTK 2.4) which has been mostly addressed, and I think that it can be moved off the 1.3.x milestone.

Aside from that, I am working on 116606 (gradients not saved until quit) - there is now a workaround, and I hope to have a complete fix in place soon (perhaps today?).

125142 (64 bit clean) is mostly done, awaiting one final commit from yosh to close it. Part of this bug was the API for gimp_dialog_new() which has been changed recently by mitch.

Simon is still working on the About dialog, and he has asked for input and ideas. They should be added to bug #58507.

Bug #78064 (crash on scale image) is currently not being looked at by anyone. Please speak up.

David Odin has been doing some work on getting rid of libgimpmisc and libgimpmiscui from the installed libgimp API, but he is looking for some help, I think. Add a comment to bug #125141.

Raphael was working on bug #66367 (RLE animoptimize) last time, and I believe that's still the case.

That leaves 5 bugs:

113033 Thumbnail PDB API for Plug-Ins

Sven had almost finished this last I heard.

125144 Text transforms

This bug has a comment from Sven which outlines what needs to be done to close this request. Perhaps someone with some time on their hands could do this?

122707 Text: can't make smaller boundary size of block

I'm not sure of the current status of this. Last I heard the back-end was more or less done, and it needed an UI. I suggest buimping the milestone, since I don't think this is essential for a usable text tool.

118547 Convert Text Layer To Pixels / Render Text Layer

This is on the TODO list of Sven, I think.

OK - so there's the summary. Not a huge amount of movement on these, but we're going in the right direction.

Cheers, Dave.

Hi,

David Neary writes:

OK - so there's the summary. Not a huge amount of movement on these, but we're going in the right direction.

Dave, please do a CVS diff between the date of your last mail and today. Then say this again. Actually we have made a lot of progress, not only on the blockers but also on other bugs that need to be addressed before 2.0. We could hardly have moved faster.

Sven

Sven Neumann (sven@gimp.org) wrote:

David Neary writes:

OK - so there's the summary. Not a huge amount of movement on these, but we're going in the right direction.

Dave, please do a CVS diff between the date of your last mail and today. Then say this again. Actually we have made a lot of progress, not only on the blockers but also on other bugs that need to be addressed before 2.0. We could hardly have moved faster.

Sven, please look closely what Bolsh wrote: "Not a huge amount of movement on these", so he is just referring to the list of prerelease blockers listed above. And - until I missed something - I share his opinion, that our progress towards a first prerelease is much slower than a progress to 2.0. Hmm. Sounds odd ;-)

Bye, Simon

Hi,

Sven Neumann wrote:

David Neary writes:

OK - so there's the summary. Not a huge amount of movement on these, but we're going in the right direction.

Dave, please do a CVS diff between the date of your last mail and today. Then say this again. Actually we have made a lot of progress, not only on the blockers but also on other bugs that need to be addressed before 2.0. We could hardly have moved faster.

I am well aware of everything that has gone into CVS in the past 2 weeks. I specifically said "on these". By that I meant that the same bugs which were blockers for the pre-releases 2 weeks ago are still blockers now, with the exception of the GimpDialog API (which I mentioned in the mail). I also summarised the changes that have been made with respect to the various blockers that are still open.

Yet again, I didn't mean to offend. If there was a point to be made, it is that the proportion of the check-ins which have been directly related to bugs which are blockers for a pre-release is pretty small when compared to the sum total of what's gone in in the last couple of weeks.

So, in summary, of the 11 bugs which were on the 1.3.x milestone a fortnight ago, 10 remain open, and 1 more was added.

Cheers, Dave.

Hi,

all well understood but progress reports should be motivating. So it's important to also mentioned all the good things that have happened. Otherwise the report will have the opposite effect of what it was written for.

Sven

Hi,

Sven Neumann wrote:

all well understood but progress reports should be motivating. So it's important to also mentioned all the good things that have happened. Otherwise the report will have the opposite effect of what it was written for.

Apologies if the tone seemed a little negative. I will try to avoid that in future.

Dave.

Hi,

David Neary writes:

Apologies if the tone seemed a little negative.

There's no need to apologize, no offense was taken.

Let me then try to come up with a summary of all the things that happened, not mentioning the changes that didn't yet happen:

- GIMP can now be used w/o any fonts. Well, of course you need fonts for the user interface but you could use X or Win32 core fonts for the user interface and GIMP will start even if your fontconfig setup is empty. If it is broken, you can workaround this by specifying --no-fonts on the gimp-1.3 command-line. Of course the text tool is unusable then.

- We now support loading of GIMP brush format version 3. That is the format that was introduced by the FilmGimp or CinePaint developers (I don't know exactly when this change was made). I didn't find any brushes in this format that make use of the higher color precision that it allows for. So it probably doesn't matter at all that we convert the brush data to 8bit integers on load. If you google for GIMP brushes, you will find a nice set of charcoal brushes that can now be used directly by The GIMP.

- Mitch redid the GimpDialog API. The new API is a lot simpler and very similar to GtkDialog. This is an incompatible API change but we did not want to release 2.0 with the messy old GimpDialog API. The new API simplifies some plug-in user interface code quite a bit.

- Simon added the possibility to merge paths, similar to the "Merge Visible Layers" functionality. Simon is also working on the new About dialog and what he has so far really looks sweet.

- Mitch and me fixed more multi-head issues and GIMP should now work correctly on multi-head setups (not talking about Xinerama here!). There's even a way to move image and dock windows to different screens (on the same display). What is missing here is to make the session-management code aware of screens.

- We replaced the old WMF plug-in by a new version that uses libwmf2. The new plug-in was written by Dom Lachowicz and Francis James Franklin and used to live in the libwmf CVS tree until now.

- Dov Grobfeld contributed a plug-in for reading and writing the DICOM file format which is a standard file format for medical images.

- I've added a small abstraction layer that encapsulates the use of GDK graphics contexts when drawing on the display canvas. This reduces the number of GCs we use and allowed to fix multi-head issues and some redraw problems with XOR drawing.

- The plug-ins and the core finally use the same color selector. Mitch added the missing bits to make the color selector from libgimpwidgets load the same color selector modules that the core uses. This has been a very long-standing issue that is finally fixed now.

- Mitch added a user interface to change GIMP themes from the Preferences dialog. Finally the nice "Small" theme is available even to users that don't care to read any docs ;)

- Dave implemented the missing save functionality in GimpDataEditor.

Quite a few bugs were fixed and code was further cleaned up and documented. We are getting into shape for the 2.0 prerelease...

Sven

PS: If I missed something, please feel free to correct me.

Sven,

- We now support loading of GIMP brush format version 3. That is the format that was introduced by the FilmGimp or CinePaint developers (I don't know exactly when this change was made).

CinePaint has made no changes to GIMP file formats. Those modifications predate our involvement, came from the GIMP HOLLYWOOD branch CVS in 2002 used to create Film Gimp 0.1. You should be able to figure out who extended/broke your file formats by researching your own CVS changelogs.

Cheers,

Robin --------------------------------------------------------------------------- Robin.Rowe@MovieEditor.com Hollywood, California www.CinePaint.org Free motion picture and still image editing software

Hi,

"Robin Rowe" writes:

- We now support loading of GIMP brush format version 3. That is the format that was introduced by the FilmGimp or CinePaint developers (I don't know exactly when this change was made).

CinePaint has made no changes to GIMP file formats. Those modifications predate our involvement, came from the GIMP HOLLYWOOD branch CVS in 2002 used to create Film Gimp 0.1. You should be able to figure out who extended/broke your file formats by researching your own CVS changelogs.

Didn't I say just that? I don't really care when the change was made and who made it. I also don't believe that anyone else cares. It has happened. Period. Now calm down, please.

Sven

Hi,

a week has gone by since the last progress report so it's about time for a short update on what has changed in GIMP CVS.

- Yosh added new functions to libgimpwidgets that provide a 64bit clean interface for option menus and radio groups. This fixes bug #125142.

- A couple of other issues with the libgimp* APIs have been resolved. The APIs should be ready for GIMP-2.0 now. Only the addition of libgimpthumb is still missing in CVS.

- Mitch went over the core and all plug-ins and unified user-visible strings, focusing on error messages. This reduces the work for translators. Also lots of newlines have been removed from these strings. We let the message dialog do the line breaks now.

- Session management now handles multiples screen. If you move a dock away from the default screen, GIMP will remember this in your sessionrc and will try to reopen it there the next time. Finally you can seriously work with two or more screens.

- The image window and popup windows such as menus now position and size itself by looking at the geometry of the current monitor instead of using the screen size. This makes GIMP behave a lot better on Xinerama setups where one screen goes over multiple monitors.

- The small theme I talked about in my last report has landed in CVS.

- Some work has been done on cleaning up the application lifecycle. The idea is that it should be possible to initialize GIMP, use it for a while, then release all resources and start all over again. This is somewhat academic but it already helped to find some possible problems. You might notice that quitting GIMP takes a little longer now. This is because we actually release all resources instead of simply calling exit(). We might add back the call to exit() for the 2.0 release.

- Mitch changed how GtkFileSelector is being used. This is in preparation of a migration to the new GtkFileChooser widget from GTK+ HEAD. The idea is to provide a patch for GIMP that makes it use the new widget so that problems with the new API can be identified early and fixed before the GTK+ API is frozen for 2.4.

- Hans fixed some Win32 problems and updated the MSC makefiles.

- Some more progress has been made on documenting the GIMP libraries and the application itself.

Quite a few bugs have been fixed. Bugzilla talks about 24 bugs closed during the last week, 17 of these were resolved by actually fixing the code. The other 7 were duplicate or invalid reports.

Sven

Sven Neumann (sven@gimp.org) wrote:

- A couple of other issues with the libgimp* APIs have been resolved. The APIs should be ready for GIMP-2.0 now. Only the addition of libgimpthumb is still missing in CVS.

With the notable exception of vectors stuff. Or did I miss something?

Bye, Simon

Hi,

Simon Budig writes:

Sven Neumann (sven@gimp.org) wrote:

- A couple of other issues with the libgimp* APIs have been resolved. The APIs should be ready for GIMP-2.0 now. Only the addition of libgimpthumb is still missing in CVS.

With the notable exception of vectors stuff. Or did I miss something?

I forgot to mention that it would be nice to add PDB APIs for text and vectors. These would of course be wrapped in libgimp so perhaps the API isn't finished yet. But these would be additions and thus not break any plug-ins.

What I was refering to here mainly is that plug-in authors shouldn't expect more majpr API changes. Mitch mentioned today that he'd like to change the GimpFileSelection API. I understand the need for this and since only few plug-ins use it, it wouldn't break many. The plan is however to not do anymore changes (despite perhaps additions) to the libgimp* APIs after the next development release which is scheduled for this weekend.

Sven

Simon Budig wrote:

Sven Neumann (sven@gimp.org) wrote:

- A couple of other issues with the libgimp* APIs have been resolved. The APIs should be ready for GIMP-2.0 now. Only the addition of libgimpthumb is still missing in CVS.

With the notable exception of vectors stuff. Or did I miss something?

Whatr changes to the vector tool will require libgimp API changes before 2.0? I wasn't aware of any...

Cheers, Dave.

David Neary (bolsh@gimp.org) wrote:

Simon Budig wrote:

Sven Neumann (sven@gimp.org) wrote:

- A couple of other issues with the libgimp* APIs have been resolved. The APIs should be ready for GIMP-2.0 now. Only the addition of libgimpthumb is still missing in CVS.

With the notable exception of vectors stuff. Or did I miss something?

Whatr changes to the vector tool will require libgimp API changes before 2.0? I wasn't aware of any...

It is not the *Tool* itself, it is the vectors infrastructure.

The Problem is, that the new vectors infrastructure provides more functionality than the old stuff. The compatibility API works with the new infrastructure, but is limited to the old functionality, in particular you cannot create a vectors object with multiple open strokes in it (Look at gimp-path-set-points: BEZIER_MOVE not only moves to a new location, but also closes the previous segment).

So we need a new API that makes it possible to create that kind of vectors via PDB. Since we internally already have functions like bezier_stroke_new_moveto, bezier_stroke_curveto, bezier_stroke_arcto, etc. it would be nice to have them available for plugins too, since they make creation of bezier strokes really easy.

I think I failed to communicate that properly, but I always considered this to be part of the new vector stuff - and this is the IMHO last part that is missing. I am scared a bit, because I have no real idea how that PDB stuff works.

I hope this makes it clear what is wrong there.

Oh, I forgot:

Functionality-wise also missing is a GUI for the dashed strokes, but a) it is probably fairly easy and b) we might be able to live without it...

I think I should describe what I have in mind for the UI, if someone wants to pick that up I'd be very happy about that.

The description of a dashed stroke is an array of doubles: length stroke, length gap, length stroke, length gap, etc.

the unit of these floats is the width of the stroke, this has the nice property, that it is scaling independant.

The Widget to define this could look like this:

[==== =========== == ===== ]

and you can paint with the mouse into it - either simply flip the pixels between black and white where the mouse gets dragged over, or stick to black/white painting when clicking on a white/black pixel.

The widget should be able to provide the doubles mentioned above, maybe we need to two additional value-entries for overall dash-pattern length and the dash-offset at the beginning of the stroke.

Any takers?

Bye, Simon