Re: [Gimp-developer] When Gegl?
On 21-Jul-2003, Joao S. O. Bueno wrote: 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? Ive been having a long discussion with Robin Rowe about stuff he possibly wants to do with CinePaint. I am, in this context, an artist. Stuff like CMYK is obvious how thats useful. (Desktop - printer stuff, etc) Floating point, however, is harder to wrap your mind around. The short answer is that quantiziation of data is bad, and more precision is better. To continue on this line of thinking, integers are limited to 0.0 and 1.0 (In 8bit per channel images, this is 0 through 255). Once its goes above 1.0, or below 0.0, data is lost. Floating point values are not clipped, so data is not lost. In addition, gegl would have been able to internally calculate using higher precision values, which allows it to unresrect itself from the accumulating error. (Basic programming concept, google for it.) So, you may have 8 bits per channel, but over the course of a dozen layers, you have tons of data. (More than can be represented in 8 bits at all times.) To avoid the accumulating error from snowballing, you use a much higher precision to calculate it. Floating point math comes in handy here too. So, with floating point, we've avoided clipping, and we've avoided premature quantization and accumulating of errors. Of course, most of what I said above applies to what you call layer combining. To apply floating point goodness to individual layers, take the common arguments for 8 bit per channel vs 16 bit per channel, and replace 8 bit with the word integer, and 16 bit with the phrase floating point. _In addition_ to the higher precision (called a larger dynamic range in film talk), you also can ignore clipping, because floating point doesnt have it. As an artist, the high precision layer combining is a godsend, and as a very gimp-abusive artist, high precision and no clipping all around is a godsend. So, this is why Im disapointed that it never came into being. -- 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] gimp-help2
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. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re: [Gimp-developer] gimp-help2
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. -- Jakub Steiner [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: gimp-help2
Hi, Daniel Egger [EMAIL PROTECTED] writes: 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. You are right but do we really want to depend on the helpbrowser alone? I could live with this but it would mean to drop one of the requirements we set up for the help system until now. Being able to read the help pages using a traditional browser has always been considered a necessity. If we want to get away with that, we should have a good reason. 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. Since XHTML is XML as well we can do the very same thing with HTML pages. Of course the concept I proposed wasn't limited to linking to toplevel HTML pages but it would include a mapping from unique identifiers to anchors in a set of HTML pages. This technique is usually referred to as XLink. 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. The XSLT processor would of course also generate the mapping table. Thus the HTML pages can have arbitrary names and can be arranged in an arbitrary directory structure. This structure can also be changed without changing anything in the GIMP. GIMP only points to some ids and uses a simple XML file to map these ids to XLinks into a set of XHTML pages. This mapping is part of gimp-help and thus completely under control of the gimp-help crew and can be generated based on the DocBook/XML sources. Now where is your problem with this concept? 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. You obviously did not understand me. Have you ever tried yelp? If not, please do it... I did but yelp is quite complex and I don't think we have the time and resources to reimplement it as our help-browser. We could of course depend on yelp and use it but it will pull in a whole bunch of other dependencies. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] status of GimpTent preparations
Hi, the Camp is getting closer and we are going into details of GimpTent preparations. I thought I should let you know what is happening here so that you know what you are missing if you don't attend. As a short summary in case you don't know yet, the Chaos Communication Camp is an international open-air hacker gathering. It takes place August 7th to 10th on a field near Berlin, Old Europe: http://www.ccc.de/camp/2003/ The GIMP and GEGL developers will be present with a large tent. The tent will host the GIMP Developers Conference but it will also provide a number of public workstations where people can use The GIMP. Users can share their experiences, give tips, watch other users work with The GIMP and talk to developers about their needs. The GimpTent will be located in the Art Beauty Village close to the tent of a group of VJs which have already expressed their interest in talking the GIMP developers into improving video editing capabilities. I expect some interesting ideas to come out of this. https://wiki.camp.ccc.de/Camp/view/Main/ArtAndBeautyVillage https://wiki.camp.ccc.de/Camp/view/Main/OpenAirVIT We will try to make the GimpTent a nice place for everyone interested in GIMP and graphics in general. Everyone is invited to participate. If you want to bring your hardware, you are welcome, but please let us know beforehand so that we can try to provide a nice place for you to set it up. If you have any ideas, suggestions and/or questions, please have a look at the Wiki pages or just mail me (or preferably the list). https://wiki.camp.ccc.de/Camp/view/Main/GimpTent https://wiki.camp.ccc.de/Camp/view/Main/GIMPDevelopersConference Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp-help2
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. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] gimp, docbook or apple trees, fruit or seeds
Daniel Egger wrote: 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. I tried to work with simple docbook, docbook, website docbook. I don't know how recent your gimp download is but this format is nothing like gimp since gimp-1.0.2. I have to stretch my imagination so much to make the format fit the gimp. I was actually going to try to substitute corpauthor for email. Do you know how deeply the email string is nested in any docbook? trust me and my recent experience, docbook was not written at all with gimp in mind. for instance, it is obvious to me that the docbook people could not imagine an app that can take its own screenshots. as much as i love gimp, i wonder if someone got their rent paid from netscape.com for making that my choice regardless. With everything else being so sensible in gimp, how come i did not get a choice that included lynx or the awesome w3m? did you know w3m renders images on xterms lately? that means it could render any screenshots gimp gets of itself for its help docs. i hate to limit the scope and imagination though, by being so disgusted with the docbook* set up. forget the work i have put into it already also. daniel, do you have something to attach to an email? like i did? snipped because i covered it here mostly 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. no this is what happened. i tried to help, asked a few questions about the logic of the template and what the tags were *supposed* to mean, and syngin decided it was quicker and easier to write the documentation without help. sorry he did not explain this before abandoning all that work. but i would like to be extremely clear about this. i am not going to waste my time contributing to docbook formated information. however, if you insist on setting the document writers up with that terrible template system again, i should be able to use the information anyways as a thoughtfully written xslt can over look the bad logic and find information there anyways. So what ever *you* commit, i can use. thanks carol also, we don't need the tree or the fruit of docbook, it is huge and the format is not good for gimp. we need just what would be a seed from this set up. the spirit of it even. heh, corpauth = email (doh!) ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] tentative GIMP 2.0 release plans
[EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) wrote: 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. is it worth building the gimp-perl module from cvs yet? carol ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp, docbook or apple trees, fruit or seeds
Hi, can we please try to avoid a flamewar about DocBook here. All our help is in DocBook, it is a well established format for this purpose. I admit that it can be quite complex but it is well documented and you usually need a small subset only. I am sure that people who want to contribute documentation can learn the necessary bits pretty fast. There are stylesheets available for transformations to all sort of formats suited for online or print publishing. IMHO it doesn't help to question the use of DocBook. There are some decisions about gimp-help that need to be made, the format for the docs is not one of them. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Preparing for 2.0 - bugzilla
Hi all, As most of you know, we are approaching a feature freeze leading up to the next stable release (I don't want to get into any fights - although I personally think 2.0 is better, I don't actually care what it's called, as long as it gets released). A feature freeze means we draw a line in the sand and say no more features get in here - after the feature freeze, there should be no changes accepted into CVS unless they fix behaviour which should work, but doesn't. So we have the problem of where (and when) to draw the line. The when is provisionally the end of camp, giving people the chance for a feature-filled weekend from the 6th to the 10th. The where is more difficult. There are currently 361 bugs open against the GIMP with either a milestone 1.3.x or milestone --. That means that currently, there are 361 tasks which people would like to see done before the next release. Many of these are small - of course, the problem is deciding which can/should be done and which can't/shouldn't. And here we come to the reason for the mail - we need help with this filtering. This is a job that anyone can do, and a few minutes of your time will allow other people a few minutes more implementing the features wanted before the freeze. What do you need to do? Well, go to http://bugzilla.gnome.org, click on the Open a new bugzilla account link, enter a valid e-mail, and you will receive a mail from bugzilla containing your password, and the link where you can log in. Once you are logged in, click on this link... http://makeashorterlink.com/?S1DF64A55 ... which will take you to a list of all bugs which currently have the milestone -- (that is, bugs which are not targetted for any release). And click on one. On the bug page, there is a drop-down box called Milestone. The milestone of every bug should be set, and the milestone of every bug with the -- milestone should be set to future, 2.0 or 1.3.x. The idea of the feature freeze is to be very brutal with these bugs. Of the 361 bugs above, 221 are enhancement requests (feature improvements). Each of these needs to be ranked in terms of importance and needs to get targetted for a future release, or closed. This is a very simple job for any given bug. As an example, bug #101256 (Improve color blindness filters), the functionality has been implemented, but has not quite been perfected. Change milestone to Future - this is not a feature which will block a stable release. The only problem is that there are so many bugs to do. So here is your chance to give a little time to the gimp, and get a warm fuzzy feeling. Guidelines for setting milestones: 1) Any bug does not block the feature freeze and should have its target milestone set to 2.0 2) Any enhancement which is not important gets milestone Future (where important is something which someone might consider crucial). 3) Important features should be milestoned 1.3.x. The problem comes with what's considered important or not. But don't get too worked up about it. 20 or 30 people receive an e-mail when a bug is changed, so that if you make a change with which someone disagrees strongly, they will let you know through bugzilla. Once this first filter is done, we will then start cutting more of the enhancement requests. If you see an enhancement and you're not sure if it's crucial or not, it isn't. Put it in Future. I really cannot overstate how much this will help us get on track for a 2.0 release soon. The second stage in the Great Enhancement Chop is to try to associate enhancements with the people who are going to code them. If no-one is going to code an enhancement, it gets cut. This is really quite easy when you get the hang of it :) So, there we go. Could people who are interested in doing this reply, just so I know what the take-up is like? Thanks a lot, Cheers, and happy gimping, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] 1.3.17 tomorrow
Hi, I announced the plan to do 1.3.17 last weekend but didn't manage to get it done. Then I wanted to do it yesterday and since that failed as well, I announced it for tonite. However since there are a few things that need to be organized for gimpcon I will again not manage to do the release. I have a tarball ready but since I believe that the 2.0 version number change needs to be outlined in the release notes, I am delaying the release until tomorrow. If someone wants to help with the release notes, I would very much appreciate a draft until tomorrow. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp, docbook or apple trees, fruit or seeds
Carol Spears wrote: Daniel Egger wrote: DocBook was written exactly for the purpose we need. as much as i love gimp, i wonder if someone got their rent paid from netscape.com for making that my choice regardless. With everything else being so sensible in gimp, how come i did not get a choice that included lynx or the awesome w3m? did you know w3m renders images on xterms lately? that means it could render any screenshots gimp gets of itself for its help docs. Actually, I'm not sure I see the benefits in not having html as the primary format... Sure, we could go for a format which allows multi-node searching (like info only better), but html docs would have the added benefit of not needing to be local and still being usable. And the user gets to choose what help client they use. And most people have a browser open all the time anyway. I'm not saying that a custom help browser is a waste of time - but do we have the time to do it? Surely starting with docbook or whatever and marking it up to html, with the possibility of doing funkier stuff later, allows us to have something, quickly? Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] gimp-perl-cvs status
On Tue, Jul 22, 2003 at 02:51:16PM -0400, Carol Spears [EMAIL PROTECTED] 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) -- -==- | ==-- _ | ---==---(_)__ __ __ 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
[Gimp-developer] Re: Gimp-developer Digest, Vol 10, Issue 34
Its still pretty bleeding edge. You'll need to get bleeding edge perl modules (which ones are documented in the gimp-perl cvs) Some stuff works, some doesn't. Its not looking likely I'll get a chance to do bring everything up to date from the plug-in side, and numerous Gtk problems still exist. Complaining about individual plug-ins probably won't help at this point... I really wouldn't recommend it for anyone not developing just yet, but you're always welcome to try. Happy GIMPing, Seth snip on the versioning squabbling is it worth building the gimp-perl module from cvs yet? carol __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
