On Fri, 18 Jul 2003, Sven Neumann wrote:

Hi,

I'd like to inform you about our plans for the GIMP 2.0 release.

First of all, Mitch and me are not willing to raise the 2.0 versus 1.4 discussion again.

Gimp is more than "Mitch and me," isn't it?

Both sides have expressed their arguments. We took quite some time to think about all of them and to reconsider our decision. We came to the point that it should be called 2.0. It's just a number, so please, before you start the discussion again, think twice if it's worth it.

It really is worth it. We will loose *A LOT* of trust with our users if we disappoint them. There are many more than a trivial number of people whe expect CMYK, 16-bit, etc in gimp 2.0. These people are our *MOST ACTIVE USERS* and those who are waiting for gimp to have these features. Any time in the past two years that someone has asked on IRC or mailing lists when gimp will have these features.

The second group mentioned I worry about more; the people who need these features, when they hear that 2.0, will check it out and sorely be disappointed. I don't know how well a reference to the story of the Boy Who Cried Wolf communicated cross-culturally, but I can tell you that once lied to once, these people will probably not trust the gimp developers again. They will go elsewhere. This is a big loss to us -- imagine what contributions would come to gimp if people who professionally need features like deep images would be using the software. The lack of deep image support up to this point has already cost us a lot; those who flocked to the program formerly known as FilmGimp would have flocked to us instead.

Yes, calling the new release 2.0 is a LIE. I cannot emphasize this strongly enough. It is a lie because we have told many, many people what 2.0 will do. To release a 2.0 without these features is pure misrepresentation. It is much too late to put the worms back into the can.

Rockwalrus

Am Fre, 2003-07-18 um 23.07 schrieb Nathan Carl Summers:

Gimp is more than "Mitch and me," isn't it?

No, it's not. I'm really surprised it took that long for people to notice.

Nathan Carl Summers wrote:

Yes, calling the new release 2.0 is a LIE. I cannot emphasize this strongly enough. It is a lie because we have told many, many people what 2.0 will do. To release a 2.0 without these features is pure misrepresentation. It is much too late to put the worms back into the can.

"Me Too."

I've expressed my opinion before, but here are some links:

http://developer.gimp.org/gimp-future

Notable points:

The 1.3.x "Cleanup for 2.0" branch o Port gimp to gtk+-2.0
o Cleanup some internal structures o Implement a few, well defined, new features o Think about a new way to handle plug-in distribution

The 1.9.x "Building GIMP 2.0" branch o GEGL -- Gimp 'E' Graphical Library o GCim -- The convergence integrated media object and utility library.

Colophon:

Feel free to send updates/comments/fixes/flames/whatever. We will keep this document up-to-date and post new versions when neccessary.

Sven & Mitch

Second link:

http://developer.gimp.org/gimp-todo.html

Lots of features listed, all of them targetted at GIMP 1.4, none of which mention GEGL and fully conform the above document. Some of which, in fact, I don't think have even been completed. ("Script-Fu overhaul", "Image/File Information", ?)

Chris

On 18-Jul-2003, Christopher Curtis wrote:

The 1.9.x "Building GIMP 2.0" branch o GEGL -- Gimp 'E' Graphical Library o GCim -- The convergence integrated media object and utility library.

I am one of these active users that have been lead to believe that gimp 2.0 will use GEGL. So, all the developers out that think 2.0 is yet another small gimp release, or something else (imho) stupid, can just go away or something.

Im actually kind of sick of listening all of you bicker back and forth.

From my outsider point of view, 2.0 is set in stone, and what it will include

will be set in stone. Also, from my outsider pov, stuff like gegl is a very cool idea. Anything that allows gimp to be more powerful is always a good thing. I also see gegl as a major feature, something that would produce a 2.0.

However, the more you all bicker, the less work is actually getting done. I hate to have to be the one saying this, but you should just be coding, because in the end, whoever codes gimp 2.0 is the one who gets to say what happens, or _nothing happens at all._

Gegl is basically the end all be all gimp graphics rendering engine. It will be able to do what no popular graphics manipulation program has done before. (I think.) 16-bit per channel graphics is good, and internal floating point based calculations independent of the actual image's bitdepth is good as well (due to the fact multi-layered images often go above 1.0 and below 0.0, and clipping severely damages the output.)

Also, while Im on the pro gimp 2.0 kick, I read the xcf2 threads. I agree, something like gimp2 will need a better file format. Internally, I dont care whats in it. Im not a gimp developer, Im a user, so I should have to care. _However_, it needs to be able to be very extendable. I want to be able to store all future gegl supported bitdepth and color space types with it, I want to be able to depend on it to be stable the same way the professional people depend on psd being a half way decent format, and I want it to someday exist, the same way I want gimp2 to someday exist.

A lot of users out there are depending on the gimp development team to get gimp2 done sometime in their lifetimes, and from what I see on here, this may never happen. And Im going to be severely disappointed if this happens.

On Friday 18 July 2003 16:59, Sven Neumann wrote:

Hi,

I'd like to inform you about our plans for the GIMP 2.0 release.

(...)

Originally we wanted to get GIMP 2.0 out at GimpCon. Since that is actually in three weeks, we will definitely not make it but I am still optimistic that we will manage to feature-freeze at the Camp and do something that we can call a 2.0 prerelease. Perhaps we will need to declare one or two missing features as bugs but basically the release made at GimpCon should have everything that GIMP 2.0 will have.

Sven,

I am here working, though slowly, on the programable layer mode, which I proposed when I first joined the list. It's not such a small change, since adding layer modes breaks the cross-reading of .xcf files.

So what I need to know now is: - If I deliver a partially working patch by next week, could it be included before the feature freeze?
- Else, I think the proper moment to bring it up would be when the new GIMP file save format, which is on topic nowadays, would be implemented. Could that be 2.2 ?

Or do we have a chance of having this new file format in 2.0? If yes, I think it could be done in a way that new layer formats could be made not to break badly the backwards compatibility.

Thanks.

JS ->

Am Sam, 2003-07-19 um 00.18 schrieb Sven Neumann:

I am not sure what you are trying to say here but actually I was hoping to hear some helpful and constructive comments on gimp-help2 from you. Did you read my mail at all?

I've read every single mail to the mailinglist however I hoped to receive some private mail from you discussing the situation -- which never happened. I normally do not give a dime about unrelated und unfounded blah on mailinglists amoung other problems which prevented me to write to this mailinglist. The interpretation of all this I'll leave to the brave reader.

Here's the explanation about the gimp-help2 project: Mel and I started gimp-help2 from scratch in order to create a completely new structured documentation in XML without any cruft from the old module. We agreed that I am the technical maintainer while he's textual maintainer, proofing and integrating any content we received from contributors. However though we tried to recruit text writers in IRC and live we failed get beyond our 2 people work. After some time Mel was struggling with severe time problems so the project grinded to a halt which is were we still are because I simply cannot write good content.

In order to bring gimp-help2 up to speed (which is what I assume you want) we need:
- Heaps of content
- A way to integrate content with the GIMP

The second point is solvable but the first one means that gimp-help2 will have to pass out on your "2.0" release except you can make a wonder happen.

On 19 Jul 2003, at 12:04, Daniel Egger wrote:

Here's the explanation about the gimp-help2 project: Mel and I started gimp-help2 from scratch in order to create a completely new structured documentation in XML without any cruft from the old module. We agreed that I am the technical maintainer while he's textual maintainer, proofing and integrating any content we received from contributors. However though we tried to recruit text writers in IRC and live we failed get beyond our 2 people work. After some time Mel was struggling with severe time problems so the project grinded to a halt which is were we still are because I simply cannot write good content.

Isn't Rebecca Walter part of the team anymore?

In order to bring gimp-help2 up to speed (which is what I assume you want) we need: - Heaps of content - A way to integrate content with the GIMP

The second point is solvable but the first one means that gimp-help2 will have to pass out on your "2.0" release except you can make a wonder happen.

I could spare a couple of hours, but not much more. Perhaps if there is some simple task I could perform, say copying and pasting stuff from the 1.2 documentation?

On 18 Jul 2003, at 21:59, Sven Neumann wrote:

Well, what will happen after the final 2.0.0 release? I think we should try to target a quick 2.2 release with only minor feature improvements but this is really something that I would want to discuss at the camp...

What happens after 2.2? Is GEGL mature enough for the transition (or will everybody start working on GEGL)?

Hi Sven,

On Saturday 19 July 2003 7:48 am,

It has lots and lots of features that we did never promise and despite of 16bit support I don't see what we would be missing (provided we get the basic CMYK supoprt finished that we started to work on). I really

Since I'm new to the 1.3 branch, could someone outline the current status of CMYK support?

(I searched the mailing list archives for CMYK, but the berkeley page search doesn't seem to be working, and the other archive didn't reveal much discussion...)

This is an area of particular interest to me - I need to use CMYK TIFFs at work - and for that I put together a rudimentary plugin (for 1.2) that separates RGB images into individual channels, and saves CMYK TIFFs...

All the best,

Am Sam, 2003-07-19 um 14.09 schrieb Branko Collin:

Isn't Rebecca Walter part of the team anymore?

Her new job took over all her spare time so she couldn't actively participate. She promised to chime in when there's some content to proof it but since there's not much to proof....

I could spare a couple of hours, but not much more. Perhaps if there is some simple task I could perform, say copying and pasting stuff from the 1.2 documentation?

This was exactly what we were trying to avoid since we're not too happy with the content and the structure of the GUMP.

I think there's two sensible ways to continue from this point: 1) Transform the old help into something that will serve more or less as help for the new GIMP. This will cost quite some amount of time since the help browser is not uptodate and most of the content doesn't exactly fit the 1.3 UI anymore. This would leave gimp-help2 as a playground for a really new manual and online help which might get more love once "2.0" is out. 2) Pump a lot of loving into the new framework to be at least a little help to people needing online help. I'm not exactly happy with this because I'd rather have no online help than one which closely resembles the usefulness of the help of most Windows programs like: "Close - Clicking this button will close your open file".

If you want to help us getting a nice documentation we'd really appreciate if you had a look at the gimp-help2 framework and submit some content in XML/DocBook directly to the CVS or in any other format to us and we'll plug it in.

Mel, I'd love to hear your standpoint and ideas.

PS: I've some nice ideas how to get more exposure and thus help from the community for this project but unfortunately I've to keep a business running which consumes quite a bit of time at the moment. If anyone wants to talk about or realise those or even better ideas this is the right time and place to chime in.

Daniel Egger wrote:

Am Sam, 2003-07-19 um 14.09 schrieb Branko Collin:

Isn't Rebecca Walter part of the team anymore?

Her new job took over all her spare time so she couldn't actively participate. She promised to chime in when there's some content to proof it but since there's not much to proof....

I could spare a couple of hours, but not much more. Perhaps if there is some simple task I could perform, say copying and pasting stuff from the 1.2 documentation?

This was exactly what we were trying to avoid since we're not too happy with the content and the structure of the GUMP.

I think there's two sensible ways to continue from this point: 1) Transform the old help into something that will serve more or less as help for the new GIMP. This will cost quite some amount of time since the help browser is not uptodate and most of the content doesn't exactly fit the 1.3 UI anymore. This would leave gimp-help2 as a playground for a really new manual and online help which might get more love once "2.0" is out. 2) Pump a lot of loving into the new framework to be at least a little help to people needing online help. I'm not exactly happy with this because I'd rather have no online help than one which closely resembles the usefulness of the help of most Windows programs like: "Close - Clicking this button will close your open file".

If you want to help us getting a nice documentation we'd really appreciate if you had a look at the gimp-help2 framework and submit some content in XML/DocBook directly to the CVS or in any other format to us and we'll plug it in.

Mel, I'd love to hear your standpoint and ideas.

PS: I've some nice ideas how to get more exposure and thus help from the community for this project but unfortunately I've to keep a business running which consumes quite a bit of time at the moment. If anyone wants to talk about or realise those or even better ideas this is the right time and place to chime in.

Hi,

I have been messing around with the information found in the pdb and what I would need to use docbook-website. I don't really understand what my problem with other software is, but the structure of a gimp docbook-website was terrible. So much like everything else I tried.

After I spent a day with docbook-website, I got my XML in a Nutshell book out again. I have the beginnings of a dtd for a single plugin document. It is a "chapter 3 level of complexity" dtd. Which means they promised to explain how to reduce some of the redundant lists at a later chapter, and all the other limitations that being on chapter 3 would imply.

It is difficult to share a "freshman" attempt with developers. If anyone is interested in seeing what I am doing, helping, commenting or running it through validation devices, feel free to suggest the best way to share these files.

I have 2 files. plugin.xml and plugin.dtd, I think they can get information from the individual plugins and make web pages from them, eventually.

I am not certain what has been done so far. I do know that my dtd's will be written using plugin and plugins as the namespace for these entities. I will not argue but direct you to page 42 of my XML in a Nutshell book. Also page 17. First Edition.

I also will not write any English documentation until I can afford to buy that book that explains the English rules about hyphens.

thanks for your time, carol

Am Sam, 2003-07-19 um 19.10 schrieb Carol Spears:

It is difficult to share a "freshman" attempt with developers. If anyone is interested in seeing what I am doing, helping, commenting or running it through validation devices, feel free to suggest the best way to share these files.

For the first you managed to confuse me. I'd be happy to help you if I can get a grasp of your problem which probably requires you to reiterate:
- What you're trying to do?
- Your idea of a possible solution
- Your steps to achieve the desired goal - The problems you're facing

(English in whole sentences would be my preferred language; don't care about correct use of hyphens. :))

I also will not write any English documentation until I can afford to buy that book that explains the English rules about hyphens.

Forget about XML and hyphens; send your text over in plain ascii and we'll get the rest fixed. :)

BTW: syngin@gimp.org is not reachable, anyone having a valid address of him or can ask for one on IRC?

Daniel Egger wrote:

Am Sam, 2003-07-19 um 19.10 schrieb Carol Spears:

It is difficult to share a "freshman" attempt with developers. If anyone is interested in seeing what I am doing, helping, commenting or running it through validation devices, feel free to suggest the best way to share these files.

For the first you managed to confuse me. I'd be happy to help you if I can get a grasp of your problem which probably requires you to reiterate:
- What you're trying to do?
- Your idea of a possible solution
- Your steps to achieve the desired goal - The problems you're facing

(English in whole sentences would be my preferred language; don't care about correct use of hyphens. :))

I also will not write any English documentation until I can afford to buy that book that explains the English rules about hyphens.

Forget about XML and hyphens; send your text over in plain ascii and we'll get the rest fixed. :)

BTW: syngin@gimp.org is not reachable, anyone having a valid address of him or can ask for one on IRC?

Unfortunately, syngin is not around. I hope he comes back soon.

I tried to work the information that can be found from the plugins themselves, via the pdb. I was going to write a docbook-website template and have gimp write it himself, like my gallery pages or the resource pages that were never finished for mmmaybe.gimp.org. The docbook-website (even though it uses the simple docbook) was cumbersome and horrible and impossible to use without great stretches of the imagination. So many useless things for gimp information.

So I made my own layout. Anybody with a handful of well written python pieces should be able to write a script that would scoop the information from the gimp and put it into this layout. From there, it should be able to go right into a web page via some xsl. I am working through the dtd part right now.

I added a few things to the layout that I would like to see from the plugin authors as well. So, my layout is a little bigger than the pdb entry as it stands.

My goal is to remove the less essential plugins and present them on a web page. If the dtd is written properly for this, the information should be useful for other projects.

I am attaching the files. Sorry. I need to work through my apache configuration as well as mutt before I can share these files the right way. Please be patient with me.

I actually downloaded the gimp2 module from cvs and added a directory called dtd and another called xml to what is already there. I have only done this on my computer though, i have yet to check it in.

Adding cvs directories on your home computer is one of my favorite conversation starters, by the way. It brings out the best in people on the irc, and I am hoping it will do the same on the gimp-developer list as well :)

carol

<!DOCTYPE plugin [ <!ELEMENT plugin (title, summary, version, environment, authorgroup, license, toolbox, image, name, input, output, help, keybinding)> <!ATTLIST title (CDATA) >
<!ELEMENT summary EMPTY>
<!ATTLIST summary abstract CDATA #REQUIRED summary homepage CDATA
summary para CDATA #REQUIRED summary mediacontainer EMPTY > <!ATTLIST summary mediacontainer blurb CDATA (name | profession | date) summary mediacontainer image* EMPTY summary mediacontainer sound CDATA> <!ATTLIST summary mediacontainer image source CDATA #REQUIRED summary mediacontainer image width CDATA #REQUIRED summary mediacontainer image height CDATA #REQUIRED summary mediacontainer image alt CDATA #REQUIRED > <!ELEMENT version ()>
<!ELEMENT environment EMPTY>
<!ELEMENT environment language EMPTY> <!ATTLIST environment language script (standard | perl | python | scriptfu) #REQUIRED> <!ATTLIST revision CDATA>
<!ATTLIST authorgroup EMPTY #REQUIRED> <!ATTLIST authorgroup author* #REQUIRED> <!ATTLIST authorgroup author firstname CDATA authorgroup author othernamename CDATA authorgroup author surname CDATA #REQUIRED authorgroup author homepage CDATA authorgroup author email CDATA #REQUIRED authorgroup author mediacontainer EMPTY> <!ATTLIST authorgroup author mediacontainer blurb CDATA (name | profession | date) authorgroup author mediacontainer image* EMPTY authorgroup author mediacontainer sound CDATA > <!ATTLIST authorgroup author mediacontainer image source CDATA #REQUIRED authorgroup author mediacontainer image width CDATA #REQUIRED authorgroup author mediacontainer image height CDATA #REQUIRED authorgroup author mediacontainer image alt CDATA #REQUIRED > <!ELEMENT authorgroup othercredit* EMPTY> <!ATTLIST authorgroup othercredit firstname CDATA authorgroup othercredit othername CDATA authorgroup othercredit surname CDATA #REQUIRED authorgroup othercredit homepage CDATA authorgroup othercredit email CDATA #REQUIRED authorgroup othercredit mediacontainer EMPTY> <!ATTLIST authorgroup othercredit mediacontainer blurb CDATA (name | profession | date) authorgroup othercredit mediacontainer image* EMPTY authorgroup othercredit mediacontainer sound CDATA > <!ATTLIST authorgroup othercredit mediacontainer image source CDATA #REQUIRED authorgroup othercredit mediacontainer image width CDATA #REQUIRED authorgroup othercredit mediacontainer image height CDATA #REQUIRED authorgroup othercredit mediacontainer image alt CDATA #REQUIRED > <!ATTLIST authorgroup maintainer EMPTY #REQUIRED > <!ATTLIST authorgroup maintainer firstname CDATA authorgroup maintainer othername CDATA authorgroup maintainer surname CDATA #REQUIRED authorgroup maintainer homepage CDATA authorgroup maintainer email CDATA #REQUIRED authorgroup maintainer mediacontainer EMPTY> <!ATTLIST authorgroup maintainer mediacontainer blurb CDATA (name | profession | date) authorgroup maintainer mediacontainer image* EMPTY authorgroup maintainer mediacontainer sound CDATA > <!ATTLIST authorgroup maintainer mediacontainer image source CDATA #REQUIRED authorgroup maintainer mediacontainer image width CDATA #REQUIRED authorgroup maintainer mediacontainer image height CDATA #REQUIRED authorgroup maintainer mediacontainer image alt CDATA #REQUIRED >

]>

Hi,

Right up front, I'd like to say that as far as I'm concerned the 1.3+ debate is closed. I'm happy with 2.0, but even if I weren't I don't think the version number is a big deal. This mail is about other stuff...

Nathan Carl Summers wrote:

On Fri, 18 Jul 2003, Sven Neumann wrote:

First of all, Mitch and me are not willing to raise the 2.0 versus 1.4 discussion again.

Gimp is more than "Mitch and me," isn't it?

Well, I would have said it a little more tactfully, maybe with more than 2 names, but let's look, shall we?

dave@bolsh:/usr/local/src/gimp-1.3$ grep mitch ChangeLog | wc -l 1174
dave@bolsh:/usr/local/src/gimp-1.3$ grep Sven ChangeLog | wc -l 1004
dave@bolsh:/usr/local/src/gimp-1.3$ grep '^[^ ]' ChangeLog | wc -l 2724

So between them they're responsible for 2178/2724 commits in the 1.3 branch, or 80%. Granted not all of those are commits - so it's probably more like 75%.

Third place is 109 (yosh). Then comes Maurits with 108, then (in no particular order) nomis, myself, pedro, rockwalrus, jimmac, Hans Breuer, Daniel Egger, sjburges, Raphael and tml. That brings us down to people who have 10 commits or fewer in the last 3 years. That's it - over 90% of the stuff in 1.3 has been written by 14 people, and the vast majority of that has been written by 2 people.

It's interesting that you brought this up, by the way - I've been thinking for a while about the problems that the gimp has been facing, and why.

The problems as I see them are

1) User feedback on the development series is poor 2) Documentation is poor
3) Our release cycle is poor
4) UI is not a priority.

I think 1, 2 and 3 are related. As are 1 and 4.

Those are the problems at the philosophical level. At the practical level, the problems are:

1) Not enough users use bugzilla to report bugs 2) Not enough developers use Bugzilla to find out what bugs need fixing
3) Not enough developers hear user complaints 4) Not enough users know what's happenning in the developer series.
5) Not enough non-technical people are working on the GIMP (this is at odds with when I joined, when many of the most active GIMP people were non-technical).

That's the practical level. Now, here's why I think these problems exist.

1) Too many communication interfaces, not enough communication.

The GIMP has the following communication methods available to it:

- Website - www.gimp.org - Website - mmmaybe.gimp.org
- Website - gug.sunsite.dk
- IRC - irc.gnome.org
- Usenet - comp.graphics.apps.gimp
- Mailing list - gimp-users@lists.xcf.berkeley.org - Mailing list - gimp-developers@lists.xcf.berkeley.org - Mailing list - gimp-web@lists.xcf.berkeley.org - Mailing list - gimpwin-dev@yahoogroups.com - Mailing list - gimpwin-users@yahoogroups.com - Mail alias - bugs@gimp.org
- Bugzilla - bugzilla.gnome.org
- CVS - cvs.gnome.org
- Release notes.

There's definite consolidation to be done there. That's 13 ways to get information. And 13 ways to send it. I listen personally to about 3 of those... bugs@g.o, Usenet and the devel list.

Certainly when I put stuff in the list, there are several things which aren't intended as information conduits per se - CVS is for versioning source files, but the best way to find out what's happenning with the gimp these days is to read the Changelog.

My first proposal would be to do a reverse split of the users and developers mailing lists - get everyone talking to one another. It will certainly annoy people because of increased traffic, but I think it'll be worth it. We have to face up to the fact that after 3 years without a major release, and only 14 active developers, the GIMP is a small project. Step 1 is to get people talking to each other.

Proposal 2 is to either do away with bugs@gimp.org or de-spam it. I'd actually prefer doing away with it altogether. People (including myself) use it as a crutch to avoid hunting around in bugzilla, and it results in us using bugzilla wrong (no-one takes possesion of gimp bugs, they float around in ownerless land until they get fixed). I would prefer to set up a system of module owners, who take possession of bugs, and send them on to the people best suited to fixing them. These people wouldn't even need to be technical, they'd just be required to do a first-level filter (invalid or nogabug or needinfo bugs) and send the real bugs to the people most likely to fix them.

Proposal 3 is to try to persuade the Win32 guys to come back to the main gimp mailing list. 1.3 should be buildable out of CVS, but I have not been able to find anyone who's actually done it using free build tools. Personally I failed miserably somewhere around pango. Our biggest user base is win32 users, so that's probably our biggest source for future developpers, documenters, ui designers. We should be listening to them, and they should be listening to us.

Proposal 4 is to set up a proper partnership between the gug and www.gimp.org. The gug is the best gimp resource on the web, which is what gimp.org should be. I know that carol's done a huge amount of work on the new site, and she's found it difficult to get content for it from people. I know as well that Raphael's spent a lot of time on the old site, and that the web team's been shrinking on him for years. The GUG site is a huge resource of content that we should be tapping into.

What form that partnership would take, and how to go about getting them involved, I don't know. Sorry - this is mainly questions, not answers :)

Proposal 5 is related to proposal 2. We need a structure. A neck to grab. I would like to propose setting up a sub-group of module owners. Mostly this would be people who have the definitive word on what goes into a module. This group of people would be intimate with the code, and be able to evaluate patches. There would also be a module owner for the website, and a module owner for UI (that is, interface issues). In the case of arguments on the (one) mailing list, the module owner trumps. So a sense of politics would be useful :)

This group would be responsible for module administration in bugzilla (assigning ownership of the module to a minion) and would be the steering committee for the project as a whole, as well as being the arbiters of CVS permissions.

Proposal 6 - allow people to submit bug reports without a bugzilla account. I would like it if Bugzilla could get their email address from the first mail they send to the portal, sign them up and send them a password, but it doesn't. As a technical problem, is this possible? Or could we have a mail alias to which mails (which pass a spam filter) get converted into bugzilla reports, with the e-mail information in the body of the bug report?

I think this is important to allow people see a more reactive gimp community. A current typical use-case might be "gimp crashes, restart gimp", or it might be "gimp crashes, go to gimp web page, nothing about bugs on the first page, restart gimp", or it might be "gimp crashes, go to gimp web page, nothing about bugs on first page, scroll down 4 pages, follow "Submit a bug!" link, there's a page asking for me to enter my e-mail address, restart gimp". I don't believe that the typical gimp user gets a bugzilla account when he runs into a gimp problem.

OK - so that's it. Food for thought. Basically, since 1.2 the size of the gimp community has been shrinking. We don't have any documenters, we don't have many testers, we don't have many bug fixers, we have very few web developers, we have a couple of artists, and we have maybe a dozen active developers. Something needs to be done to change that, or the gimp will never see a major release with gegl (whatever version number it will have).

Cheers, Dave.

On Fri, Jul 18, 2003 at 09:59:22PM +0200, Sven Neumann wrote:

decision. We came to the point that it should be called 2.0. It's just a number, so please, before you start the discussion again, think twice if it's worth it.

It's not just a number, it is also used in the sources of external plug-ins. (e.g. AM_GIMP_2_0)... this is increased maintainance hassle, again for little gain.

Thanks, however, for making it clear that you decided it, instead of just letting the discussion die.

On Sat, Jul 19, 2003 at 12:10:54AM +0200, Sven Neumann wrote:

Gimp is more than "Mitch and me," isn't it?

Yes it is. And if you are really willing to continue this sinless discussion instead of helping us to get the release done, we can of

This is *extremely* unfair. _You_ are proposing a rather big version change, and your only argument is soemthing like "I told soma magazine"....

Now claiming that Nathan isn't helping is rather strange.

the basic CMYK supoprt finished that we started to work on). I really don't see your point. I am trying hard but I cannot see the lie you are talking about in big bold letters. I'm sorry but I don't have any

Well, a lot of people (you can see that by looking at the "vote") disagree. Given that it's "just a number", you are extremely insisting...

ago. This is just ridiculous, especially for a free software project that people work on in their free time.

What is ridiculous is the unexplainable insistence on that change when so many people feel bad about it?

On 07/19/03 13:10, Carol Spears wrote:

I also will not write any English documentation until I can afford to buy that book that explains the English rules about hyphens.

I'm not sure what book or what hyphens you are talking about, but the Elements of Style is in the public domain. Here are some links for you:

http://www.bartleby.com/141/ specifically
http://www.bartleby.com/141/strunk.html#8 http://www.cs.vu.nl/~jms/doc/elos.pdf

There are other resouces available on the web.

http://owl.english.purdue.edu/handouts/grammar/g_hyphen.html http://lingua.kie.utu.fi/dbergen/AAW/Lesson%205/punctuation1.htm etc.

I would think that any "poorly done" english documentation is better than none, and people might help to fix documentation more than they would strive to write it. Getting started is always hardest...

regards, Chris

On 07/19/03 13:10, Carol Spears wrote:

I also will not write any English documentation until I can afford to buy that book that explains the English rules about hyphens.

Also, I'm not heard of this, but it sounds like it may pertain more to British English (I'm under the impression that Elements of Style is an American made thing):

http://www.bartleby.com/116/

It's called "The King's English" by H. W. Forler. It also has a section on hyphens:

http://www.bartleby.com/116/405.html

regards again, Chris

On 19 Jul 2003 at 22:13, David Neary wrote:

[...]

Those are the problems at the philosophical level. At the practical level, the problems are:

1) Not enough users use bugzilla to report bugs

Bugzilla is powerful, but its power comes at the price of complexity...

2) Not enough developers use Bugzilla to find out what bugs need fixing
3) Not enough developers hear user complaints

Most bug reports I've read are commented by at least one person who I'd consider to be one of the developers. This might be incorrect, maybe because in my opinion, developing isn't just coding.

4) Not enough users know what's happenning in the developer series.

Tried to change this using gimp.de. As this is a german language portal site, it is known (at least I hope it is at all) mainly in german speaking countries. It's limited to the eye-catching features, i.e. new (ui) functions or performace improvments (like the recent mmx enhancements).

5) Not enough non-technical people are working on the GIMP (this is at odds with when I joined, when many of the most active GIMP people were non-technical).

In my opinion, it's not clearly defined what they can do. The most common answer is "write documentation", but this seems to requires cvs access or someone who will coordinate the whole thing. Maybe wiki.gimp.org can help here, though it's purpose is still somewhat undecided.

That's the practical level. Now, here's why I think these problems exist.

1) Too many communication interfaces, not enough communication.

The GIMP has the following communication methods available to it:

- Website - www.gimp.org - Website - mmmaybe.gimp.org
- Website - gug.sunsite.dk

mmmaybe.gimp.org should replace www.gimp.org, so this should clear sooner or later. gug.sunsite.dk isn't under direct control of the gimp community, at least that's that's my impression.

- IRC - irc.gnome.org

This is the fastest way to get support - even interactive - from the community, so it isn't redundant at all.

- Usenet - comp.graphics.apps.gimp

Usenet is some peoples medium of choice, too.

- Mailing list - gimp-users@lists.xcf.berkeley.org - Mailing list - gimp-developers@lists.xcf.berkeley.org - Mailing list - gimp-web@lists.xcf.berkeley.org - Mailing list - gimpwin-dev@yahoogroups.com

gimpwin-dev is no more, it was closed and everyone was asked to use gimp- developer instead

- Mailing list - gimpwin-users@yahoogroups.com - Mail alias - bugs@gimp.org

- Bugzilla - bugzilla.gnome.org
- CVS - cvs.gnome.org
- Release notes.

There's definite consolidation to be done there. That's 13 ways to get information. And 13 ways to send it. I listen personally to about 3 of those... bugs@g.o, Usenet and the devel list.

I'm using at least six of them - 3 lists, usenet, irc, bugzilla.
[...]

My first proposal would be to do a reverse split of the users and developers mailing lists - get everyone talking to one another. It will certainly annoy people because of increased traffic, but I think it'll be worth it. We have to face up to the fact that after 3 years without a major release, and only 14 active developers, the GIMP is a small project. Step 1 is to get people talking to each other.

Well, whenever something got to technical on gimpwin-users, some of the users did unsubscribe. However, in most of the cases, it was far less technical than anything on gimp-developer, so there may be some problems here. Readers of gimp- user may be a bit more interested in this than the average win32 user, though.

Proposal 3 is to try to persuade the Win32 guys to come back to the main gimp mailing list. 1.3 should be buildable out of CVS, but I have not been able to find anyone who's actually done it using free build tools. Personally I failed miserably somewhere around pango.

According to Tor Lillqvist, there was something missing from Pango 1.2.3 and fixed shortly after the release. Maybe a thread about building GIMP 1.3.16 on Win32 should be started here, I'm willing to contribute everything I've encountered while trying to do so.

Our biggest user base is win32 users, so that's probably our biggest source for future developpers, documenters, ui designers. We should be listening to them, and they should be listening to us.

Yep. Though listening to them is a bit hard sometimes. Most of the problems are some kind of "gimp is broken". Often, it turns out to be something completely different. And of course, you'll have to mute all those 'use a REAL os' - posts from the mailing list then. They aren't providing solutions, they are annoying users ;)

[...]

Proposal 6 - allow people to submit bug reports without a bugzilla account. I would like it if Bugzilla could get their email address from the first mail they send to the portal, sign them up and send them a password, but it doesn't. As a technical problem, is this possible? Or could we have a mail alias to which mails (which pass a spam filter) get converted into bugzilla reports, with the e-mail information in the body of the bug report?

Quantity will increase, quality will decrease by allowing this. Get someone who sorts this out first, then implement it.

I think this is important to allow people see a more reactive gimp community. A current typical use-case might be "gimp crashes, restart gimp", or it might be "gimp crashes, go to gimp web page, nothing about bugs on the first page, restart gimp", or it might be "gimp crashes, go to gimp web page, nothing about bugs on first page, scroll down 4 pages, follow "Submit a bug!" link, there's a page asking for me to enter my e-mail address, restart gimp". I don't believe that the typical gimp user gets a bugzilla account when he runs into a gimp problem.

That's something the typical user is searching on a support page. I suggested adding a "Support" link to mgo, but was have been convinced that this may be mistaken for a support hotline or something like that (in *.de, normally something like a faq or knowledgebase and downloads for hotfixes and tools is hidden behind such a link).

Maybe something like "Support" -> "How we can help you (Tutorials, Docs, ...)", "How you can help us (Development, Docs, ...)"?

HTH, Michael

Christopher W. Curtis wrote:

On 07/19/03 13:10, Carol Spears wrote:

I also will not write any English documentation until I can afford to buy that book that explains the English rules about hyphens.

Also, I'm not heard of this, but it sounds like it may pertain more to British English (I'm under the impression that Elements of Style is an American made thing):

http://www.bartleby.com/116/

It's called "The King's English" by H. W. Forler. It also has a section on hyphens:

http://www.bartleby.com/116/405.html

hi!

Thanks for this information. Unfortunately, I think that writing documentation in any form of English is better left to the handful of people who are very good at it.

My problems with the hyphen being used like it is is simply that I feel I want to be very careful with it when dealing with xml namespaces, and also be certain it is used properly in any case where the locale is "en" or some form of this. It is really not my area of expertise, and I seriously doubt I will ever gain any expertise in English.

Having the ./gimp-1.3/plug-ins is problematic to me. The rest of gimp names use hyphens as wisely as you can expect, but not this one area.

I should warn everyone also, I dreamed that i renamed the plugins and this caused everything in my life to get much easier to deal with ....

I was hoping for more dtd help than English help. I hate the rules for the spoken and written languages. This xml is refreshing as it is fairly clear cut about a lot of the crap.

Mr Curtis, you seem to be quick with the English rules, perhaps you would like to help edit gimp documentation as it comes in.

Our last English expert was hired and is busy with a time consumeing translation job.

carol

Michael Schumacher wrote:

On 19 Jul 2003 at 22:13, David Neary wrote:

[...]

Those are the problems at the philosophical level. At the practical level, the problems are:

1) Not enough users use bugzilla to report bugs

Bugzilla is powerful, but its power comes at the price of complexity...

2) Not enough developers use Bugzilla to find out what bugs need fixing
3) Not enough developers hear user complaints

Most bug reports I've read are commented by at least one person who I'd consider to be one of the developers. This might be incorrect, maybe because in my opinion, developing isn't just coding.

4) Not enough users know what's happenning in the developer series.

Tried to change this using gimp.de. As this is a german language portal site, it is known (at least I hope it is at all) mainly in german speaking countries. It's limited to the eye-catching features, i.e. new (ui) functions or performace improvments (like the recent mmx enhancements).

5) Not enough non-technical people are working on the GIMP (this is at odds with when I joined, when many of the most active GIMP people were non-technical).

In my opinion, it's not clearly defined what they can do. The most common answer is "write documentation", but this seems to requires cvs access or someone who will coordinate the whole thing. Maybe wiki.gimp.org can help here, though it's purpose is still somewhat undecided.

That's the practical level. Now, here's why I think these problems exist.

1) Too many communication interfaces, not enough communication.

The GIMP has the following communication methods available to it:

- Website - www.gimp.org - Website - mmmaybe.gimp.org
- Website - gug.sunsite.dk

mmmaybe.gimp.org should replace www.gimp.org, so this should clear sooner or later. gug.sunsite.dk isn't under direct control of the gimp community, at least that's that's my impression.

- IRC - irc.gnome.org

This is the fastest way to get support - even interactive - from the community, so it isn't redundant at all.

- Usenet - comp.graphics.apps.gimp

Usenet is some peoples medium of choice, too.

- Mailing list - gimp-users@lists.xcf.berkeley.org - Mailing list - gimp-developers@lists.xcf.berkeley.org - Mailing list - gimp-web@lists.xcf.berkeley.org - Mailing list - gimpwin-dev@yahoogroups.com

gimpwin-dev is no more, it was closed and everyone was asked to use gimp- developer instead

- Mailing list - gimpwin-users@yahoogroups.com - Mail alias - bugs@gimp.org

- Bugzilla - bugzilla.gnome.org
- CVS - cvs.gnome.org
- Release notes.

There's definite consolidation to be done there. That's 13 ways to get information. And 13 ways to send it. I listen personally to about 3 of those... bugs@g.o, Usenet and the devel list.

I'm using at least six of them - 3 lists, usenet, irc, bugzilla.

[...]

My first proposal would be to do a reverse split of the users and developers mailing lists - get everyone talking to one another. It will certainly annoy people because of increased traffic, but I think it'll be worth it. We have to face up to the fact that after 3 years without a major release, and only 14 active developers, the GIMP is a small project. Step 1 is to get people talking to each other.

Well, whenever something got to technical on gimpwin-users, some of the users did unsubscribe. However, in most of the cases, it was far less technical than anything on gimp-developer, so there may be some problems here. Readers of gimp- user may be a bit more interested in this than the average win32 user, though.

Proposal 3 is to try to persuade the Win32 guys to come back to the main gimp mailing list. 1.3 should be buildable out of CVS, but I have not been able to find anyone who's actually done it using free build tools. Personally I failed miserably somewhere around pango.

According to Tor Lillqvist, there was something missing from Pango 1.2.3 and fixed shortly after the release. Maybe a thread about building GIMP 1.3.16 on Win32 should be started here, I'm willing to contribute everything I've encountered while trying to do so.

Our biggest user base is win32 users, so that's probably our biggest source for future developpers, documenters, ui designers. We should be listening to them, and they should be listening to us.

Yep. Though listening to them is a bit hard sometimes. Most of the problems are some kind of "gimp is broken". Often, it turns out to be something completely different. And of course, you'll have to mute all those 'use a REAL os' - posts from the mailing list then. They aren't providing solutions, they are annoying users ;)

[...]

Proposal 6 - allow people to submit bug reports without a bugzilla account. I would like it if Bugzilla could get their email address from the first mail they send to the portal, sign them up and send them a password, but it doesn't. As a technical problem, is this possible? Or could we have a mail alias to which mails (which pass a spam filter) get converted into bugzilla reports, with the e-mail information in the body of the bug report?

Quantity will increase, quality will decrease by allowing this. Get someone who sorts this out first, then implement it.

I think this is important to allow people see a more reactive gimp community. A current typical use-case might be "gimp crashes, restart gimp", or it might be "gimp crashes, go to gimp web page, nothing about bugs on the first page, restart gimp", or it might be "gimp crashes, go to gimp web page, nothing about bugs on first page, scroll down 4 pages, follow "Submit a bug!" link, there's a page asking for me to enter my e-mail address, restart gimp". I don't believe that the typical gimp user gets a bugzilla account when he runs into a gimp problem.

That's something the typical user is searching on a support page. I suggested adding a "Support" link to mgo, but was have been convinced that this may be mistaken for a support hotline or something like that (in *.de, normally something like a faq or knowledgebase and downloads for hotfixes and tools is hidden behind such a link).

Maybe something like "Support" -> "How we can help you (Tutorials, Docs, ...)", "How you can help us (Development, Docs, ...)"?

This had been my hope for the wiki. Although, I think back and I don't know if I would not be too shy to start on something like a wiki. I remember mostly being a gimp lover and feeling too stupid to want to bother the developers too much.

I had hoped that developers would outline their ideas there. I remember waiting for mail to be answered and such, I think it would be much more fun to watch the idea taking form on the wiki.

Should be easy to work that thing into a message board type thing like GUG used to have. A year or so after the GUG site is broken and unrepaired, I read that the message board and galleries are missed. This can all occur on the wiki.

It will take some handy people to set it up and it will take some brave users and perhaps even braver developers to outline their ideas there, on the wiki. Mr. Schumacher and I have already been discussing the stylesheets.

I think it would be cool if the wiki could reflect the current splash in the development gimp. It would just take some smart color grabbing by gimp or artist with opinions on web page colors to go with the image.

I would like web pages to show off the gimp logo scripts and maybe free good fonts to go with them, if we can work with some of the poor free font guys and a handful of licenses. Some of the artsy fartsy designers on that use the gimp and love to show off could start on this sort of stuff now.

As much as I hate flash usually on the web, I think gimp needs a flash plugin and some flash demos. Also, I am trying to build a resume block into my gimp dtd so you can advertise yourself there.

Heh, I guess i should stop typing mindlessly to a weird developers list and put my ideas on the wiki. I still don't believe that me or my mail belongs *here*.

I am putting the dtd and the plugin.xml on the wiki. If anyone would like to play with me there, please feel invited.

carol

Hi Sven,

On Saturday 19 July 2003 7:48 am,

I'm working on it; I've got 1.3.16 installed and working, and it doesn't look as though the relevant code has changed too much (just been moved a bit).

It would be really nice to get a patch against 1.3.16.

A patch against 1.3.16 is now attached to bug 97777.

The patch adds a new dither parameter to gimp_drawable_blend(), and to the gimp-blend pdb function, so the patch also updates the Script-Fu scripts to use the new parameter.

All the best,

Michael Schumacher wrote:

2) Not enough developers use Bugzilla to find out what bugs need fixing
3) Not enough developers hear user complaints

Most bug reports I've read are commented by at least one person who I'd consider to be one of the developers.

Personally there's no WAY I have time to trawl bugzilla looking for bugs in 'my' parts of GIMP, and I suspect that most other developers are the same. But when someone who knows CC:s me I try to take an interest.

Bugzilla is good, but maybe the bugs aren't reaching the right developer with a good hit rate.

--Adam

Christopher W. Curtis wrote:

On 07/19/03 13:10, Carol Spears wrote:

I also will not write any English documentation until I can afford to buy that book that explains the English rules about hyphens.

I'm not sure what book or what hyphens you are talking about, but the Elements of Style is in the public domain.

Just to explain, this is about whether applications which use the libgimp API to furnish services to the main GIMP app should be called plug-ins or plugins. Old story - I believe bex insisted on plug-ins, and eventually won people over - carol prefers plugins.

Cheers, Dave.

Carol Spears wrote:
> As much as I hate flash usually on the web, I think gimp needs > a flash plugin and some flash demos.

For what purpose? Could you elucidate?

David Neary wrote:

Just to explain, this is about whether applications which use the libgimp API to furnish services to the main GIMP app should be called plug-ins or plugins. Old story - I believe bex insisted on plug-ins, and eventually won people over - carol prefers plugins.

'Plugins' is definitely wrong from a language point of view -- but it also seems to me to be more eye and finger friendly than 'plug-ins', and I think we can take it as de facto in the age of 'email' without being beheaded for treason against the Language of the Empire, or something. omg i mean it dont compare to most of what u see on the net lololol

I don't think that the issue is worth holding up any documentation for. :)

--Adam

On 07/20/03 06:49, Sven Neumann wrote:

A few people expressed that they dislike the version number, other liked it. We went through all the arguments a few times and finally decided that we want to go for 2.0.

Firstly, I have no control over the version number and there's no point arguing with a wall - I simply did this for my own sanity. I went through the list archives, and have tallied what people publicly 'decided' should be the next version. Here is the list:

[1] david gowers [implicit] 1.4 [2] Marc A. Lehmann [start of subject] 1.4 [3,4] Raphaël Quinet 1.4
[5] Guillermo S. Romero 1.6 or 1.8 [6] Michael J. Hammel 1.4
-
[7] Tino Schwarze 1.4
[8] Sven Neumann 2.0
[9] Branko Collin 1.6 or 1.8
[10] Christopher W. Curtis 1.5
[11] Shlomi Fish 1.4
-
[12] Robert L Krawitz not-2.0
[13] Owen [sqrt(2)] 1.4[142...]
[14] Patrick McFarlan not-2.0
[15] David Neary 2.0
[16] Henrik Brix Andersen 2.0
-
[17] Adam D. Moss 8.0
[18] Steinar H. Gunderson 1.4
[19] Nathan Carl Summers 1.4
[20] Jakub Steiner 1.4
[21] Daniel Egger 1.4
-
[22] Marco Wessel XP
[23] Joao S. O. Bueno 1.4
[24] wolfgang 1.4
[24] Carol Spears 1.4

Since this isn't a vote, I'm not tallying any numbers, and there may be 20,000 people all saying they want 2.0 in the July archives; however, these are not yet online so I can't scan them.

Chris

References: [1]http://lists.xcf.berkeley.edu/lists/gimp-developer/2003-June/008711.html [2]http://lists.xcf.berkeley.edu/lists/gimp-developer/2003-June/008713.html [3]http://lists.xcf.berkeley.edu/lists/gimp-developer/2003-June/008800.html [4]http://lists.xcf.berkeley.edu/lists/gimp-developer/2003-June/008769.html [5]http://lists.xcf.berkeley.edu/lists/gimp-developer/2003-June/008715.html [6]http://lists.xcf.berkeley.edu/lists/gimp-developer/2003-June/008716.html [7]http://lists.xcf.berkeley.edu/lists/gimp-developer/2003-June/008719.html [8]http://lists.xcf.berkeley.edu/lists/gimp-developer/2003-June/008728.html [9]http://lists.xcf.berkeley.edu/lists/gimp-developer/2003-June/008745.html [10]http://lists.xcf.berkeley.edu/lists/gimp-developer/2003-June/008806.html [11]http://lists.xcf.berkeley.edu/lists/gimp-developer/2003-June/008808.html [12]http://lists.xcf.berkeley.edu/lists/gimp-developer/2003-June/008749.html [13]http://lists.xcf.berkeley.edu/lists/gimp-developer/2003-June/008737.html [14]http://lists.xcf.berkeley.edu/lists/gimp-developer/2003-June/008750.html [15]http://lists.xcf.berkeley.edu/lists/gimp-developer/2003-June/008759.html [16]http://lists.xcf.berkeley.edu/lists/gimp-developer/2003-June/008827.html [17]http://lists.xcf.berkeley.edu/lists/gimp-developer/2003-June/008828.html [18]http://lists.xcf.berkeley.edu/lists/gimp-developer/2003-June/008760.html [19]http://lists.xcf.berkeley.edu/lists/gimp-developer/2003-June/008761.html [20]http://lists.xcf.berkeley.edu/lists/gimp-developer/2003-June/008762.html [21]http://lists.xcf.berkeley.edu/lists/gimp-developer/2003-June/008832.html [22]http://lists.xcf.berkeley.edu/lists/gimp-developer/2003-June/008768.html [23]http://lists.xcf.berkeley.edu/lists/gimp-developer/2003-June/008776.html [24]http://lists.xcf.berkeley.edu/lists/gimp-developer/2003-June/008785.html

On 07/19/03 20:56, Carol Spears wrote:

Having the ./gimp-1.3/plug-ins is problematic to me. The rest of gimp names use hyphens as wisely as you can expect, but not this one area.

Aha ... well, doing a quick search with 'dict,' it knows about "plug-in" and refers "plugin" to "plug-in" automagically, However, being a lazy or ignorant American (pick one only, please) I say "plugin".

Mr Curtis, you seem to be quick with the English rules, perhaps you would like to help edit gimp documentation as it comes in.

Sadly I have led you astray; however, I would be more than happy and reasonably willing to proof incoming documentation. I sent a couple [minor] patches/suggestions to the GUM authors before it went final.

Chris

Hi,

Sven Neumann wrote:

Your mail really confused me as I don't seem to be able to follow most of the points you brought up. Dave, is that really you who wrote this??

First off, let me assure you that it was me :)

Right up front I said:

David Neary writes:

The problems as I see them are...

That was intended to emphasise that this is my take on things, and is, as with everything I say, open to discussion and quite possibly wrong.

I will try to clear up some of your confusion for you :)

1) User feedback on the development series is poor 2) Documentation is poor
3) Our release cycle is poor
4) UI is not a priority.

I am very surprised about point (4). We have put a lot of effort into improving the user interface. I would even go so far to say that UI has the highest priority.

From my perspective, I've seen discussions in recent months on modifying shortcuts to conform with the HIG, reduce the complexity of the install process, setting the menu on the image windows on by default, and on and on. There have been 4 or 5 of these arguments and in every case your position has been to stick with the status quo. People have said to you "users find this too complex. I find this too complex." and your answer has been "Some people find it useful".

I hope that you don't think I'm picking on you here - Raphael has also tended to favour the status quo in usability bugs on bugzilla. One question that springs to mind from what you say above is who is "we"? I've not been involved in many UI discussions, although I have made a first contact with usability@gnome.org, and hope to have a mail sometime this week requesting screenshots for usability evaluation...

Also I have to disagree with point (1). There is substantial user feedback on the development series. You probably don't read the gimp-user mailing list and don't follow the discussion on various public forums whenever a release is done. Other developers seem to do that and all this feedback is going back into the development. I really don't see your point.

Up until quite recently (that is, during the first 2 years of 1.3 development) anyone who wanted to open a bugzilla report against 1.3 was told they couldn't - that the series was unstable, full stop. So up until quite recently, there wasn't any way for users to give feedback in terms of bug reports. Also as you may have noticed, the devel list has gotten very quiet recently (well, until you proposed that the next version be called 2.0 - that might actually have been a good move :).

As you say, I am not subscribed to the user list. Perhaps I should be. I suspect I'm not alone in not subscribing. But the idea of the separation of lists was that I didn't have to be. Perhaps that day is gone, and I should just subscribe to the user list and be done with it. In this case, if all the developers are subscribed to the user list, why would we need a devel list?

1) Not enough users use bugzilla to report bugs

Bugzilla is the only way to report bugs. Whooever reports bugs uses Bugzilla for it. A few people need to be shown the way to it but in the end everyone uses Bugzilla.

Bugzilla is a quite complicated tool. I love it. As you say, anyone who reports bugs uses bugzilla. That means we miss lots of bugs.

2) Not enough developers use Bugzilla to find out what bugs need fixing
3) Not enough developers hear user complaints

I believe that all active developers use Bugzilla. Mitch and me spend a substantial amount of time with Bugzilla and I have the impression that other developers do the same.

"Use bugzilla" != "add occasional comments to bugs and maybe fix a few". As I'm sure you've noticed, 90% of comments on open gimp bugs are from either yourself or Raphael.

A quick trawl of bugzilla shows that there are 182 bugs with comments from Mitch in the last 6 months, compared to 691 from yourself, 479 from Raphael, and in the region of 80 for me (because I changed emails in the last 6 months of my bugzilla account it's a bit hard to figure out).

This just to show that like in terms of code contributed, where there's a huge gap between yourself and mitch vs the rest of us, in bugzilla it's yourself & Raphael vs the rest of us (I suspect this is because we use bugzilla wrong).

- Mail alias - bugs@gimp.org

This one is dead, noone is using it. It's only used for syndicating Bugzilla changes.

Not no-one is using it. I use it to do a quick filter on bugs I might find interesting. I delete 99% of the mails as they arrive. I actually use this more than bugzilla (where "using bugzilla" means getting ownership of bugs, and fixing them or passing on ownership to someone else).

My first proposal would be to do a reverse split of the users and developers mailing lists - get everyone talking to one another. It will certainly annoy people because of increased traffic, but I think it'll be worth it. We have to face up to the fact that after 3 years without a major release, and only 14 active developers, the GIMP is a small project. Step 1 is to get people talking to each other.

This might be a good idea but I am afraid that it will have a negative effect. I fear that users will stop subscribing to the list because there is too much technological discussion and I fear that developers will be annoyed by too much ever-repeating newbie questions.

Perhaps the annoyance will manifest itself in the new FAQ that people (including myself) intended writing a year ago? And the devel list's been so quiet recently that the tech discussions probably wouldn't be noticed. But if they are, maybe we'll start getting contributions from people who want to help again...

Proposal 2 is to either do away with bugs@gimp.org or de-spam it.

We need bugs@gimp.org. Despamming it is of course a good idea and I wonder why Yosh has disabled the spam-filter again. Getting rid of bugs@gimp.org as a syndication of changes to Bugzilla is definitely a very bad idea. It would cause unseen changes to bugs and new bug-reports being ignored.

Yet again, would you mind saying who is "we"? And if we used bugzilla properly, there would be no missed bugs... I hate to insist on this, clearly I'll need to explain it a bit more (will do, below).

Have a look at the stats, there are no new bugs floating around. Usually bug-reports get answered in less than 24 hours. We trimmed down the number of open bugs to a half during the last year. If there is some success story in GIMP development, then it's Bugzilla. The main cause for this is the fact that developers get mail from Bugzilla whenever a new bug is reported or a report is changed.

Right ideal opportunity to explain how bugzilla *should* work. Let's look at the currently open gimp bugs - there are, in total, 391 bugs. Which is, as you point out, doiwn from over 600 at one point. I even had a little bit to do with that, I think...

Now, let's look at the "Owner" field - 1 bug is owned by grosgood, one by jimmac, 2 by mitch, 2 by Raphael, 2 by rockwlrs, and 1 each for sven and yosh. That's 10. Leaving 381 bugs owned by that well-known gimp developer bugs@gimp.org.

The lifecycle of a bug *should* be that a bug gets reported against a module, which is owned by the module owner, who knows who works on what parts of that module (for example, a bug against the plug-ins module would land in the mailbox of someone who knew that adam owns the psd plug-in, but that myself or Maurits might be interested). This person doesn't need to be technical, they need to be good enough to screen out the NEEDINFOs, the NOTABUGs, the INVALIDs. Otherwise their job is to turn unconfirmeds into news, and to pass the bug on to the person (or group of people) interested.

At this point, the person to whom the bug has been assigned either accepts the bug (effectively agreeing to fix it), or re-assigns the bug to someone else. When the bug is fixed, it is reassigned to the original reporter for verification and eventually closure.

That is what is supposed to happen in bugzilla. What actually happens is kind of similar, in a haphasard way. Usually a bug in one of the file format bugs gets adam's email stuck onto it by someone, and he ends up having a look. Or I notice a keyword in a mail I get at bugs@g.o that might be related to a bugfiw I botched up. And so on.

I would prefer to set up a system of module owners, who take possession of bugs, and send them on to the people best suited to fixing them. These people wouldn't even need to be technical, they'd just be required to do a first-level filter (invalid or notabug or needinfo bugs) and send the real bugs to the people most likely to fix them.

Of course a good idea in theory but facing the fact that there are only very few active developers, it doesn't seem to be doable. If you can hire a team of 5 QA persons for this job, I'd vote for your proposal.

I'm glad you agree there's a problem with the number of people active in gimp development. As I've said a couple of times, the module owners don't need to know how to fix the bugs. This seems to me like a great way to get people involved in the gimp. I know that fixing bugs was how I got involved... I just started browsing bugzilla, picked one that looked fairly easy, and attacked. So maybe there are 5 people who aren't too confident diving into the core, and would like to feel their way around with bug reports?

Proposal 3 is to try to persuade the Win32 guys to come back to the main gimp mailing list. 1.3 should be buildable out of CVS.

This has happened, the win32 development is discontinued and subscribers have been asked to join gimp-developer and/or gtk+-devel instead.

And yet I can't remember the last time I saw a mail from Hans or Tor. And I know that they had gathered a group of Win32 people, none of whom seem to have appeared on this list. And I have yet to see a screenshot of the GIMP 1.3 running on Win32 (except via an XServer, which I've done :).

Proposal 6 - allow people to submit bug reports without a bugzilla account. I would like it if Bugzilla could get their email address from the first mail they send to the portal, sign them up and send them a password, but it doesn't. As a technical problem, is this possible? Or could we have a mail alias to which mails (which pass a spam filter) get converted into bugzilla reports, with the e-mail information in the body of the bug report?

This would mean more bug-reports without a working email address of the bug reporter. IMO a very bad idea since experience shows that these bug reports cause a lot of work and often need to be closed as INCOMPLETE or INVALID in the end.

What's wrong with using the From: or the Reply-to: addresses?

be "gimp crashes, go to gimp web page, nothing about bugs on first page, scroll down 4 pages, follow "Submit a bug!" link,

There is info about bugs on the first page of www.gimp.org. I don't know what you are talking about.

Screenshot: http://bolsh.dyndns.org/~dave/Screenshot.png

Where do you see any mention of bugs, or support, or anything a user might be tempted to follow in the event of a problem?

I thought the mention of scrolling above made it clear what I meant...

OK - so that's it. Food for thought. Basically, since 1.2 the size of the gimp community has been shrinking. We don't have any documenters, we don't have many testers, we don't have many bug fixers, we have very few web developers, we have a couple of artists, and we have maybe a dozen active developers. Something needs to be done to change that, or the gimp will never see a major release with gegl (whatever version number it will have).

Your mail really confused me as I don't seem to be able to follow most of the points you brought up. Dave, is that really you who wrote this??

It doesn't surprise me much that your take on this is different to mine. I hope you don't take offense at this, but while you're a great developer, no-one could ever accuse you of being a good politician :)

Part of the idea behind this is to establish some kind of structure to how we use the tool available to us in a manner which makes it easier for people to contribute to the gimp. As you already contribute immensely to the gimp, I wouldn't expect you to see any problems with the way things are. But when I spend more of my free time building the gimp or installing dependencies than I actually spend coding, I consider that a problem.

Part of the problem is communication. In the past 3 years, there have been numerous surprises after doing a cvs up - sometimes it's a version jump in automake, there was the version jump in gtk+, then there was fontconfig, there was the disappearing toolbox way back when, then the reintroduction of the mmx stuff, and so on - at various moments during the development of 1.3, people's build environments have been broken overnight with no mail to say it was going to happen, or why. I remember a big argument about whether the 1.3 version of GTK+ was really necessary - in my opinion that jump was badly managed, and probably resulted in a half dozen people stopping building cvs gimp.

But it also goes the other way - I remember arguments over plug-in tools and mmx in particular, but there have been a few occasions where people have submitted stuff to the gimp which has subsequently been backed out. This is not to say that the decision to back stuff out was necessarily bad, but if I remember them it's because they were badly handled.

I'm sure that you've personally been frustrated by the lack of help that's been around for yourself & mitch. But the reason there's been a lack of help is because the people who are likely to help are so often opposed when they propose stuff.

My idea is to discuss a change in how the gimp project runs itself. The changes would include spreading around the responsibility for things like bugzilla in a more official way - someone would be In Charge of the plug-in bugs, someone else would be In Charge of the UI bugs, and so on.

To me the benefits of these types of changes are self-evident - they partition up things to be done into bite-sized tasks, allowing people who have a couple of hours a week free (like me) to be of benefit to the project in a more targetted way. They give us a chance to start rebuilding the kind of community we had when I started working on the gimp. They take a bunch of work away from yourself and mitch, and spread it around.

They also allow people who want to contribute to the gimp to do so more easily. Getting the gimp developpers and the users talking with the intention of having a better gimp, and a better community, is a good thing. We need to spread responsibility around, and that includes responsibility to decide what does & does not go into CVS.

Hopefully this will develop a bit more and people's positions can be cleared up before camp, I would like to spend some time at the camp discussing these types of issues (communication, and distribution of responsibility). Of course, if we can all agree before camp, great. More time for beer.

Cheers, Dave.

At 19:40 20.07.03 +0200, David Neary wrote:

[...] And I have yet
to see a screenshot of the GIMP 1.3 running on Win32 (except via an XServer, which I've done :).

Here it comes
http://hans.breuer.org/gimp/gimp-1.3-2003-06-21.png

_but_ it is using a modified Pango see http://bugzilla.gnome.org/show_bug.cgi?id=94791

and a modified Gimp http://bugzilla.gnome.org/show_bug.cgi?id=113681

with patches which apparently will never be accepted, though one of the bugs is only relied to 'future' ...

Hans -------- Hans "at" Breuer "dot" Org ----------- Tell me what you need, and I'll tell you how to get along without it. -- Dilbert

Am Son, 2003-07-20 um 13.36 schrieb Sven Neumann:

You're quoting out of context without replying to me; if you prefer to get an answer you'd better fix that because I might miss a mail in the floods at times.

What exactly is the problem with the help-browser in 1.3? I know that there are issues with the URL combo widget but apart from that it should work fine. Is there a problem we don't know about? Perhaps someone should file a bug-report then.

The problem is the mapping of content to context, the system is still based on the 1.2 help which won't get us very far except with the 1.2 help.

Hi Sven,

On Sunday 20 July 2003 11:44 am, Sven Neumann wrote:

The CVS version does include some naive RGB CMYK conversion routines and it has a CMYK color selector. What is still missing is support for loading and saving CMYK files. I would like to add this capability to a couple of file plug-ins such as TIFF. This doesn't mean that GIMP could work in CMYK but at least it would allow you to select colors by their CMYK values and to convert to CMYK when saving. A couple of users have told me that this functionality would dramatically improve the usefulness of GIMP for them and since it's such a simple change, we decided to give it a try.

Sounds like a good start. If you want to investigate better RGB CMYK conversion, then the littlecms library is a good choice to do the heavy lifting; it can do accurate conversions between colour spaces defined by ICC profiles.

A default conversion from sRGB to SWOP-Coated seems to be the combination most houses use when no "proper" profiles are available, and will generally give considerably better results than a [c,m,y]=1-[r,g,b] type algorithm...

Could you send me (or the list) a copy of this plug-in? I am particularily interested in the CMYK loading and saving routines.

I've made it available for download from my website, at http://www.blackfiveservices.co.uk/projects/separate-0.1.tar.gz

As it stands it compiles and works under 1.2 (Linux and Win32 - I use it at work on a windowbox). I've nearly got it working under 1.3 - it'll do the separations themselves - but my filename-building routines need an overhaul for glib-2.0; they currently segfault...

The plugin itself uses littlecms to do the hard work, and can either place the separated channels in individual grey layers, or solid colour layers in "darken only" mode, with the data in the layer masks.

The plugin can't yet load CMYK images, but it can save them...

All the best,

Hi Sven,

On Monday 21 July 2003 1:43 am, Sven Neumann wrote:

I would like to postpone this until after the release. However we should probably add a dummy pointer to the conversion functions now so that we can use it for passing a color profile later.

Yes, that makes sense - you'll need to pass both a source (RGB) and destination (CMYK) profile though.

All the best,

On Sun, Jul 20, 2003 at 12:49:02PM +0200, Sven Neumann wrote:

I sense your reaction as extremly unfair since we discussed the

Then you should probably change your attitude.

version number in all details and there were other arguments than the completely meaningless one you mention here.

Arguments like "the others do it, too"? That's of course no argument, and you never delivered anything else.

A few people expressed that they dislike the version number, other liked it.

I suggest you look at the mail archives again. There was quite a majority against 2.0 that you completely miss.

We went through all the arguments a few times and finally decided that we want to go for 2.0.

I am sorry, but you are trying to deceive... "we" is rather far fetched, as this seems to include you and mitch only (mitch hasn't even said anything).

For some reason I really don't trust your honesty anymore, as you are continuously misrepresenting facts.

What is so insistent about this?

What is so insisting is that you are not telling the truth, and I wonder why you resort to that.

It's a decision and it had to be done at some point.

Well, you decided it against the majority, without giving reasons.

Now please, for the good of GIMP, accept it and let us proceed to prepare this release.

As I said, I don't care that much for 2.0 vs. 1.4, but, as I said in the beginning, I wonder where the honesty went, since you cintinously brush aside others opinions, overruling them and all for, as you say, nothing important. If it's important enough for you to try to deceive, why are you claiming the opposite?

Your behaviour is *extremely* strange. I *am* frightened.

Sorry for the f'up to my own mail, but to avoid getting pushed into the troll corner I'd like to add this:

The reason I am so insisting is that you continously misrepresent what people say, and the current climax is that you totally ignore that the overwhelming majority of people here said they dislike 2.0.

If you stood up and publicly said something like: "yes, the majority here is against it, but I, the Sven who does by far most of the coding work" (might include Mitch, too, since you are his voice here) "just overrule everybody else and force out 2.0 against the will of the majority, because I can and will do it", then that would be fine with me. Really. But you don't do this, and this is frightening to me.

I don't oppose dictatorship on your side (I don't have reason nor the right to complain, too!), but I extremely dislike dishonesty. So if you are forcing this issue, please at least *acknowledge* it and don't try to misrepresent the issue in your favour.

Am Mon, 2003-07-21 um 01.54 schrieb Sven Neumann:

This can be easily fixed. We just need to find out what changes we actually want to do. Mitch seems to have a pretty clear idea how it could work and I think we discussed that we need some XML file that maps keywords to HTML pages.

I've also an idea which doesn't need a mapping at all and also doesn't need any tricky XML->HTML processing.

If there is interest in getting the new help to work, we can implement this mapping.

I'd rather we simply render the XML directly because the mapping is tricky at two points:
- The XML-transformation needs to be taught about creating files with a fixed name. This bit us before with SGML and is even more tricky with the DocBook/XML stylesheets.
- The docs need to be kept in sync with the GIMP Source which is a tedious work.

Of course if we decide to polish the old 1.2 help pages instead of doing a whole new thing, we would better not do this change.

I don't think we have enough manpower to get the help done in time. I've a business to run, have no idea where syngin is and it seems we still have no content writers. My guesstimate for efforts we'd need to put into it would be >400h to get something which is showable.

After all it involves touching _lots_ of files.

Tell me what....

On Mon, Jul 21, 2003 at 04:36:53PM +0200, Sven Neumann wrote:

What is so insisting is that you are not telling the truth, and I wonder why you resort to that.

I am not going to let you claim in public that I was lying to you or any other GIMP developer.

I didn't claim that. I do claim that you misrepresent facts on purpose, and this is a fact.

I wonder what makes you think I would do that. I think you should excuse yourself for this.

I think I am excused already, thank you.

In any case, you can ignore this issue, misrepresent facts, force 2.0, but please don't ask me to believe you anymore. From my side, I consider this thread finished now.

Am Mon, 2003-07-21 um 17.23 schrieb Sven Neumann:

You want us to include an XML renderer in the help-browser? That doesn't sound like a simple solution.

Why not? Why should DocBook be more difficult to render than HTML? It doesn't necessarily have to be a DocBook renderer, it could also be a live translator. Maybe we can utilize yelp for it?

What is tricky about 'xsltproc $xmlfile > $htmlfile'? OK, I have to admit I don't much experience with the DocBook XML issues you encountered when working on gimp-help but since I played with this stuff for developer.gimp.org I cannot follow this argument. Perhaps I need to take a closer look at gimp-help2 first...

The problem is that once you created the HTML, it's fixed including the filenames because the links point to it. Getting to spit out HTML files with the "correct" names in the granularity we want is close to impossible; I had to reorder gimp-help quite a bit to make it possible at all. Your developer.gimp.org experience is probably limited to either one single HTML file or files whose names don't matter except for index.html. However at the moment we need the filenames because the help browser picks up the files by loading a prespecified path. This scheme is not only hard to maintain but also broken by design; I'm quite confident there are still mislinked help files and we didn't notice in GIMP 1.2.

- The docs need to be kept in sync with the GIMP Source which is a tedious work.

How would your solution avoid this problem?

Instead of specifying filenames in the GIMP XML entities are specified to reference the wanted section. So both the help internally AND the GIMP are using exactly the same mapping to the files thereby avoiding annoying synchronisation problems.

Also the documentation can be shipped *as is* without risking wreckage every time the stylesheets or the processor or the GIMP or the content changes.

But I would perhaps make sense to setup the framework and encourage people to contribute help for gimp-2.0.

Good idea.

We could setup some text that is displayed for all missing pages and that explicitely encourages people to write help on this topic.

Didn't work for GIMP 1.2 so I doubt it will here. We haven't received a single contribution for the help in whatever form; maybe the "Eek" scared people off or something...

Daniel Egger wrote:

Am Mon, 2003-07-21 um 17.23 schrieb Sven Neumann:

You want us to include an XML renderer in the help-browser? That doesn't sound like a simple solution.

Why not? Why should DocBook be more difficult to render than HTML? It doesn't necessarily have to be a DocBook renderer, it could also be a live translator. Maybe we can utilize yelp for it?

What is tricky about 'xsltproc $xmlfile > $htmlfile'? OK, I have to admit I don't much experience with the DocBook XML issues you encountered when working on gimp-help but since I played with this stuff for developer.gimp.org I cannot follow this argument. Perhaps I need to take a closer look at gimp-help2 first...

The problem is that once you created the HTML, it's fixed including the filenames because the links point to it. Getting to spit out HTML files with the "correct" names in the granularity we want is close to impossible; I had to reorder gimp-help quite a bit to make it possible at all. Your developer.gimp.org experience is probably limited to either one single HTML file or files whose names don't matter except for index.html. However at the moment we need the filenames because the help browser picks up the files by loading a prespecified path. This scheme is not only hard to maintain but also broken by design; I'm quite confident there are still mislinked help files and we didn't notice in GIMP 1.2.

the attribute rewritter that we used on mgo is the easiest way to keep all of the urls straight that i found. this is not me saying it is easy, it is me saying it is easiest.

i spent some quality time with docbook; olink, ulink and kin. docbook was not written for gimp. Not the gimp as i understand it at least.

- The docs need to be kept in sync with the GIMP Source which is a tedious work.

gimp should write his own documentation. shoot, if we write the dtd properly, gimp can write his own docbook; i will not volunteer to write the layout for this however, as i am old and my life is already too short. gimp does not slide easily into docbook. but spewing xml from one place to another is easy stuff. at least Helvetix made it seem so, and i have not scared him away yet, as near as i can see.

How would your solution avoid this problem?

Instead of specifying filenames in the GIMP XML entities are specified to reference the wanted section. So both the help internally AND the GIMP are using exactly the same mapping to the files thereby avoiding annoying synchronisation problems.

Also the documentation can be shipped *as is* without risking wreckage every time the stylesheets or the processor or the GIMP or the content changes.

But I would perhaps make sense to setup the framework and encourage people to contribute help for gimp-2.0.

Good idea.

perhaps the wiki is already up and working for this sort of thing. or, maybe you would rather get some space on sourcforge or yahoo.

We could setup some text that is displayed for all missing pages and that explicitely encourages people to write help on this topic.

Didn't work for GIMP 1.2 so I doubt it will here. We haven't received a single contribution for the help in whatever form; maybe the "Eek" scared people off or something...

Eeek on a wiki is easier to read than in your software. I had a hard time seeing gimp-1.2 help, as i did not want to run the full browser and never managed to have all of the pieces together to build the gtk browser.

When i looked at what you were doing to try to contribute, I looked at the sgml template and all sense of reason and purpose escaped me. I don't think it was prof and syngin, i think it was terrible terrible sgml markup.

I feel like what i must wait until after camp to work on was answering all of these troubles. If I am somewhat incoherent at times, I can very easily blame trying to fit what I know into crappy templates that were not made with what i know in mind.

My plugin template was made to get information from the registry of the plugin and use it on a web page. It can be used in a help document also.

I cannot do this alone though. Seriously, if I am incoherent about this stuff, there is a good chance that the review of the current software caused this. I blame docbook. And docbook was better than sgml. help!

carol

On Mon, 2003-07-21 at 17:23, Sven Neumann wrote:

But I would perhaps make sense to setup the framework and encourage people to contribute help for gimp-2.0. We could setup some text that is displayed for all missing pages and that explicitely encourages people to write help on this topic.

I think this would be pretty elegant and would appeal to me personaly to write some particular doc. "Write documentation" is a horrid picture to me. An insanely large task. Write a particular section actually sounds fun.

Am Mon, 2003-07-21 um 20.09 schrieb Sven Neumann:

Because there are widgets that render HTML but no widgets that render DocBook. And actually, who wants to use the help-browser to browse the help files?

Are we talking about online help or a manual?

I do think that using (some flavour of) HTML has a lot advantanges.

Not as far as I can see, this is exactly the reason every OS has it's own metaformat for online help (think of CFM, Mac Doc Ressources, man pages, info, or even DocBook/XML in case of GNOME and KDE).

The biggest advantage is that we can expect a working browser on almost every box that GIMP gets installed to.

But a browser doesn't necessarily sport the navigation features one would like to have, or a global find function. Also a browser is meant for viewing documents on the whole screen while a help browser is typically used concurrently to the application it tries to help the user with.

That is not true. There is a simple XML file that maps the XML filenames to HTML filenames:

http://developer.gimp.org/layout.xml

Um, I seriously think I should rephrase the problem as we're talking about very things here.

Sorry, but I haven't yet understood the problem with filenames you see nor did I understand how your proposal would avoid it.

I'm not mapping filenames (neither XML nor HTML) but entities and or ids in XML files wherever they might appear. Basically one can add id attributes to arbitrary tags and use them as crossreference or link targets. So if you have one file referencing all other files (in the gimp-help module) specifying entities and then you call those entities a processor can cache the skeleton of the whole documentation tree and have all ids in memory thereby knowing where the specified (in GIMP source) id can be found in the jungle of XML files. This way I can (re-)structure information however I like and they will be always found.

OTOH using filenames which are loaded means that one has to teach the XML processor exactly how the *output* are to be named which is a feature which:
a) not all XSLT-processors support
b) works only with a fixed structure because the layout (chapters, sections, paragraphs) determine where the content will be located; the choosable filename (in the XML files) is a hint at best where it should place the HTML files.

You would just link to XML filenames, wouldn't you?

No.

How is that any better than
linking to HTML filenames (apart from the fact that I am speaking of XHTML here, so that would be XML then anyway)?

When I say XML in the context of gimp-help I always mean DocBook/XML which refers to the *input* format.

We ran a link-checker through the help files so I am pretty sure there isn't.

Huh? Where did you get that one from? (No, I wasn't talking about the links in the HTML files, but the links from the GIMP to the HTML files).

But of course we don't want to stick to the old system, that is not the point. The idea was to make GIMP refer to unique identifiers and to have a file that specifies how these identifiers map to HTML filenames (and anchors into HTML pages).

I understand but still think that using that unique identifiers directly on the XML files is more wise.

Eeek, entities are probably the worst thing in the XML / SGML world. I would rather avoid them whenever possible. An entity is just a macro and is thus mainly used for rather bad hacks.

Sorry, my bad, entities are used to teach a parent document about it's childs; linking is done using ids on arbitrary tags.

I think we should ship the documentation including the generated HTML pages. XSLT seems to be rather difficult to setup and I would not want to put that burden on the users.

Have you ever tried yelp? If not, please do it...

Am Mon, 2003-07-21 um 23.17 schrieb Carol Spears:

i spent some quality time with docbook; olink, ulink and kin. docbook was not written for gimp. Not the gimp as i understand it at least.

DocBook was written exactly for the purpose we need.

gimp should write his own documentation. shoot, if we write the dtd properly, gimp can write his own docbook; i will not volunteer to write the layout for this however, as i am old and my life is already too short.

Bad idea, own DTD means that one has to write one and also create the transformation stylesheets which is a lot of work, especially when considering that there's already a lot of software exactly for this purpose and it's also quite well documented.

Eeek on a wiki is easier to read than in your software. I had a hard time seeing gimp-1.2 help, as i did not want to run the full browser and never managed to have all of the pieces together to build the gtk browser.

Heh. Coincidently this are exactly two problems an online help system is facing... :)

When i looked at what you were doing to try to contribute, I looked at the sgml template and all sense of reason and purpose escaped me. I don't think it was prof and syngin, i think it was terrible terrible sgml markup.

I don't see the problem. Actually DocBook/XML is not much different from DocBook/SGML and since it's quite natural and I'm really picky about code style it should be quite readable. But as I said, we accept any format, even plain text.

I cannot do this alone though. Seriously, if I am incoherent about this stuff, there is a good chance that the review of the current software caused this. I blame docbook. And docbook was better than sgml. help!

We certainly need to set a few facts straight: XML and SGML are both just syntaxes for markup languages; SGML is a superset and ancestor of XML so it basically can look exactly like the stricter XML when a few rules are taken care of.
DocBook (which is a DTD) on the other hand defines the semantic or meaning of the used tags.

Comparing DocBook to SGML is like an apple to tree comparison.

And as I said: You probably cannot tell the difference between my DocBook/SGML and DocBook/XML files when I hide the fileextension...

Am Mon, 2003-07-21 um 23.21 schrieb Jakub Steiner:

I think this would be pretty elegant and would appeal to me personaly to write some particular doc. "Write documentation" is a horrid picture to me. An insanely large task. Write a particular section actually sounds fun.

We have had this notice in GIMP for quite a while which means that you either never even used the helpbrowser or didn't care. :/

However, I offer you the chance to write a particular section for the docs right away... Wanna pick a topic? :)

David Neary writes:

Sven Neumann wrote:

David Neary writes:

2) Not enough developers use Bugzilla to find out what bugs need fixing
3) Not enough developers hear user complaints

I'd like to chime in here and say that gimp seems much more responsive than most projects to bugzilla. Some bugs may get closed or duped, and I may not always agree, but I don't think I've ever felt like bugs were being ignored the way they are in a lot of projects. And that's even without the other channels like IRC and the mailing lists.

Of course, David didn't actually complain about responsiveness, but about the number of developers; and indeed, it's only a few developers making comments. Is the problem that bugs don't get triaged to appropriate owners, so that people outside the small overworked core team might see and fix them?

Now, let's look at the "Owner" field - 1 bug is owned by grosgood, one by jimmac, 2 by mitch, 2 by Raphael, 2 by rockwlrs, and 1 each for sven and yosh. That's 10. Leaving 381 bugs owned by that well-known gimp developer bugs@gimp.org.

I found that confusing, too -- it's not what I'm used to in other projects, where bugs generally have an owner and components have a default owner, who may also triage new bugs for that component. I guess the gimp team is small enough or works closely enough that they feel they don't need that; or everyone wants to see all the bugs.

The lifecycle of a bug *should* be that a bug gets reported against a module, which is owned by the module owner, who [ ... ]

I'm not sure anyone's quite sure of the perfect bug lifecycle. I've seen at least five different theories tried, and none seem to work perfectly. It probably just depends on what works best for a particular team.

I'm glad you agree there's a problem with the number of people active in gimp development. As I've said a couple of times, the module owners don't need to know how to fix the bugs. This seems to me like a great way to get people involved in the gimp. I know that fixing bugs was how I got involved... I just started browsing bugzilla, picked one that looked fairly easy, and attacked. So maybe there are 5 people who aren't too confident diving into the core, and would like to feel their way around with bug reports?

Bugzilla keywords, like helpwanted or blocker, can be helpful here too. (Does gimp already use these? I confess I haven't looked, and should.) For bugs which might be relatively easy fodder, a keyword in bugzilla and a periodic posting on gimp-developer mentioning the keyword or requesting help on particular bugs (as I've seen here a few times in the past) can be a great motivator.

...Akkana

Daniel Egger wrote:

Am Mon, 2003-07-21 um 23.21 schrieb Jakub Steiner:

I think this would be pretty elegant and would appeal to me personaly to write some particular doc. "Write documentation" is a horrid picture to me. An insanely large task. Write a particular section actually sounds fun.

However, I offer you the chance to write a particular section for the docs right away... Wanna pick a topic? :)

Would it take you long to put together a list of topics that docs are needed for? We could cross-post to the gimp-users list, and maybe send a copy to the GUG and see if anyone there is interested in helping out...

Just an idea.

Cheers, Dave.

On Mon, 2003-07-21 at 23:48, Daniel Egger wrote:

We have had this notice in GIMP for quite a while which means that you either never even used the helpbrowser or didn't care. :/

However, I offer you the chance to write a particular section for the docs right away... Wanna pick a topic? :)

The main motivator I was talking about is bringing up a help browser for a certain tool, seeing a 'please help' msg.

Daniel Egger wrote:

On Tue, Jul 22, 2003 at 09:46:17AM +0200, David Neary wrote:

Would it take you long to put together a list of topics that docs are needed for? We could cross-post to the gimp-users list, and maybe send a copy to the GUG and see if anyone there is interested in helping out...

Well, there is an outline (i.e. the index) which might give a few hints. A fully fledged would take some time and cooperation though.

Where is the index? And when you say "outline" do you mean "root document with lots of dead links"?

Cheers, Dave.

pcg@goof.com ( Marc) (A.) (Lehmann ) wrote:

On Mon, Jul 21, 2003 at 04:36:53PM +0200, Sven Neumann wrote:

What is so insisting is that you are not telling the truth, and I wonder why you resort to that.

I am not going to let you claim in public that I was lying to you or any other GIMP developer.

I didn't claim that. I do claim that you misrepresent facts on purpose, and this is a fact.

I wonder what makes you think I would do that. I think you should excuse yourself for this.

I think I am excused already, thank you.

In any case, you can ignore this issue, misrepresent facts, force 2.0, but please don't ask me to believe you anymore. From my side, I consider this thread finished now.

is it worth building the gimp-perl module from cvs yet?

carol

On Tue, Jul 22, 2003 at 02:51:16PM -0400, Carol Spears wrote:

is it worth building the gimp-perl module from cvs yet?

Depends on what you are needing it for.

The evrsion in CVS seems to be fully working, except that none of the examples that use their own Gtk+ interface have been converted to gtk2 yet, and coredump.

Also, many constants have different names in 2.0, and, although I hopefully renamed them in the plug-ins, I certainly didn't test all the plug-ins.

There are also certainly some edges, but you should be able to work with it quite nicely. And if some plug-ins don't work just delete them.

(I even built it on windows for fun.. and as I though, no sourcecode changes were required, although I built with cygwin using gtk+2-win32)

writes:

is it worth building the gimp-perl module from cvs yet?

Depends on what you are needing it for.

The evrsion in CVS seems to be fully working, except that none of the examples that use their own Gtk+ interface have been converted to gtk2 yet, and coredump.

gtk2-perl binding is quite usuable now and conversion is not so difficult.

pcg@goof.com ( Marc) (A.) (Lehmann ) wrote:

On Tue, Jul 22, 2003 at 02:51:16PM -0400, Carol Spears wrote:

is it worth building the gimp-perl module from cvs yet?

Depends on what you are needing it for.

The evrsion in CVS seems to be fully working, except that none of the examples that use their own Gtk+ interface have been converted to gtk2 yet, and coredump.

Also, many constants have different names in 2.0, and, although I hopefully renamed them in the plug-ins, I certainly didn't test all the plug-ins.

There are also certainly some edges, but you should be able to work with it quite nicely. And if some plug-ins don't work just delete them.

(I even built it on windows for fun.. and as I though, no sourcecode changes were required, although I built with cygwin using gtk+2-win32)

thats awesome. gimp-perl is broken right now for gimp-1.2, i get this message from gimp that if i am elite enough to use threading, then i am elite enough to fix it.

i think if i pin perl from woody, i am elite enough to fix it.

also, i really really never ever thought that gimp-perl would be available for wingimp. i am also impressed that you can send all that mail and still get things done.

thank you carol

Am Die, 2003-07-22 um 18.34 schrieb David Neary:

Where is the index? And when you say "outline" do you mean "root document with lots of dead links"?

Nope, I mean like a rough idea of the table of contents:
1. Introduction
1. Welcome to The GIMP
1.1. Known platforms
1.2. The GIMP-Help system 2. Legalese
1. The GIMP License
3. Toolbox
1. The Toolbox
2. The Toolbox Menu
3. Rectangle Selection Tool
4. Ellipse Selection Tool
5. Free Selection Tool
6. Fuzzy Selection Tool
7. Select By Color Tool
8. Scissors Tool
9. Patience! For the Jedi it is time to eat as well. 10. Color Picker Tool
11. Histogram
12. Magnify Tool
13. Measure Tool
14. Move Tool
15. Crop Tool
16. Rotate Tool
4. Filters
1. Filter introduction
2. Blur
2.1. Overview
2.2. Options
2.3. See also...
Glossary

Don't know how 3.9. slipped in but apart from that it's what we have right now. We need more introduction, more tool descriptions (also from those not in the toolbox), plugin descriptions, meta information (like keyboard shortcuts), examples, screenshots etc...

Patrick McFarland wrote:

I am one of these active users that have been lead to believe that gimp 2.0 will use GEGL. So, all the developers out that think 2.0 is yet another small gimp release, or something else (imho) stupid, can just go away or something.

Im actually kind of sick of listening all of you bicker back and forth. From my outsider point of view, 2.0 is set in stone, and what it will include will be set in stone. Also, from my outsider pov, stuff like gegl is a very cool idea. Anything that allows gimp to be more powerful is always a good thing. I also see gegl as a major feature, something that would produce a 2.0.

However, the more you all bicker, the less work is actually getting done. I hate to have to be the one saying this, but you should just be coding, because in the end, whoever codes gimp 2.0 is the one who gets to say what happens, or _nothing happens at all._

Gegl is basically the end all be all gimp graphics rendering engine. It will be able to do what no popular graphics manipulation program has done before. (I think.) 16-bit per channel graphics is good, and internal floating point based calculations independent of the actual image's bitdepth is good as well (due to the fact multi-layered images often go above 1.0 and below 0.0, and clipping severely damages the output.)

Also, while Im on the pro gimp 2.0 kick, I read the xcf2 threads. I agree, something like gimp2 will need a better file format. Internally, I dont care whats in it. Im not a gimp developer, Im a user, so I should have to care. _However_, it needs to be able to be very extendable. I want to be able to store all future gegl supported bitdepth and color space types with it, I want to be able to depend on it to be stable the same way the professional people depend on psd being a half way decent format, and I want it to someday exist, the same way I want gimp2 to someday exist.

A lot of users out there are depending on the gimp development team to get gimp2 done sometime in their lifetimes, and from what I see on here, this may never happen. And Im going to be severely disappointed if this happens.

Two bits from a former developer, here. We talked a lot about what 2.0 would have after we released 1.0. CVS current is nothing close to that. I'd be disappointed if it were released as 2.0. So would a lot of the people I talk to about the GIMP. A lot of people have seen the GEGL documents. People have expectations for 2.0 that this release will not meet. I personally think you shouldn't call it 2.0 until it supports Lab as a native color space, but that's because I really like Lab.

The relative lack of serious technical progress in recent versions is why I now use Photoshop 7 for most image editing, these days. I only use GIMP when I want one of the plug-in effects that isn't available from PS7, or when I'm on a computer that I don't have a PS7 license for. Maybe I'm the only one like that, but I doubt it. PS5 and Gimp 1.0 were pretty competitive in most areas, with a few well-noted shortcomings. PS7 completely blows away CVS HEAD. Releasing it as 2.0 will invite comparisons, and you don't want to do that right now.

I'm not actively involved in the project anymore, so it's not really my fish to fry, but I'd ask the current project maintainers to reconsider releasing the current HEAD branch as 1.4 instead of 2.0.

Kelly

Sven Neumann wrote:

The ball is rolling now and any further discussion about it is only hurting GIMP's reputation.

You're going to do what you're going to do. I'm just offering my counsel. Claiming that offering my counsel is "hurting GIMP's reputation" is a hamfisted way of telling me to shut up because you don't like my opinion. Releasing 1.4 as 2.0 will do more to hurt GIMP's reputation than anything I could say about why you shouldn't do so.

As to why PS7 is better: the PS7 features I make the most use of are the better colorspace support, PS7 dynamic brushes, adjustment and effect layers, and the "healing brush".

Kelly

Kelly Martin wrote:

Sven Neumann wrote:

The ball is rolling now and any further discussion about it is only hurting GIMP's reputation.

You're going to do what you're going to do. I'm just offering my counsel. Claiming that offering my counsel is "hurting GIMP's reputation" is a hamfisted way of telling me to shut up because you don't like my opinion. Releasing 1.4 as 2.0 will do more to hurt GIMP's reputation than anything I could say about why you shouldn't do so.

As to why PS7 is better: the PS7 features I make the most use of are the better colorspace support, PS7 dynamic brushes, adjustment and effect layers, and the "healing brush".

what does "hamfisted" mean?

carol

Carol Spears wrote:

Kelly Martin wrote:

Claiming that offering my counsel is "hurting GIMP's reputation" is a hamfisted way of telling me to shut up because you don't like my opinion. Releasing 1.4 as 2.0 will do more to hurt GIMP's reputation than anything I could say about why you shouldn't do so.

what does "hamfisted" mean?

Awkward, ungainly - imagine someone with fists like hams trying to pluck eyebrows or pick up pennies.

Dave.

carol@gimp.org (2003-07-23 at 1320.11 -0400):

counsel. Claiming that offering my counsel is "hurting GIMP's reputation" is a hamfisted way of telling me to shut up because you don't like my opinion. Releasing 1.4 as 2.0 will do more to hurt

what does "hamfisted" mean?

Using dict(1):

1 definition found

From WordNet (r) 1.7 [wn]:

ham-fisted
adj : not skillful in physical movement especially with the hands; "a bumbling mechanic"; "a bungling performance"; "ham-handed governmental interference"; "could scarcely empty a scuttle of ashes, so handless was the poor creature"- Mary H. Vorse [syn: {bumbling}, {bungling}, {butterfingered}, {ham-handed}, {handless}, {heavy-handed}, {left-handed}]

GSR

On Wed, Jul 23, 2003 at 09:47:37AM -0400, Carol Spears wrote:

get this message from gimp that if i am elite enough to use threading, then i am elite enough to fix it.

;)

i think if i pin perl from woody, i am elite enough to fix it.

The problem is that debian woody uses an experimental and very very broken option when compiling their perl, namely the 5.005 threading model.

It's known not to work with gimp or many other modules, and since it's explicitly flagged as experimental people really wonder why debian chose to enable it.

The perl from testing or unstable (one of them has 5.008) should work.

(Please note that it explicitly says that it is a warning only, doesn't mention "elite" anywhere and all that is requested is to not send complaints when it breaks, as you have been warned).

also, i really really never ever thought that gimp-perl would be available for wingimp.

The problem is that there seem to be two modes of building gimp or gtk+2, the using unix-like tools, and the (standard!) one.

You could have the first (easy, for unixians) way with gtk1, too, but then gimp would only run with an X11 server.

Gtk+2 can be built with the normal win32 backend even under cygwin now. That might not be the platform that people want (no nice installer etc.), which is why I think it will take some time until all this works out of the box.

gimp-perl would need to be modified in it's config mechanism since the 1.2 wingimp doesn't provide the configuration framework needed. I do not know wether this will be true for the 2.0 version, but I suspect it will (?).

while gimp-perl-1.2 could be modified, all hopes are gone when it comes to Gtk1.

The situation is very different to gtk+2, though, since standard cygwin builds are available and useful and support pkgconfig. The build framework of Gtk+2-perl is also working with that.

So, getting gimp-perl-1.3 Gtk+2 and gimp working under windows is "just" a matter of a lot of time and patience.

Daniel Egger wrote:

Am Die, 2003-07-22 um 18.34 schrieb David Neary:

Where is the index? And when you say "outline" do you mean "root document with lots of dead links"?

Nope, I mean like a rough idea of the table of contents:
1. Introduction
1. Welcome to The GIMP
1.1. Known platforms
1.2. The GIMP-Help system 2. Legalese
1. The GIMP License
3. Toolbox
1. The Toolbox
2. The Toolbox Menu
3. Rectangle Selection Tool
4. Ellipse Selection Tool
5. Free Selection Tool
6. Fuzzy Selection Tool
7. Select By Color Tool
8. Scissors Tool
9. Patience! For the Jedi it is time to eat as well. 10. Color Picker Tool
11. Histogram
12. Magnify Tool
13. Measure Tool
14. Move Tool
15. Crop Tool
16. Rotate Tool
4. Filters
1. Filter introduction
2. Blur
2.1. Overview
2.2. Options
2.3. See also...
Glossary

Don't know how 3.9. slipped in but apart from that it's what we have right now. We need more introduction, more tool descriptions (also from those not in the toolbox), plugin descriptions, meta information (like keyboard shortcuts), examples, screenshots etc...

i am stuck on 3.9.

i am going to work up some ideas starting there. maybe even at neditcon1.

this is a nice list, btw. wanna see my 404 dumpster?
http://www.det-tour.org/~carol/gallery/summer/IMG_0223.html

i am very much enjoying making this new gimp make my webpages right now.

thanks

carol

pcg@goof.com ( Marc) (A.) (Lehmann ) wrote:

On Tue, Jul 22, 2003 at 02:51:16PM -0400, Carol Spears wrote:

is it worth building the gimp-perl module from cvs yet?

Depends on what you are needing it for.

The evrsion in CVS seems to be fully working, except that none of the examples that use their own Gtk+ interface have been converted to gtk2 yet, and coredump.

Also, many constants have different names in 2.0, and, although I hopefully renamed them in the plug-ins, I certainly didn't test all the plug-ins.

There are also certainly some edges, but you should be able to work with it quite nicely. And if some plug-ins don't work just delete them.

(I even built it on windows for fun.. and as I though, no sourcecode changes were required, although I built with cygwin using gtk+2-win32)

i am going to spend some time at my moms early next week. this might be one of those cool occasions where i can have the perl plugins working on wingimp and not on my elite debian gnu/linux box cvs gimp build. is that cool or what?

do you think there might be something to show her while i am there?

i will warn you, i am having a whippet party with my good friend szell earlier this day, so i will not be as clear thinking as usual.

what is the chances that the gimp perl plugins can run be running on my moms window box next monday evening?

carol

pcg@goof.com ( Marc) (A.) (Lehmann ) wrote:

On Wed, Jul 23, 2003 at 09:47:37AM -0400, Carol Spears wrote:

get this message from gimp that if i am elite enough to use threading, then i am elite enough to fix it.

;)

i think if i pin perl from woody, i am elite enough to fix it.

The problem is that debian woody uses an experimental and very very broken option when compiling their perl, namely the 5.005 threading model.

It's known not to work with gimp or many other modules, and since it's explicitly flagged as experimental people really wonder why debian chose to enable it.

The perl from testing or unstable (one of them has 5.008) should work.

(Please note that it explicitly says that it is a warning only, doesn't mention "elite" anywhere and all that is requested is to not send complaints when it breaks, as you have been warned).

also, i really really never ever thought that gimp-perl would be available for wingimp.

The problem is that there seem to be two modes of building gimp or gtk+2, the using unix-like tools, and the (standard!) one.

You could have the first (easy, for unixians) way with gtk1, too, but then gimp would only run with an X11 server.

Gtk+2 can be built with the normal win32 backend even under cygwin now. That might not be the platform that people want (no nice installer etc.), which is why I think it will take some time until all this works out of the box.

gimp-perl would need to be modified in it's config mechanism since the 1.2 wingimp doesn't provide the configuration framework needed. I do not know wether this will be true for the 2.0 version, but I suspect it will (?).

while gimp-perl-1.2 could be modified, all hopes are gone when it comes to Gtk1.

The situation is very different to gtk+2, though, since standard cygwin builds are available and useful and support pkgconfig. The build framework of Gtk+2-perl is also working with that.

So, getting gimp-perl-1.3 Gtk+2 and gimp working under windows is "just" a matter of a lot of time and patience.

sorry, i hadn't read this before mussing on getting those plugins to my moms computer.

i didn't complain about the warning and the problem. i guess i even knew how to fix it.

please ignore the email i most recently sent.

carol

On Wed, Jul 23, 2003 at 03:33:55PM -0400, Carol Spears wrote:

i am going to spend some time at my moms early next week. this might be one of those cool occasions where i can have the perl

I got it working with tml's native build, linking msvcrt and cygwin.dll into the same process (does not work, but actually works)

I'll check in a README.win32 soon that describes very roughly what I did.

*However* you would better allocate a few days to it. Apart from the compile speed (gcc on win32 compiles 5-10times slower on my machine than under linux), you need quite a lot of time selecting the right toolset and gtk version (there are *many* different gtk+ versions).

I'd even recommend against it at this stage, and leave it somebody else to prepare a distribution once 2.0 is out.. :)

what is the chances that the gimp perl plugins can run be running on my moms window box next monday evening?

close to zero.

Michael Schumacher writes:
> According to Tor Lillqvist, there was something missing from Pango > 1.2.3 and fixed shortly after the release.

BTW, I now made new pre-built pango-1.2.3 Win32 packages on www.gimp.org/win32/downloads.html, with the missing exports added, so building GIMP 1.3.x for Win32 should now be easier.

--tml

Michael Schumacher writes:
> According to Tor Lillqvist, there was something missing from Pango > 1.2.3 and fixed shortly after the release.

BTW, I now made new pre-built pango-1.2.3 Win32 packages on www.gimp.org/win32/downloads.html, with the missing exports added, so building GIMP 1.3.x for Win32 should now be easier.

Thanks. I've succeeded in building GIMP 1.3 on Win32 using these packages.

HTH, Michael

On Sat, 26 Jul 2003, Michael Schumacher wrote:

Date: Sat, 26 Jul 2003 03:04:12 +0200 (MEST) From: Michael Schumacher
To: gimp-developer@lists.xcf.berkeley.edu Subject: Re: (LONG) Problems with the GIMP (was: Re: [Gimp-developer] tentative GIMP 2.0 release plans)

Michael Schumacher writes:
> According to Tor Lillqvist, there was something missing from Pango > 1.2.3 and fixed shortly after the release.

BTW, I now made new pre-built pango-1.2.3 Win32 packages on www.gimp.org/win32/downloads.html, with the missing exports added, so building GIMP 1.3.x for Win32 should now be easier.

Thanks. I've succeeded in building GIMP 1.3 on Win32 using these packages.

Any chance of binaries for testing?

And what compiler did you use (wondering if I'll be able to get gtk-wimp to work with the Gimp 1.3 on windows).

Sincerely

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

Alan Horkan wrote:

On Sat, 26 Jul 2003, Michael Schumacher wrote:

[...]

Thanks. I've succeeded in building GIMP 1.3 on Win32 using these

packages.

Any chance of binaries for testing?

No. There are still to much issues to even think of it - some of them may be caused by the fact that I'm running gimp from the directory where I've built it. Currently, it would be better to help others building GIMP on win32 than to distribute binaries of it - there are some issues in the build process that should be worked out first (i.e., it seems to be impossible to build on Win9x/ME)

And what compiler did you use (wondering if I'll be able to get gtk-wimp to work with the Gimp 1.3 on windows).

I used GCC that comes with MinGW: http://mingw.sourceforge.net. gtk-wimp seems to work.

HTH,
Michael

Alan Horkan writes:
> Any chance of binaries [for Win32] for testing?

If you ask nicely, I might be presuaded to zip up what I've got... (Just built it on Win32 for the first time in a while.)

> And what compiler did you use (wondering if I'll be able to get gtk-wimp > to work with the Gimp 1.3 on windows).

gcc version 3.2.3 (mingw special 20030504-1)

One irritating thing with GIMP on Windows currently is GTK bug #112402, I really need to fix that soon. GIMP's toolbox and some other windows are currently positioned with their title bar exactly off screen.

There also seems to be some handle leak when GIMP is starting up and queries all the plug-ins. Also, something needs to be done to #98737 soon. (Perhaps related, I had to start GIMP at least four times before it got past all the plug-ins and wrote out the pluginrc file.)

--tml

At 23:22 27.07.03 +0000, Tor Lillqvist wrote: [...]

One irritating thing with GIMP on Windows currently is GTK bug #112402, I really need to fix that soon. GIMP's toolbox and some other windows are currently positioned with their title bar exactly off screen.

This is a regression of previous versions. IIRC it was caused by the usage of gdk_eindow_new() with parameters 'in range' and additional adjusted by SafeAdjustWindowRect and the code later calling gdk_window_move with coordinates directly derived from the current mouse cursor position. Using SafeAdjustWindowRectEx in gdk/win32/gdkwindow-win32.c:996 appears to fix it.

There also seems to be some handle leak when GIMP is starting up and queries all the plug-ins. Also, something needs to be done to #98737 soon. (Perhaps related, I had to start GIMP at least four times before it got past all the plug-ins and wrote out the pluginrc file.)

I'm still using my somewhat hackish g_spawn_async version attached to the bug report and don't have to restart at all under win9x during the whole plug-in query phase.

Hans -------- Hans "at" Breuer "dot" Org ----------- Tell me what you need, and I'll tell you how to get along without it. -- Dilbert

Hans Breuer writes:
> This is a regression of previous versions. IIRC it was caused > by the usage of gdk_eindow_new() with parameters 'in range' and > additional adjusted by SafeAdjustWindowRect and the code > later calling gdk_window_move with coordinates directly derived > from the current mouse cursor position. > Using SafeAdjustWindowRectEx in gdk/win32/gdkwindow-win32.c:996 > appears to fix it.

I just committed changes to gdk/win32 (HEAD and gtk-2-2) that seem to fix these problems. In fact, I dropped SafeAdjustWindowRectEx() altogether, I don't think it's GTK's business to prevent an application from locating its windows outside of the screen if it wants to :-) And with multiple monitors, coordinates might be negative anyway.

The main job of the fix was going through the handling of top-level window position and size in event generation and functions, and make sure that it matches GDK's convention (position is that of decoration, size that of client area). And in the Win32 API, usually both position and size include decorations.

> I'm still using my somewhat hackish g_spawn_async version attached to > the bug report and don't have to restart at all under win9x during the > whole plug-in query phase.

I'll look at g_spawn() improvements tomorrow, hopefully.

--tml

Tor Lillqvist writes:
> There also seems to be some handle leak when GIMP is starting up and > queries all the plug-ins. Also, something needs to be done to #98737 > soon. (Perhaps related, I had to start GIMP at least four times before > it got past all the plug-ins and wrote out the pluginrc file.)

Done:

2003-07-30 Tor Lillqvist

* app/plug-in/plug-in.c (plug_in_close): [Win32] Plug handle leak, call CloseHandle().

and in GLib:

2003-07-31 Tor Lillqvist

* glib/gspawn-win32.c: When possible, manage without the helper process. (Part of the enhancements outlined in #98737.) Speeds up GIMP 1.3's first-time-run plug-in query phase a lot.

Plug a file descriptor (and thus Win32 handle) leak: close the read end of the child error report pipe after use.

Now I can start GIMP 1.3.17 from fresh and it successfullly queries all the plug-ins, quite fast even, with no handles leaked.

Still need to add script support to gspawn-win32.c so that Hans's Python plug-ins work.

--tml

On 21 Jul 2003, at 19:27, Daniel Egger wrote:

Am Mon, 2003-07-21 um 17.23 schrieb Sven Neumann:

We could setup some text that is displayed for all missing pages and that explicitely encourages people to write help on this topic.

Didn't work for GIMP 1.2 so I doubt it will here. We haven't received a single contribution for the help in whatever form; maybe the "Eek" scared people off or something...

Do you mean the following text?

+ Can I help? +
+ Yes, you can! Please send a message to with + Animate Cells as the subject line. Feel free to also + include documentation related suggestions or fix requests.

That's hardly an invitation to write this part of the online help. I also seem to remember some policy about using bugzilla instead of the above e-mail address.

Am Die, 2003-08-19 um 00.15 schrieb Branko Collin:

Didn't work for GIMP 1.2 so I doubt it will here. We haven't received a single contribution for the help in whatever form; maybe the "Eek" scared people off or something...

Do you mean the following text?

Yeah, that was the eek text. However this was not my idea and still don't like it.

That's hardly an invitation to write this part of the online help.

Agreed. I also think such messages don't reach the right users; pros rarely read the help especially when it's known to be rather incomplete and not really useful.

I also seem to remember some policy about using bugzilla instead of the above e-mail address.

Where? :)