Graechan, are you saying that a script such as my Arrow Stroke Path doesn't work on Windows (under GIMP 2.8.14)? (For what it's worth, it works fine on GNU/LInux.)

Graechan, could you try entering the following code into the Script-fu Console and reporting the result (change the 'image' ID if necessary):

Ah yes. Have you reported a bug for that? Can you give me the bug number? I found the error.
But I have to discuss it, if it is a glib error or a gimp error.
In
app/pdb/edit-cmds.c:829
paint_options are created for this stroke.
In
app/core/gimpstrokeoptions.c:609
sets an attribute of GimpStrokeOptions and unrefs the paint_options. I do not know, if this is a good idea. I do not know, if GObject refs an attribute automatically (or only in linux, because in linux, the script does not fail?) when set or not.
If not, the reference counter is (in this case) decreased to zero.
In
app/pdb/edit-cmds.c:837
paint_options is unrefed after stroking. In this case, paint_options ref counter is already zero, so gimp crashes.

Oh yes, I think, I have it.
app/core/gimpstrokeoptions.c was changed in 02/14 and the deletion of the dereferencing of paint_options was forgotten.
(Bug 721249)

I believe you are correct; the paint_options object is getting unref'ed twice. In GNU/Linux, when run from the command line, an error is reported (see below) but the program continues.

GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed

The question is whether the object should be unref'd in edit_stroke_vectors_invoker() or in gimp_stroke_options_prepare().

It should not be unref'd in gimp_stroke_options_prepare(). The strokeoptions were changed by mitch in 02/14 and he added the unref to all places, where the paint_options are created, handed over and getting back the result. In my opinion, this is the right way.
Before these changes, paint_options were created in gimp_stroke_options_prepare() and were unref'd there.

I will reopen Bug 721249 to fix this.

Thanks Onkel Hatti for the tips! http://gimpchat.com/viewtopic.php?f=7&t=10972&start=60#p147248

For my 32 bit Vista system after replacing the files (from 2.8.11 to 2.8.14 bin folder):
libgtk-win32-2.0.0.dll
libcairo-2.dll
libpixman-1-0.dll
and adding libpng15-15.dll
no error occurred (all icons are displayed)
Script-Fu Scrolling Interface V1.1, plug-ins Python, GMIC, MathMap and even PSPI and plug-ins -sharp works well

Ps. Script-fu: Cossin En Spirale and Arrow Stroke Path - They also work fine.

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.