On Sat, 9 Aug 2003, Dave Neary wrote:

Date: Sat, 9 Aug 2003 20:36:10 +0200 From: Dave Neary
To: gimp-user@lists.xcf.berkeley.edu Cc: gimp-developer@lists.xcf.berkeley.edu Subject: [Gimp-developer] Third big serious meeting from GIMPcon

Hi all,

Here are the minutes of the meeting we had this afternoon, written up by Raphael.

I want to say a big thank you to Dave, Raphael and anyone else who took the effort to record the proceeding for those of us who cannot be there. Keep up the good work.

I expect these notes from Gimp Con will be similarly useful as a review for those of you who did make it.

Hopefully someone will post links to these on the news page, and gnomedesktop.org when the talks are all finished.

Sincerely.

Alan Horkan http://advogato.org/person/AlanHorkan/

Good to get some high-quality feedback.

On Sat, 9 Aug 2003, Leonard Rosenthol wrote:

At 6:01 PM -0700 8/8/03, Nathan Carl Summers wrote:

Let us start with an existing graphics format, for inspiration if nothing else.

OK.

The format I chose is PNG, because it is arguably the best existing lossless portable graphics format available.

Well, I would argue that TIFF has the "crown"...

However, PNG is an excellent standard, regardless.

Good point. It can't hurt to take a look at several graphics formats and take the best parts from each of them.

4 capable of representing trees and graphs

Trees, yes - for things like layers. But why a graph??

GEGL supports graphs. If we use GEGL graphs, we'll need a representation ;)

5 recoverable from corruption
6 fast random access of data
9 fast loads and saves
10 compact

Good goals, but not a requirements. Perhaps you should separate those two things out...

I see fast loads as an absolute requirement. Being compact is nice as well, because not everyone has 3 terrabyte harddrives and a T3 line into their house.

Hopefully, GIMP's file handling will improve to the point where it will load thing on an as-needed basis. Therefore, fast random access is necessary. A VIPS-like demand-driven pipeline would increase gimp responsiveness a lot.

And I can think of other goals that I'd like to see:

* incremental update just update a single layer w/o rewriting the whole file!

This seems like an excellent goal. It seems like you are suggesting a database-like format.

* rich metadata
(this may be your 7, but needs to be spelled out)

Well, that was what I meant by extensibility and the ablity to represent anything GIMP can. I agree that this is important.

PNG certainly supports 1,2,6,7,9,10, and 11. Let us examine the other issues in more detail.

I would argue that PNG doesn't do 7 - it has no native support for CMYK, for example. (but yes, it does RGB, Gray and indexed).

And for comparison, I would offer that TIFF does the same list and REALLY does 7, including CMYK, Lab, ICC and Spot color spaces. It's extensibility is similar to PNG (in fact, PNG's chunks were modelled on TIFF chunks).

Indeed.

A pure XML format, by way of comparison, would fulfill requirements 1,2,3,4,7, and 8.

I'd add 9, just being in XML doesn't mean it can't be fast.

I guess if you used raw image data instead of base64 or something similar

Requirement 5 in practice would be difficult to fulfill in a pure XML format without hand-hacking, which is beyound the skills of most users. A zlib-style compression step could make some progress towards 10.

But gzipping the entire XML block would then pretty make 6 impossible unless you want to seriously increase in-memory requirements.

right.

An archive with XML metadata and png graphical data, on the other hand, would satisfy requirements 1,2,3,4,7,8, and 11.

An archive (zip, tar, ar) with XML metadata plus raster image data (ie. my previous proposal) would meet 1,2,3,4,6,7,8,10,11. 5 & 10 are related to the archive format of choice since some are better at these than others. But yes, I suspect that it would probably be a bit slower.

Requirement 6 is
fulfilled for simple images, but for more complex images XML does not scale well, since every bite from the begining of the XML file to the place in which the data you are interested in is.

But the XML is just a "catalog" of what's in the archive (at least in my proposal). So you read the catalog up front and then use it to quickly find the part of the archive you want and viola - fast random access to data.

It seems like all we have to do is combine the strengths of PNG and the strengths of XML to create a format that satisfies our requirements. What we really need is not an extensible text markup language, but an extensible graphics markup format.

That's what TIFF and PNG were designed for.

Portable XCF would use a chunk system similar to PNG, with two major differences. First, chunk type would be a string instead of a 32-bit value. Second, chunks can contain an arbitrary number of subchunks, which of course can contain subchunks themselves.

I think sub-chunks is a bad idea. Although a common way to represent hierarchical relationship, they can also put overhead on random access and also slow down read/write under certain conditions.

How about a TIFF-like directory chunk at the beginning (except hierarchical)?

At the end of each chunk is a checksum, as well as a close-chunk marker. The purpose of the close-chunk marker is to help recover in case of corruption; if no corruption is detected, the close-chunk marker is ignored.

This is a common technique in many file formats for corruption detection. It works.

One of the major advantages of this hybred technique is that if an implementation does not understand or is not interested in a particular chunk, it can seek to the next chunk without having to read or parse any of the data in-between.

How does it do that? How do you find "start of chunk" without a catalog? How do you get random access to a particular chunk w/o a catalog?

It traverses the file in a linked-list style. But you are right that a directory block would be even faster.

image data chunks should use png-style adaptive predictive compression. They should also use adam-7.

Great - but that's not specific to a file format - we can do that anywhere...

Indeed we can.

Rockwalrus

Like in any Free Software project, developers are leaving from time to time to pursue other projects. And from time to time, new developers are joining the team and starting to contribute. However, it looks like the number of new developers joining the GIMP development has been decreasing in the recent years.

Probably one of the main reasons is that Gimp isn't the only major open-source end-user app anymore.

But yes, I would not be surprised if Gimp was percieved as stagnating.

There should be a section on www.gimp.org or developer.gimp.org titled "How to contribute?" or "How to get involved?". It should be easy for potential new developers to see where to start and how they can help.

Absolutely. We need to make it as easy as possible.

It would be very nice to have Windows binaries for the development version.

I would say that Mac users and Windows users are much more likely to expect and use binaries.

Is Bugzilla too hard to use for new users? ------------------------------------------

It was suggested to make it easier for users to submit bug reports, for example by having an e-mail address to which bug reports can be sent without having to register to Bugzilla (we already have such an address, although it is not widely known).

Personally, I'd like to see Bugzilla be the only place for gimp bugs.

This proposal was rejected because most of the bug reports (especially from new users) are incomplete and require additional information. If the user does not have a Bugzilla account, it is not possible to rely on the automatic notification system to send messages to the user when a comment is added to their bug report or when the status of their bug report changes.

Agreed.

Most developers consider Bugzilla to be a very valuable tool that works well. Instead of trying to hide Bugzilla from the users, we should try to make it as easy as possible for the new users to join. This is already done to some extent by the bug submission wizard available from http://bugs.gimp.org/. There is a small problem with the GNOME2 keyword that prevents the open GIMP bugs from being displayed to the user and we should try to get this fixed.

A good wizard would go a long way towards making first-time Bugzilla submission not so overwhelming.

List of open tasks
------------------

There are many open bug reports or proposals for enhancements that would be relatively easy to fix or implement. We should make it easier for potential contributors to see the list of easy tasks that are open. The "easy tasks" should include anything that can be done in one or two hours by an average developer or maybe a bit more if the contributor is not familiar with the code.

The best way to keep the list of open tasks up-to-date is probably to base it on Bugzilla. We could for example use a Bugzilla keyword for all bugs that are easy to fix (there is already a keyword "easy-fix" reserved for that, although we could invent our own). It would then be easy to create a Bugzilla query showing the list of easy tasks.

I think that this is the best solution. I have already marked some easy bugs with the easy-fix keyword.

Another solution would be to have a page on www.gimp.org or developer.g.o containing a list of all these bugs, with direct links to the corresponding bug reports. The second solution may require a bit more work because it would have to be maintained by someone, but it might be a bit easier to use.

I doubt there would be much advantage to doing this.

The following items should be available in the web site: - "How to contribute?" / "Getting involved" - List of tasks

I propose that other outstanding tasks, like things that we would like to see in the next version, be available as Bugzilla query links. When necessary, we can add keywords or tracking bugs.

- List of sources of contains some useful items such as "Bugs", "FAQ", etc. information (mailing lists, newsgroup, ...) - FAQ

As with the other documents summarizing what is happening here at GimpCon, comments are welcome...

On 9 Aug 2003 at 18:35, Leonard Rosenthol wrote:

At 8:36 PM +0200 8/9/03, Dave Neary wrote:

Another reason may be that it is difficult to build the development version because it depends on released versions of some libraries that are not included yet in the major GNU/Linux distributions (e.g., GTK+ version 2.2.2). Also, the number of dependencies for GIMP 1.3.x is much higher than the number of dependencies for GIMP 1.2.x, so it is more difficult to have a working build environment for the 1.3.x version. This problem may be solved as time passes, because more and more distributions will include the required libraries.

I think the related reason here is that many open source projects get their contributors from non-Linux platforms, esp. Windows. And building GIMP/Windows is even more of a nightmare than building GIMP on Linux.

Well, building GIMP/Windows so that GIMP can be run isn't that complicated - building it right so it can be "make install"ed is.

Building with Cygwin seems to be rather easy once you've got recent versions of all required libraries and tools.

Building with MinGW is a bit more complicated - the packages of libiconv and libintl that are linked from http://www.gimp.org/~tml/gimp/win32/downloads.html don't include import libriaries to be used with libtool. All my tries to create them with pexports and dlltool didn't produce working libs.

Maybe one of the GIMP>K/Win32 gods can enlighten a mere mortal on the modifications that need to be done to build GIMP with MinGW?

Michael

Michael Schumacher writes:
> Building with MinGW is a bit more complicated - the packages of > libiconv and libintl that are linked from > http://www.gimp.org/~tml/gimp/win32/downloads.html don't include > import libriaries to be used with libtool. All my tries to create > them with pexports and dlltool didn't produce working libs.

(Note to those who don't know: Perhaps a bit surprisingly, Win32 binaries for libiconv and gettext are distributed from FSF's ftp site. Even more surprising, they are build with MSVC, and only MS format import libraries are supplied.)

Umm, sorry, I don't remember how I produced import libraries for those... Hmm, I do write on the downloads page that I used pexports and dlltool, so presumably I did, but I don't remember the details. Anyway, libiconv and libintl both export just a handful of functions, so just extract the list of exported functions with objdump or whatever, edit it into a .def file, and produce the import library with dlltool?

> Maybe one of the GIMP>K/Win32 gods can enlighten a mere mortal on the > modifications that need to be done to build GIMP with MinGW?

Well, I think you summarized it quite nicely. One shouldn't expect to necessarily be able to say "./configure; make install", but by doing it step by step in each subdirectory, it shouldn't be that hard. I use automake 1.7, autoconf 2.54 and libtool 1.5 with no personal modifications.

--tml

On 10 Aug 2003 at 19:00, Tor Lillqvist wrote:

Michael Schumacher writes:
> Building with MinGW is a bit more complicated - the packages of > libiconv and libintl that are linked from > http://www.gimp.org/~tml/gimp/win32/downloads.html don't include > import libriaries to be used with libtool. All my tries to create > them with pexports and dlltool didn't produce working libs.

(Note to those who don't know: Perhaps a bit surprisingly, Win32 binaries for libiconv and gettext are distributed from FSF's ftp site. Even more surprising, they are build with MSVC, and only MS format import libraries are supplied.)

Umm, sorry, I don't remember how I produced import libraries for those... Hmm, I do write on the downloads page that I used pexports and dlltool, so presumably I did, but I don't remember the details. Anyway, libiconv and libintl both export just a handful of functions, so just extract the list of exported functions with objdump or whatever, edit it into a .def file, and produce the import library with dlltool?

The result of make after creating the libintl.a & libiconv.a files:

Creating library file: .libs/libgimpui-1.3.dll.a .libs/gimpui.o(.text+0x159):gimpui.c: undefined reference to `gimp_min_colors' .libs/gimpui.o(.text+0x170):gimpui.c: undefined reference to `gimp_install_cmap'
.libs/gimpui.o(.text+0x1a4):gimpui.c: undefined reference to `gimp_gamma' ...

and many more undefined references to 'gimp_...'.

Would you mind sharing your libiconv.a and libintl.a - and the corresponding .def files? Maybe it can be figured out how you created them.

Maybe one of the GIMP>K/Win32 gods can enlighten a mere mortal on the >

modifications that need to be done to build GIMP with MinGW?

Well, I think you summarized it quite nicely. One shouldn't expect to necessarily be able to say "./configure; make install", but by doing it step by step in each subdirectory, it shouldn't be that hard. I use automake 1.7, autoconf 2.54 and libtool 1.5 with no personal modifications.

You mentioned that libintl.h has to be modified - is this just a #define or something else?

Michael

Michael Schumacher writes:
> The result of make after creating the libintl.a & libiconv.a files:

> Creating library file: .libs/libgimpui-1.3.dll.a > .libs/gimpui.o(.text+0x159):gimpui.c: undefined reference to `gimp_min_colors' > .libs/gimpui.o(.text+0x170):gimpui.c: undefined reference to `gimp_install_cmap' > .libs/gimpui.o(.text+0x1a4):gimpui.c: undefined reference to `gimp_gamma' > ...

> and many more undefined references to 'gimp_...'.

Well, the above messages doesn't seem to have much to do with libintl and libiconv import libraries. It seems that you aren't for some reason linking with libgimp's import library. The Makefile.am does have $(libgimp) in libgimpui_1_3_la_LIBADD, so it should. What does your make output from the libtool --mode=link phase look like? For me it is as follows:

/bin/bash ../libtool --mode=link gcc -mcpu=pentium3 -g -O2 -Wall -mms-bitfields -L/target/lib -o libgimpui-1.3.la -rpath /target/head/lib -version-info 17:0:0 -no-undefined -export-symbols gimpui.def gimpui.lo gimpmenu.lo gimpmiscui.lo gimpbrushmenu.lo gimpfontmenu.lo gimpgradientmenu.lo gimppatternmenu.lo gimpexport.lo ./libgimp-1.3.la ../libgimpwidgets/libgimpwidgets-1.3.la ../libgimpcolor/libgimpcolor-1.3.la ../libgimpbase/libgimpbase-1.3.la -Li:/target/lib -lgtk-win32-2.0 -lgdk-win32-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangowin32-1.0 -lgdi32 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lintl -liconv rm -fr .libs/libgimpui-1.3.dll.a .libs/libgimpui-1.3.dll.aT .libs/libgimpui-1.3.la .libs/libgimpui-1.3.lai if test "x`/usr/bin/sed 1q gimpui.def`" = xEXPORTS; then cp gimpui.def .libs/libgimpui-1.3-17.dll.def; else echo EXPORTS > .libs/libgimpui-1.3-17.dll.def; cat gimpui.def >> .libs/libgimpui-1.3-17.dll.def; fi gcc -mcpu=pentium3 -shared .libs/libgimpui-1.3-17.dll.def .libs/gimpui.o .libs/gimpmenu.o .libs/gimpmiscui.o .libs/gimpbrushmenu.o .libs/gimpfontmenu.o .libs/gimpgradientmenu.o .libs/gimppatternmenu.o .libs/gimpexport.o -L/src/gimp-current/libgimpbase/.libs -Li:/target/lib -L/src/gimp-current/libgimpcolor/.libs -L/target/lib ./.libs/libgimp-1.3.dll.a ../libgimpwidgets/.libs/libgimpwidgets-1.3.dll.a ../libgimpcolor/.libs/libgimpcolor-1.3.dll.a ../libgimpbase/.libs/libgimpbase-1.3.dll.a /target/lib/libgtk-win32-2.0.dll.a /target/lib/libgdk-win32-2.0.dll.a /target/lib/libatk-1.0-0.dll /target/lib/libgdk_pixbuf-2.0.dll.a /target/lib/libpangowin32-1.0.dll.a -lgdi32 /target/lib/libpango-1.0.dll.a /target/lib/libgobject-2.0.dll.a /target/lib/libgmodule-2.0.dll.a /target/lib/libglib-2.0.dll.a -lintl -liconv -mcpu=pentium3 -mms-bitfields -o .libs/libgimpui-1.3-17.dll -Wl,--image-base=0x10000000 -Wl,--out-implib,.libs/libgimpui-1.3.dll.a Creating library file: .libs/libgimpui-1.3.dll.a creating libgimpui-1.3.la
(cd .libs && rm -f libgimpui-1.3.la && ln -s ../libgimpui-1.3.la libgimpui-1.3.l a)

> Would you mind sharing your libiconv.a and libintl.a - and the > corresponding .def files?

(Sent in private reply.)

> You mentioned that libintl.h has to be modified - is this just a #define or > something else?

It's just a change at one line, line 102, which should be:

# if __GNUC__ >= 2 && !defined __APPLE_CC__ && !defined __MINGW32__ && (defined __STDC__ || defined __cplusplus)

The && !defined __MINGW32__ had to be added, otherwise it tries to use some odd __adm__ stuff that doesn't work correctly when import libraries are involved.

--tml

> Another reason may be that it is difficult to build the development > version because it depends on released versions of some libraries that > are not included yet in the major GNU/Linux distributions

Whether they're included in the latest major distributions is quite irrelevant unless a developer (or indeed, user) is USING the latest major distributions. I imagine (okay, know) that unix-heads can be pretty shy of re-installing their operating system world just to get a small handful of the latest versions of OMG L33T DEPS!!! apps working properly.

As you say, as time approaches infinity the issue tends to zero.

Meanwhile...

--Adam

Nathan Carl Summers wrote:

Like in any Free Software project, developers are leaving from time to time to pursue other projects. And from time to time, new developers are joining the team and starting to contribute. However, it looks like the number of new developers joining the GIMP development has been decreasing in the recent years.

:-(

Probably one of the main reasons is that Gimp isn't the only major open-source end-user app anymore.

I don't think that's the reason. GIMP is still the only major 2D paint and image processing program - and developers who want to work on graphics are unlikely to defect to OpenOffice or GCC or something.

But yes, I would not be surprised if Gimp was percieved as stagnating.

No - I think some people may percieve it as "finished" - although I personally know that's not true, many people are quite happy with GIMP as it is today.

As a committed OpenSource developer who might have been interested in working on GIMP, I have to say that the level of acrimony and hostility that I see between developers is VERY off-putting. (I've been lurking here for quite some time).

Other projects I work on are generally places where friends meet to develop software - and which have the occasional bust-up over some technical issue. Here, it seems that there is a continual hostile undercurrent and everything is challenged and fought over tooth and nail.

I don't know whether you all believe that - or how you do anything about it if you do believe it. But for me, it's the number one reason not to get into mainstream GIMP development.

I'm only one data point though - others may have quite different reasons to stay away.

One thing that would revive GIMP's fortunes immensely would be to merge GIMP and FilmGIMP back into one package. I know that's a difficult task - and a highly contentious issue too - but if there are only 'N' GIMP developers in the world, you'd really hope that N/2 of them were not off working on FilmGIMP.

---- Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation & Training (817)619-2466 (Fax) Work: sjbaker@link.com http://www.link.com Home: sjbaker1@airmail.net http://www.sjbaker.org

On Mon, 11 Aug 2003, Stephen J Baker wrote:

No - I think some people may percieve it as "finished" - although I

Even if the GIMP had every feature of the current versions of Adobe PhotoShop, Corel Painter, and Jasc Paint Shop combined it still wouldn't be finished. There is always something more, more features more file formats, more platforms.

personally know that's not true, many people are quite happy with GIMP as it is today.

The GIMP is quite simply the best Free Software, Open Source Raster Graphics tool out there but I want MORE! I hope the GIMP will (eventually) become the best Raster Graphics tool bar none.

As a committed OpenSource developer who might have been interested in working on GIMP, I have to say that the level of acrimony and hostility that I see between developers is VERY off-putting. (I've been lurking here for quite some time).

I don't know whether you all believe that - or how you do anything about it if you do believe it. But for me, it's the number one reason not to get into mainstream GIMP development.

I feel that way too, unfortunately it is so hard not to react in the same way and get off the downward spiral. I only very grudginly subscribed to the developer list at all.

I feel that the active lead developer(s) need to admit this is not a democracy and be the bad guy, be the benevolent dictator, be the leader and take decisions that move the GIMP forward.

I'm only one data point though - others may have quite different reasons to stay away.

I am sure there are other factors too but I tend to believe that the hostility is a deciding factor that turns off new developers.

One thing that would revive GIMP's fortunes immensely would be to merge GIMP and FilmGIMP back into one package. I know that's a

Not as impractical as trying to merge Gnome and KDE but they have freedesktop.org and are increasingly working together on shared standards so GIMP and CinePaint should be able to work together too.

If you look at the history of FilmGIMP it was on an older Hollywood branch of the GIMP and remerging the branches would have been very difficult even then and the GIMP developers seem to favour waiting for GEGL to provide the 32-bit image support.

The port of the GIMP to Gnome2 and various restructuring of FilmGIMP now CinePaint (they are gradually creeping towards using more C++ for example) have made the two increasingly incompatible.

difficult task - and a highly contentious issue too - but if there

I dont even understand why it is contentious anymore.

The split has happened and people need to accept it and move on. Blame, accusations or resentment help no one. One the emotional issues are out of the way it just becomes an issue of how willing people are to what needs to be done.

are only 'N' GIMP developers in the world, you'd really hope that N/2 of them were not off working on FilmGIMP.

Keeping a shared standardised Plugin API might be a realistic achievable goal and help minimize duplication of effort but again the question is if there are people willing and able to do the work.

There are file format incompatibilities in XCF which Sven recently 'brought up' on the CinePaint list, without 32-bit colour depth there is only a limited amount that GIMP can do but if there are people willing and able to do the work...

The next generation file format will have to consider interoperability with third party applications and make some compromises for the greater good (use existing standards wherever possible would clearly be a good star) and hopefully CinePaint will be considered and kept in mind as part of this process.

Sincerly

Alan Horkan http://advogato.org/person/AlanHorkan/

Alan Horkan wrote:

I feel that way too, unfortunately it is so hard not to react in the same way and get off the downward spiral. I only very grudginly subscribed to the developer list at all.

I feel that the active lead developer(s) need to admit this is not a democracy and be the bad guy, be the benevolent dictator, be the leader and take decisions that move the GIMP forward.

I like the 'benevolent dictator' model for OpenSource management - it works well in so many projects - ranging from tiny three man projects right up to the Linux kernel itself.

It's really hard to come to a firm decision in a timely manner in an environment where everyone's voice counts equally...doubly so if things get ugly.

The art is to find a dictator who actually *is* benevolent.

---- Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation & Training (817)619-2466 (Fax) Work: sjbaker@link.com http://www.link.com Home: sjbaker1@airmail.net http://www.sjbaker.org

On 11 Aug 2003 at 1:57, Tor Lillqvist wrote:

Michael Schumacher writes:
> The result of make after creating the libintl.a & libiconv.a files:

> Creating library file: .libs/libgimpui-1.3.dll.a > .libs/gimpui.o(.text+0x159):gimpui.c: undefined reference to `gimp_min_colors' > .libs/gimpui.o(.text+0x170):gimpui.c: undefined reference to `gimp_install_cmap' > .libs/gimpui.o(.text+0x1a4):gimpui.c: undefined reference to `gimp_gamma' > ...

> and many more undefined references to 'gimp_...'.

Well, the above messages doesn't seem to have much to do with libintl and libiconv import libraries. It seems that you aren't for some reason linking with libgimp's import library. The Makefile.am does have $(libgimp) in libgimpui_1_3_la_LIBADD, so it should. What does your make output from the libtool --mode=link phase look like?

/bin/sh ../libtool --mode=link gcc -Ic:/usr/src/include -Wall -mms-bitfields - Lc:/usr/src/lib -o libgimpui-1.3.la -rpath /c/temp/gimp1.3/lib -version-info 18:0:0 -no-undefined -export-symbols gimpui.def gimpui.lo gimpmenu.lo gimpmiscui.lo gimpbrushmenu.lo gimpfontmenu.lo gimpgradientmenu.lo gimppatternmenu.lo gimpexport.lo ./libgimp-1.3.la ../libgimpwidgets/libgimpwidgets-1.3.la ../libgimpcolor/libgimpcolor-1.3.la ../libgimpbase/libgimpbase-1.3.la -Lc:/usr/src/lib -lgtk-win32-2.0 -lgdk-win32- 2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangowin32-1.0 -lgdi32 -lpango-1.0 -lgobject- 2.0 -lgmodule-2.0 -lglib-2.0 -lintl -liconv gcc -shared .libs/gimpui.o .libs/gimpmenu.o .libs/gimpmiscui.o .libs/gimpbrushmenu.o .libs/gimpfontmenu.o .libs/gimpgradientmenu.o .libs/gimppatternmenu.o .libs/gimpexport.o - L/c/usr/compile/gimp/libgimpbase/.libs -L/c/usr/compile/gimp/libgimpcolor/.libs -Lc:/usr/src/lib ./.libs/libgimp-1.3.dll.a ../libgimpwidgets/.libs/libgimpwidgets-1.3.dll.a ../libgimpcolor/.libs/libgimpcolor-1.3.dll.a ../libgimpbase/.libs/libgimpbase- 1.3.dll.a -lgtk-win32-2.0 -lgdk-win32-2.0 -latk-1.0 -lgdk_pixbuf-2.0 - lpangowin32-1.0 -lgdi32 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 - lintl -liconv -mms-bitfields -o .libs/libgimpui-1.3-18.dll -Wl,-retain-symbols- file -Wl,gimpui.def -Wl,--out-implib,.libs/libgimpui-1.3.dll.a Creating library file: .libs/libgimpui-1.3.dll.a .libs/gimpui.o(.text+0x159):gimpui.c: undefined reference to `gimp_min_colors' ...

I found a workaround - instead of libgimp-1.3.dll.a and libgimpui-1.3.dll.a, use libgimp-1.3.a and libgimpui-1.3.a. I modified the corresponsing .la files accordingly.

This makes installing a bit painful - I had to disable the install target in the libgimp Makefile and copy the two libs manually - but now I've got a working GIMP 1.3 on Win32.

You mentioned that libintl.h has to be modified - is this just a #define or >

something else?

It's just a change at one line, line 102, which should be:

# if __GNUC__ >= 2 && !defined __APPLE_CC__ && !defined __MINGW32__ && (defined # __STDC__ || defined __cplusplus)

The && !defined __MINGW32__ had to be added, otherwise it tries to use some odd __adm__ stuff that doesn't work correctly when import libraries are involved.

Thanks, this works.

Michael

Dave Neary writes:

Another reason may be that it is difficult to build the development version because it depends on released versions of some libraries that are not included yet in the major GNU/Linux distributions (e.g., GTK+ version 2.2.2).

both debian unstable, mandrake and redhat provides gtk+2.x for quite a long time.

there's no problem in providing both gtk+-1.2.x and gtk+-2.x in a distro.

Also, the number of dependencies for GIMP 1.3.x is much higher than the number of dependencies for GIMP 1.2.x, so it is more difficult to have a working build environment for the 1.3.x version.

this is a valid point for:
- users of very old distributions
- non developer users (that is most end users) - windows users (for which getting both a working development suit and enough knowledge to build something with required dependancies is probably not easy)

Do we need binary distributions?
--------------------------------

There was a discussion about binary distributions. This may help people to try some versions of the GIMP (especially the development versions) without having to compile everything. However, maintaining binaries is a lot of work, even if we only maintain binaries supplied by others. In addition, this would bring some additional responsabilities that we do not want to have. For these reasons, it was decided that www.gimp.org would not host any binaries but would link to the pages of those who are providing binaries for various platforms.

yes development and packaging (well binary tarball is some kind of packaging) are two different tasks.

you can either: - leave it to distributions (after all gimp-1.3 is already provided in mandrake contribs and in debian unstable) - leave it to a nightly build system (see mozilla) - leave it to another specialized team (aka you need one people that sometimes build windows binaries and someone who sometimes build static gimp for linux)

Is Bugzilla too hard to use for new users? ------------------------------------------

It was suggested to make it easier for users to submit bug reports, for example by having an e-mail address to which bug reports can be sent without having to register to Bugzilla (we already have such an address, although it is not widely known). This proposal was rejected because most of the bug reports (especially from new users) are incomplete and require additional information. If the user does not have a Bugzilla account, it is not possible to rely on the automatic notification system to send messages to the user when a comment is added to their bug report or when the status of their bug report changes.

even if bug reporting by mail may not look suitable, being able to anwser bugzilla by mail is a must.
it saves quite a lot of time and is often see as more easy to use by developers (at least here at mdk).

there're several extensions that do this (see freshmeat.net or soft/bugs module in mandrake cvs).

On Fri, 22 Aug 2003 13:15:57 +0200, Thierry Vignaud wrote:

Another reason may be that it is difficult to build the development version because it depends on released versions of some libraries that are not included yet in the major GNU/Linux distributions (e.g., GTK+ version 2.2.2).

both debian unstable, mandrake and redhat provides gtk+2.x for quite a long time.

The current GIMP requires GTK+ 2.2.0 and recommends 2.2.2 (this will be required by the next version). Unfortunately, many users of the distributions mentioned above are still using GTK+ 2.0.x, not 2.2.x. Besides, the majority of the users are not using the latest version of their distribution.

there's no problem in providing both gtk+-1.2.x and gtk+-2.x in a distro.

Of course. This is what has allowed many users to experiment with the latest GIMP while still being able to work with the stable version based on GTK+ 1.x.

Also, the number of dependencies for GIMP 1.3.x is much higher than the number of dependencies for GIMP 1.2.x, so it is more difficult to have a working build environment for the 1.3.x version.

this is a valid point for:
- users of very old distributions
- non developer users (that is most end users) - windows users (for which getting both a working development suit and enough knowledge to build something with required dependancies is probably not easy)

This is not only about "users of very old distributions." The world is not only Linux and Windows, and the Linux world is not only made of binary distributions. I am typing this from a Solaris machine on which I had to build all GIMP dependencies from sources.

Assuming that a system has at least some basic tools such as make and a compiler, building GIMP 1.3.x adds 27 dependencies (or 32 if you are a developer who also needs libtool, autoconf, etc.) Compare this with GIMP 1.2.x, which had only 11 dependencies (or 14 for developers.)

Do we need binary distributions?

[...]

you can either:
- leave it to distributions (after all gimp-1.3 is already provided in mandrake contribs and in debian unstable) - leave it to a nightly build system (see mozilla) - leave it to another specialized team (aka you need one people that sometimes build windows binaries and someone who sometimes build static gimp for linux)

There are actually two issues: the creation of the binaries and their distribution.

Building the binaries can be done by a nightly build system or by a dedicated team. But we would probably have to generate a large number of binaries:
- If we build Linux binaries, there is a risk that they conflict with the packages supported by the distribution. We have to decide if the installation prefix is /usr, /usr/local, /opt/gnome or some other path.
- We would have to provide RPM and Debian packages as well as some tarballs.
- Although this is getting a bit better now, different RPM-based distributions are using different naming conventions for the packages on which the GIMP depends (e.g. Red Hat vs. SuSE). - What about Solaris, MacOS X, IRIX, AIX and others?

Even if we could create the binary packages, I don't think that we should distribute them from the GIMP web site. This means that we would get support questions for these binaries. We already get some distribution-specific bug reports from time to time, but we can usually divert them to a more appropriate place. Supporting the binaries is not something that most developers would enjoy doing.

So it is better if someone else can take care of building and distributing binaries for us. This can be a Linux distributor or some individual who puts the binaries on his web site (like it is currently done for the Windows version). We would be glad to link to these sites from the GIMP web site, but it is better to avoid hosting any binaries on www.gimp.org.

Is Bugzilla too hard to use for new users?

[...]

even if bug reporting by mail may not look suitable, being able to anwser bugzilla by mail is a must.
it saves quite a lot of time and is often see as more easy to use by developers (at least here at mdk).

As far as I am concerned (I spend several hours per week on Bugzilla), I don't think that answering Bugzilla by mail would really save time. For every third or fourth bug to which I respond, I do a Bugzilla query to find related bugs. Since I use the web interface for queries, I don't think that I would save much time by using e-mail for the other bugs.

-Raphaël

Raphaël Quinet writes:

Another reason may be that it is difficult to build the development version because it depends on released versions of some libraries that are not included yet in the major GNU/Linux distributions (e.g., GTK+ version 2.2.2).

both debian unstable, mandrake and redhat provides gtk+2.x for quite a long time.

The current GIMP requires GTK+ 2.2.0 and recommends 2.2.2 (this will be required by the next version). Unfortunately, many users of the distributions mentioned above are still using GTK+ 2.0.x, not 2.2.x. Besides, the majority of the users are not using the latest version of their distribution.

- current debian unstable => 2.2.2 (2.2.2-3) - current mandrake cooker => 2.2.2 (2.2.2-6mdk) - current rh rawhide => 2.2.2 (gtk2-2.2.2-2.1)

mdk9.2 is scheduled to be released on septembed, i do not remebed exact date for rh but it's supposed to be at the same time. debian is expected to be releasd on december.

so this issue may not be a real one.

you're left to few classes of users:

- those who use only distro packages: they will wait until a binary package is availlable

- those who know how ot build programs: they're supposed to know how to build dependancies
and anyway, maybe adding a few ifdef round gimp code using specific 2.2.x features if it can safely be disabled may help users of older releases or other distros.

Also, the number of dependencies for GIMP 1.3.x is much higher than the number of dependencies for GIMP 1.2.x, so it is more difficult to have a working build environment for the 1.3.x version.

this is a valid point for:
- users of very old distributions
- non developer users (that is most end users) - windows users (for which getting both a working development suit and enough knowledge to build something with required dependancies is probably not easy)

This is not only about "users of very old distributions." The world is not only Linux and Windows, and the Linux world is not only made of binary distributions.

agreed.

Assuming that a system has at least some basic tools such as make and a compiler, building GIMP 1.3.x adds 27 dependencies (or 32 if you are a developer who also needs libtool, autoconf, etc.) Compare this with GIMP 1.2.x, which had only 11 dependencies (or 14 for developers.)

factoring features around all tools is nice even if it's bring more dependancies.
sure it's

Even if we could create the binary packages, I don't think that we should distribute them from the GIMP web site. This means that we would get support questions for these binaries. We already get some distribution-specific bug reports from time to time, but we can usually divert them to a more appropriate place. Supporting the binaries is not something that most developers would enjoy doing.

So it is better if someone else can take care of building and distributing binaries for us. This can be a Linux distributor or some individual who puts the binaries on his web site (like it is currently done for the Windows version).

so since, most oses are in one of the following states: - already provides gimp-1.3.x somewhere (debian unstable, mandrake contribs)
- is ready for gimp-1.3.x regarding dependancies (redhat) - some site provide prebuild binaires (windows)

and since other oses are either small regarding number of users or their users are expected to know how to build something (eg: those who already build gimp on solaris like you) are able to deal with a few more dependancies that are anyway needed for other programs, i think this issue can then be closed and this feature be not provided by gimp.org.

We would be glad to link to these sites from the GIMP web site, but it is better to avoid hosting any binaries on www.gimp.org.

though, this web site could then figure some url to get binaries for most people (either distros packages or tarballs from third parties) [maybe it exists already, i didn't check it out]

As far as I am concerned (I spend several hours per week on Bugzilla), I don't think that answering Bugzilla by mail would really save time. For every third or fourth bug to which I respond, I do a Bugzilla query to find related bugs. Since I use the web interface for queries, I don't think that I would save much time by using e-mail for the other bugs.

well, ones can use its bugzilla mail box for such queries :-)

Hi,

On Sun, 2003-08-24 at 14:23, Thierry Vignaud wrote:

and anyway, maybe adding a few ifdef round gimp code using specific 2.2.x features if it can safely be disabled may help users of older releases or other distros.

We did that for a while. It not only became difficult to maintain but at some point it became apparent that gtk+-2.0 just had too many bugs that could not be worked around. The current code still has some ifdefs that enable workarounds for bugs in gtk+ before version 2.2.2. We do this in order to avoid a dependency on 2.2.2 but at some point before gimp-2.0, we will have to drop these workarounds and depend on gtk+-2.2.2 or newer.

Sven

Sven Neumann writes:

and anyway, maybe adding a few ifdef round gimp code using specific 2.2.x features if it can safely be disabled may help users of older releases or other distros.

We did that for a while. It not only became difficult to maintain but at some point it became apparent that gtk+-2.0 just had too many bugs that could not be worked around. The current code still has some ifdefs that enable workarounds for bugs in gtk+ before version 2.2.2. We do this in order to avoid a dependency on 2.2.2 but at some point before gimp-2.0, we will have to drop these workarounds and depend on gtk+-2.2.2 or newer.

sure, when woraounding old bugs became too much development time consuming, it's better to just bump the requires.

what's more, the odds are high that all distributors that will ship gimp-2.0 will ship gtk+-2.2.x too

Hi,

On Sun, 2003-08-24 at 16:00, Thierry Vignaud wrote:

what's more, the odds are high that all distributors that will ship gimp-2.0 will ship gtk+-2.2.x too

Not only are the odds high, they don't have any other chance. On the other hand, by the time that gimp-2.0 will be ready, we will most likely see gtk+-2.4 being released. But I'd rather avoid a dependency on that version of possible.

Sven

tvignaud@mandrakesoft.com (2003-08-24 at 1423.45 +0200):

- current debian unstable => 2.2.2 (2.2.2-3) - current mandrake cooker => 2.2.2 (2.2.2-6mdk) - current rh rawhide => 2.2.2 (gtk2-2.2.2-2.1)

mdk9.2 is scheduled to be released on septembed, i do not remebed exact date for rh but it's supposed to be at the same time. debian is expected to be releasd on december.

I hope debian pushes the unstable to the testing one before going for the release, otherwise we end with a bad version in the released distro (2.2.1, which has some nasty problems with Xinput, IOW, tablets, while 2.2.2 seems to be working).

so this issue may not be a real one.

Some people, while compiling some things, prefer to have the rest from normal releases, not bleeding edge ones. Sometimes that is posible, sometimes it is not, I think we got caught in one of those "out of sync" moments.

- those who know how ot build programs: they're supposed to know how to build dependancies

How to and have time to handle all. ;]

well, ones can use its bugzilla mail box for such queries :-)

Which tool are you talking about, btw? The full name, please.

GSR

Thierry Vignaud wrote:

Raphaël Quinet writes:

The current GIMP requires GTK+ 2.2.0 and recommends 2.2.2 (this will be required by the next version). Unfortunately, many users of the distributions mentioned above are still using GTK+ 2.0.x, not 2.2.x. Besides, the majority of the users are not using the latest version of their distribution.

- current debian unstable => 2.2.2 (2.2.2-3) - current mandrake cooker => 2.2.2 (2.2.2-6mdk) - current rh rawhide => 2.2.2 (gtk2-2.2.2-2.1)

mdk9.2 is scheduled to be released on septembed, i do not remebed exact date for rh but it's supposed to be at the same time. debian is expected to be releasd on december.

so this issue may not be a real one.

It's real in so far as most linux users aren't using RedHat 9.x, Debian unstable or Mandrake 9.x - I am using Debian testing here, for example, to which I moved relatively recently from RedHat 6.2, which is still the distro available in work, where we have a binary package dependency (a database product) that isn't available in the version we use for later distros.

On that work machine, building a 1.2 GIMP from scratch can be done in a day (that is, from glib up, through libjpeg, libpng and friends). Building a 1.3 CVS GIMP takes considerably longer than that.

you're left to few classes of users:

- those who use only distro packages: they will wait until a binary package is availlable

One of the reasons that we haven't had as much testing as we'd like yet on 1.3.

- those who know how ot build programs: they're supposed to know how to build dependancies
and anyway, maybe adding a few ifdef round gimp code using specific 2.2.x features if it can safely be disabled may help users of older releases or other distros.

This is an immense simplification. There are people who want to use the new GIMP, but have had problems building some part of it. You're forgetting that the target audience of the GIMP is a user interested in graphics, not a developer.

this is a valid point for:
- users of very old distributions

Even recent distros - GNOME 2 has only been around for a little over a year.

- non developer users (that is most end users)

And most people we're interested in.

- windows users (for which getting both a working development suit and enough knowledge to build something with required dependancies is probably not easy)

Setting up a build environment in windows is something of a nightmare. Windows users are also our biggest user base, I reckon. And they also find lots of bugs in the GIMP because it's used in ways that Linux doesn't even think of doing.

Assuming that a system has at least some basic tools such as make and a compiler, building GIMP 1.3.x adds 27 dependencies (or 32 if you are a developer who also needs libtool, autoconf, etc.) Compare this with GIMP 1.2.x, which had only 11 dependencies (or 14 for developers.)

factoring features around all tools is nice even if it's bring more dependancies.

Sure - it's The Unix Way to use smaller packages to do specific jobs. The point is that each smaller package which isn't already available on the system raises the barrier for entry for GIMP building.

and since other oses are either small regarding number of users or their users are expected to know how to build something (eg: those who already build gimp on solaris like you) are able to deal with a few more dependancies that are anyway needed for other programs, i think this issue can then be closed and this feature be not provided by gimp.org.

I'm not sure I follow the reasoning... The point is that to get more people using, testing, contributing to and developping for the newer version of the GIMP, freely available binary packages lower the barrier. Of course we don't want to build the packages, but if volunteers do packages for a given distro, we should have one place where we link to the externally maintained binaries. It would be pretty simple to do, and would, I think, prove a great benefit to people eager to see what we've been up to for the last 3 years.

Cheers,
Dave.