[Gimp-developer] developer.gimp.org
Hi, I finally moved the new site that was created some months ago to developer.gimp.org. Please have a look and comment on it. This is by no means final but I hope that it will allow to spread info about GIMP development more easily. The web-site is build using docbook website. This may seem difficult but it makes it very easy to contribute content. If anyone is interested, you can directly access the XML source of a particular page by replacing the .html extension with .xml. The whole source with stylesheets can be downloaded as well: http://developer.gimp.org/dgo.tgz I would appreciate help with content as well as with integration of the API reference and other docbook sources (Simon wrote a nice article about plug-in development that would fit nicely). I haven't yet managed to integrate sources that don't use the docbook website DTD but other variants of docbook (article, book) but I am sure it can be done. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] tentative GIMP 2.0 release plans
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. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] tentative GIMP 2.0 release plans
Marc, Arguments like the others do it, too? That's of course no argument, and you never delivered anything else. Please look at the mailing-list archive, there were numerous arguments for 2.0. Your attitude is extremly unfair. You are completely ignoring the discussion that has taken place and pick only the worst and meaningless arguments that have been made. 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. I don't think it makes sense to count the number of people that expressed their opinion on the list. As with every discussion the ones that are against a particular change raise their voices the most and the ones that agree do so mostly quietly or in private mails. Only few people expressed problems with the version number change and they didn't have any compelling arguments. The voices against 2.0 have not been ignored or we would have announced the change earlier. Instead we decided to think about it again, asked more people for their opinion, discussed it on #gimp and with a couple of users and then decided that 2.0 is a reasonable choice. 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 wonder what makes you think I would do that. I think you should excuse yourself for this. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] tentative GIMP 2.0 release plans
On Mon, Jul 21, 2003 at 04:36:53PM +0200, Sven Neumann [EMAIL PROTECTED] 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. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] tentative GIMP 2.0 release plans
Hi Marc, [EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) writes: 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. I really don't think the majority was overwhelming. These numbers are difficult to evaluate since there are other sources than just this mailing-list and of course any vote should be multiplied with the amount of contributions a particular voter has made to this project. 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. No, I am not going to say this since I don't agree with the lines written above and they do not express my view of the decision process. Of course there is some sort of force. A decision is made and then, instead of discussing it over and over again, it is forced upon the people that didn't agree. I would prefer that everyone agreed but it looks as if a few people are completely stuck on their choice. I'm feeling sad about this and takes a good amount of fun out of doing this release. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] tentative GIMP 2.0 release plans
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 -- Servus, Daniel signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
[Gimp-developer] gimp-help2
Hi Daniel, Daniel Egger [EMAIL PROTECTED] writes: I'd rather we simply render the XML directly because the mapping is tricky at two points: You want us to include an XML renderer in the help-browser? That doesn't sound like a simple solution. - 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. 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 docs need to be kept in sync with the GIMP Source which is a tedious work. How would your solution avoid this problem? 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. 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. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: gimp-help2
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 insert your favourite xslt processor here 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... -- Servus, Daniel signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
[Gimp-developer] Re: gimp-help2
Hi, Daniel Egger [EMAIL PROTECTED] writes: 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? 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? I do think that using (some flavour of) HTML has a lot advantanges. The biggest advantage is that we can expect a working browser on almost every box that GIMP gets installed to. The problem is that once you created the HTML, it's fixed including the filenames because the links point to it. Getting insert your favourite xslt processor here 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. That is not true. There is a simple XML file that maps the XML filenames to HTML filenames: http://developer.gimp.org/layout.xml Sorry, but I haven't yet understood the problem with filenames you see nor did I understand how your proposal would avoid it. You would just link to XML filenames, wouldn't you? 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)? 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. We ran a link-checker through the help files so I am pretty sure there isn't. 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). - 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. 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. 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. 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. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] When Gegl?
So, if gegl isnt going to be in gimp2, when will it be? Ive been waiting for gimp2 awhile now, and now that gegl wont be in it, I have to keep waiting. How long will I have to wait now? 2.2? 2.4? -- Patrick Diablo-D3 McFarland || [EMAIL PROTECTED] Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music. -- Kristian Wilson, Nintendo, Inc, 1989 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] When Gegl?
Patrick McFarland wrote: So, if gegl isnt going to be in gimp2, when will it be? Ive been waiting for gimp2 awhile now, and now that gegl wont be in it, I have to keep waiting. How long will I have to wait now? 2.2? 2.4? gegl isn't a panacea... -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 That gum you like is going to come back in style. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp-help2
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. -- Jakub Steiner [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] When Gegl?
Patrick McFarland wrote: So, if gegl isnt going to be in gimp2, when will it be? Ive been waiting for gimp2 awhile now, and now that gegl wont be in it, I have to keep waiting. How long will I have to wait now? 2.2? 2.4? I believe that the general idea (one with which I agree) is to have a quick 2.2 with some very small features going in. That should be out by Christmas. Then gegl would go in in the new year, and work would begin on gettiong gegl to the point where it replaces at least the current gimp functionality. There will also be floating point support from the start. After that, we will need a tile iterator, a pixel accessor, more operations, and more colourspace definitions. We'll also need to redo a large part of the core (notably the channels stuff, and all the plug-ins) to take account of the generalised image structure. We will also need a new file format, IMHO. But that's being discussed elsewhere. A pity that people are more worried about whether jar or ar will be used to bunch layers together than they are about how the future gimp will handle layer trees and groups, adjustment layers, vector and text layers and all the other interesting difficult stuff, though. Cheers, Dave. PS. Excuse my tone. I've become a little bitter twisted. I'm sure Berlin will fix that. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp-help2
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? :) -- Servus, Daniel signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [Gimp-developer] Re: (LONG) Problems with the GIMP
David Neary writes: Sven Neumann wrote: David Neary [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] When Gegl?
On Monday 21 July 2003 4:47 pm, Adam D. Moss wrote: Patrick McFarland wrote: So, if gegl isnt going to be in gimp2, when will it be? Ive been waiting for gimp2 awhile now, and now that gegl wont be in it, I have to keep waiting. How long will I have to wait now? 2.2? 2.4? gegl isn't a panacea... Perfectly said. Actually, I've skimmed trhough some docs on the GEGL, and I wonder, what are its actual uses for the final user? I can see it provides the grounds for easier hacking in the GIMP, and will facilitate the implemanetation of internal CMYK and FLoating point images, and such. But for GEGL alone, what does the artist takes? I can also see that it could be a nice engine to provide a customizable brush, or layer combine mode. I am writing such a resource for gimp 1.3, whithout GEGL, and even if it doesn't make it in the official tree, it will be avaliable to whoever wants to try it. Of course, I am probably missing a lot of uses of the GEGLL - but I am gneuinely interested in knowing more about it. Thanks, JS -- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
