Mat Caughron writes:
> NOT to fork the project but to make it more available. It seems the only > way to see the current windows-gimp 1.2.4 source is to download the zip > file from: www.gimp.org/win32/downloads-20030104.html > Even if you want to look up a particular file, you have to download and > unzip the whole thing.

I probably should put up a diffs file in addition to my source snapshot. (Earlier I did, but then I got complaints that just providing diffs isn't GPL compliant...) They aren't that many diffs, and much of the difference is not really relevant unless you want exactly the same random number generator behaviour as in my prebuilt binaries, for instance. Or exactly the same (incomplete) handling of non-ASCII file names. Much of the non-committed changes is ugly hacks.

--tml

On 27 Jan 2003, at 18:54, Tor Lillqvist wrote:

Mat Caughron writes:

NOT to fork the project but to make it more available. It seems

the only > way to see the current windows-gimp 1.2.4 source is to download the zip > file from:
www.gimp.org/win32/downloads-20030104.html > Even if you want to look up a particular file, you have to download and > unzip the whole thing.

I probably should put up a diffs file in addition to my source snapshot. (Earlier I did, but then I got complaints that just providing diffs isn't GPL compliant...) They aren't that many diffs, and much of the difference is not really relevant unless you want exactly the same random number generator behaviour as in my prebuilt binaries, for instance. Or exactly the same (incomplete) handling of non-ASCII file names. Much of the non-committed changes is ugly hacks.

Is not all your code in the GIMP CVS repository? If so, why not? As Sven pointed it, it is fairly easy to surf through CVS using its web interface.

Branko Collin writes:
> Is not all your code in the GIMP CVS repository? If so, why not?

I have told this several times, most recently earlier today:

I have local changes I haven't committed to the (real) GIMP CVS, true. [...] As soon as 1.2.4 has been officially released I'll try to see how many of my local changes I can integrate cleanly into the official sources and commit to CVS, but I don't want to do that until after 1.2.4 has been released. I'm afraid of breaking stuff and delaying the release even further.

My non-committed changes fall into these categories:

- Minor Makefile.am hacks

- Random number generator changes in the plug-ins, to fix #67386.

- System charset to/from UTF-8 conversions as GTK+ 1.3.0 on Windows uses UTF-8, to make non-ASCII file and directory names cause less pain.

- Enable plug-in init functions.

--tml

On 28 Jan 2003, at 1:15, Tor Lillqvist wrote:

Branko Collin writes:

Is not all your code in the GIMP CVS repository? If so, why not?

I have told this several times, most recently earlier today:

I have local changes I haven't committed to the (real) GIMP CVS, true. [...] As soon as 1.2.4 has been officially released I'll try to see how many of my local changes I can integrate cleanly into the official sources and commit to CVS, but I don't want to do that until after 1.2.4 has been released. I'm afraid of breaking stuff and delaying the release even further.

My non-committed changes fall into these categories:

- Minor Makefile.am hacks

- Random number generator changes in the plug-ins, to fix #67386.

- System charset to/from UTF-8 conversions as GTK+ 1.3.0 on Windows uses UTF-8, to make non-ASCII file and directory names cause less pain.

- Enable plug-in init functions.

Yes, I read that, but I took those to be minor changes, that you had yet to commit.

On Tue, 28 Jan 2003 01:15:07 +0000, Tor Lillqvist wrote:

Branko Collin writes:
> Is not all your code in the GIMP CVS repository? If so, why not?

I have told this several times, most recently earlier today:

I have local changes I haven't committed to the (real) GIMP CVS, true. [...] As soon as 1.2.4 has been officially released I'll try to see how many of my local changes I can integrate cleanly into the official sources and commit to CVS, but I don't want to do that until after 1.2.4 has been released. I'm afraid of breaking stuff and delaying the release even further.

From my point of view, I think that it would be better to integrate

these changes before the 1.2.4 release. This would allow the 1.2.4 release to be the same on all platforms. Otherwise, we would have to have a new release for all platforms (1.2.5) once your changes are merged into the common codebase. I would prefer to avoid that, so that 1.2.4 can be the last stable release on the 1.2.x branch (famous last words - of course there will still be some bugs). It would be nice if everybody could focus on the 1.3.x development once 1.2.4 is relased. Disclaimer: this is only my personal opinion.

-Raphaël

Raphaël Quinet writes:
> From my point of view, I think that it would be better to integrate > these changes before the 1.2.4 release.

It's just that maybe half of the changes are really quite ugly hacks to get non-ASCII file and directory names working somewhat better on Windows, where GTK+ 1.3.0 uses UTF-8. Example:

status != PDB_CANCEL) {
+#ifdef GDK_USE_UTF8_MBS
+ gchar *utf8_filename = g_filename_to_utf8 (filename, -1, NULL, NULL, NULL); + g_message (_("Save failed.\n%s"), utf8_filename); + g_free (utf8_filename);
+#else
g_message (_("Save failed.\n%s"), filename); +#endif
}

The random number generator changes aren't that ugly, but still, might conceivably be considered API changes as they might well cause for instance a plug-in to use rand48() instead of a previously hardcoded rand() on some Unix variant. (The plug-ins in my version all use RAND_FUNC, SRAND_FUNC and G_MAXRAND, while previously some hardcoded rand() and whatnot.) This will cause different results from some identical script-fu script invokation. Example:

-#define RANDOM ((gdouble) ((gdouble) rand ()/((gdouble) G_MAXRAND))) +#define RANDOM ((gdouble) ((gdouble) RAND_FUNC ()/((gdouble) G_MAXRAND)))

- srand (VALS.seed); + SRAND_FUNC (VALS.seed);

I don't know. I agree that it would be nice to have a common 1.2.4 release, but OTOH, the UTF-8 conversion stuff is really just hacks to cope with my (in hindsight) misguided decision to use UTF-8 already in GTK+ 1.3.0 on Windows.

> It would be nice if everybody could focus on the 1.3.x development > once 1.2.4 is relased.

Agree. My personal opinion is not to merge those changes in and get on with getting 1.2.4 released. The changes don't affect core GIMP functionality anyway, so we can IMHO still say that GIMP 1.2.4 uses the same codebase on Unix and Windows. If the changes aren't merged in, and somebody builds GIMP on Windows from official sources, they will notice difference in behaviour compared to "my" build only in the handling of non-ASCII filenames, and in some random number generator dependent plug-ins.

A fresh "cvs diff -u2" of my GIMP directory is at www.iki.fi/tml/gimp.my-diffs

--tml

On Tue, 28 Jan 2003 16:38:28 +0000, Tor Lillqvist wrote:

Raphaël Quinet writes:
> From my point of view, I think that it would be better to integrate > these changes before the 1.2.4 release.

It's just that maybe half of the changes are really quite ugly hacks to get non-ASCII file and directory names working somewhat better on Windows, where GTK+ 1.3.0 uses UTF-8. Example: [...]

Hmmm... Sure, this is not very clean. On the other hand, there are a couple of quick workarounds that have been introduced in the 1.2.x branch while the proper solutions have only been implemented in the 1.3.x branch. IIRC, there is at least one piece of code in the 1.2.x branch that contains a comment stating that the following code is a temporary hack that is fixed in the 1.3.x branch only.

So I think that some #ifdef's are acceptable in the maintenance branch because this is only a temporary solution for a problem that has been solved differently in the main branch. But I would like to hear the opinions of Yosh, Sven or Mitch about this.

The random number generator changes aren't that ugly, but still, might conceivably be considered API changes as they might well cause for instance a plug-in to use rand48() instead of a previously hardcoded rand() on some Unix variant. (The plug-ins in my version all use RAND_FUNC, SRAND_FUNC and G_MAXRAND, while previously some hardcoded rand() and whatnot.) This will cause different results from some identical script-fu script invokation. [...]

I could also take the opposite point of view and say that the current GIMP is broken because invoking the same script on different platforms gives different results, even if the script is started with the same random seed. If I publish a tutorial explaining how to get a nice effect by using some plug-ins, then some users will get a different result from what was intented. And these differences occur not only between the Windows version and some UNIX versions, but also between several UNIX variants.

I know that this issue has been discussed in bug #67386 and Sven's opinion was that we should not get different results in the stable branch (different from one version to the next). But we already get different results if we use the GIMP on different platforms...

Anyway, there are pros and cons for applying or not applying the changes to the random number generator. Regarding the UTF-8 hacks, I think that it would be nice to have them in the common codebase. But again, I would like to hear the opinions of other developers first.

-Raphaël

Tor, sf.net wont remove the wingimp project until you, or any other qualified gimp developer tells them to. The project is already breaking atleast one rule, the one about only developers for a project can start a sf.net project about the said project. Please take care of this before it gets out of hand.

Go here and fill a support request: https://sourceforge.net/tracker/?func=add&group_id=1&atid=200001

Sven Neumann writes:
> IMO Tor should commit his filename-conversion hacks.

OK.

> It should be possible to get the changes needed on Win32 into the code > to the 1.2 code by adding some more ifdefs. At least I hope so since > I'd like to have all of Tor's changes in CVS.

OK, I'll merge them in then, with ifdefs as appropriate not to affect behaviour on Unix. I'll probably have time to do it next weekend. Or should I wait until 1.2.4 has been released?

--tml

Patrick McFarland writes:
> Go here and fill a support request: https://sourceforge.net/tracker/?func=add&group_id=1&atid=200001

OK, I did that.

--tml

Sven Neumann writes:
> IMO Tor should commit his filename-conversion hacks.

I wrote: > OK, I'll merge them in then, with ifdefs as appropriate not to affect > behaviour on Unix. I'll probably have time to do it next weekend.

It took some time before I could do it, but now I have merged in those hacks. I also merged in the #67386 fixes for Win32. For both sets of changes, the code for non-Windows should be unchanged.

I still have uncommitted the plug-in initialisation code from #66859. Will merge that in a couple of days.

--tml