Hey Rod,

Ummm, I did share my compiled version. It's on my website and announced here.

Thanks,
Partha

I know and i am also grateful.
Installing on my desktop this time to see if that fixes the launch issue.

Still get an error dialog.



It seems to be using my .gimp-2.8 user folder "splashes" directory so i am thinking i need to uninstall GIMP-2.8.12 for this to work.

That error is fixed. Now. After the release. If that bug is not considered as very severe, the fixed version will be 2.8.16.

Hi Rod,

I think I already responded on the other thread. In any case, my suggestion is to first back up your .gimp folder and delete it. Then restart my build and let me know if you get any errors. If yes, send me the report I mentioned. If not, then the culprit is in your .gimp folder.

Thanks,
Partha

Hi Hatti,

I'm not sure I follow what you're saying. Just to clarify, I was referring to beta testing any compiled (Windows) binary packages released by the GIMP team, not the source code. What is occurring right now is basically the kind of Beta testing of the binary packages I'm referring to. All this could be done prior to any "Official" release of compiled binary packages by the GIMP team.

The beta testing I'm suggesting would be for Windows binaries released by the GIMP team (and possibly MAC binaries, now that they are providing those as well).

The GIMP team would not be involved in beta testing Linux binaries because Linux binaries are usually compiled and released by GIMP package maintainers for each Linux distro. In Linux, all binaries are normally beta tested via testing repos before they are actually pushed to update repos. Unless or course you roll your own (or use a rolling distro).

For example, in Fedora, GIMP 2.8.14 is still sitting in the testing repos. It's being well tested by the Fedora "testers" before being pushed to the official update repos. I was thinking that a similar paradigm could implemented for the Windows community with a "Beta" release of the compiled Windows binaries.

If the GIMP team releases "Official" Windows binaries (without testing) and they're broken, they end up with egg on their faces. There are a lot more GIMP Windows users than Linux or MAC users. Approximately 70% of the traffic on this site are Windows users, with 20% using Linux and 10% using MAC.

Thanks! I like the whole grayscale look - does not distract from your photo work.

I am concerned about "significant delay" though.

Just to test, I just used an old laptop (i5 with 6G RAM running Windows 7 Home Premium), and it was pretty spiffy if I may say so. I loaded a RAW image using UFRaw and used the paintbrush to paint on it.

Would you be able to provide some video of this?

As it turns out, none of my logo scripts use conventional stroking methods (i.e gimp-edit-stroke), so they are not affected by this issue.

Duplicate the layer, color with stroke color, select and shrink by the stroke width. That's what I usually do. Produces better results on text anyway.

Looks like the stroke bug has been fixed in the GIMP 2.8.x source.

https://bugzilla.gnome.org/show_bug.cgi?id=721249#c14

Were you able to get a clean compile? If so, you can fix it yourself by removing the offending unref in gimpstrokeoptions.c and recompile.
https://bugzilla.gnome.org/attachment.c ... ction=diff

The installer has been updated but it looks like there are still some issues..

We have released an updated 2.8.14 installer for Microsoft Windows. This one fixes the crash on window resize and the missing icons bugs - all by updating the included GTK+ library to 2.24.24.

Still unsolved are the missing spacing character in the zoom drop down and the disappearing background on high zooms (updating the Pango and Cairo libraries that are didn't change anything there), investigations continue.

Please continue to report bugs, we can't fix what we don't know about.

http://www.gimp.org/

It seems GIMP-2.8.15 no longer instantly updates the theme from Edit>Preferences>Themes. It updates on next start.

Are you guys referring to GIMP 2.8.14? The GIMP team is referring to this release as 2.8.14.

Only Samj is calling her packaged release V2.8.15.

This seems confusing to me. Shouldn't odd numbers refer to development versions and even numbers refer to stable releases? When there are maintenance releases or revisions to the stable version, shouldn't there just be another number added?

In GIMP 2.8.10, there several maintenance updates. In Fedora, new compiles/revisions are denoted as GIMP 2.8.10-1, 2.8.10-2 and so on. It seems to me this paradigm makes sense and helps keep track of exactly which version you have.


You have confirmed that the missing characters in the size dropdown is also related to the theme in 2.8.14? That is good to know.

Has anyone been able to duplicate the missing background problem on high zooms? There are screenshots of the problem in this bug report.

If I have understood it comes to the zoom button The interchange of libraries libpango-1.0-0.dll and libpangowin32-1.0-0.dll solves the problem.

That means, as i said before, that Samj compiled after the creating of the release.
So, in fact, it is a package made from the development Version.
The GIMP Team did not make a new release. They just made another package with other third party libraries.
If they made a new release, its name would be 2.8.16.



Yes. open an Image, add transparency and zoom it to grotesque 4000%. The transparency vanishes.

Hatti