Re: [Gimp-developer] gimp perl.
Hi, Joao S. O. Bueno wrote: How is the parasite editor doing? I will be needing it soon - in 1.3. A generic C based one is an enhancement request open in CVS, and is up for grabs. The gimp-perl one will be available as soon as gimp-perl is. 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
Re: [Gimp-developer] gimp, docbook or apple trees, fruit or seeds
Hi, Carol Spears [EMAIL PROTECTED] writes: you and I are scheduled to discuss this after camp. if you continue to insist to reply to my mail, i will continue to insist that you stick to *your* scheduled time for this discussion. I said that I want to wait till after the camp before I take a closer look at the XML format for plug-in infos that you are designing. This seems to be definitely a post-2.0 thing and if you need me to look at it, it will have to wait a bit. The format we use for writing our help pages is a completely different topic and I would welcome if you would try to keep them distinct. If I am wrong about this being a different topic, this may be because you never explained what you are actually doing with this plug-ins XML file that you are working on. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: gimp, docbook or apple trees, fruit or seeds
Am Die, 2003-07-22 um 20.47 schrieb Carol Spears: 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. How so? I was actually going to try to substitute corpauthor for email. Do you know how deeply the email string is nested in any docbook? Yes, I know but this is for a purpose. You could also put this information (except it's mandantory) in a normal paragraph; however you don't have the type information in the transformation process later in case you could make some use of it -- like print the Author's name (without emailaddress) on the bottom of every page in the document. trust me and my recent experience, docbook was not written at all with gimp in mind. It was written with documentation in mind which is exactly what we need; I wouldn't use it as a fileformat for images at all. for instance, it is obvious to me that the docbook people could not imagine an app that can take its own screenshots. They didn't design this (because it *IS* overkill) but you can certainly express it using the given hooks. 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 cannot imagine how this auto-screenshot feature is supposed to work; but given that one can do anything within the bounds of imagination and knowledge I cannot see why it wouldn't i hate to limit the scope and imagination though, by being so disgusted with the docbook* set up. I can write up a installation documentation for docbook + compilation of xsltproc in less that 10 comprehensible lines... Remember we're not talking about DocBook/SGML anywork -- that's a disgusting piece of work. daniel, do you have something to attach to an email? like i did? What did you have in mind? 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. The tags are selfexplanatory, the meaning of them is nicely covered (with examples) in the DocBook-book (the duck book). We're not *requiring* any of them execept the structural ones (sects, paras, chapters) however: the more the better. 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. See, I already offered to take content in *any* and enrich it using the appropriate tags. Why? Because I'm not an good content writer because I'm not creative enough. I know how to deal with DocBook, XML and XSLT pretty well though. Again: If you want to write, *do it*, send it to me *in any format convenient for you* and I will merge the pieces. And believe me that I won't say it another time because I'm starting to get sick of people who claim wanting to write docs but at the same time complain about the format and thus have a poor excuse why they cannot also, we don't need the tree or the fruit of docbook, it is huge and the format is not good for gimp. Okay, propose a better (XML-) format, write a DTD (yet better also a Schema) *and* XSLT transformation into at least (X)HTML and PDF and I'll call it a deal. Just tell me how long you need... -- Servus, Daniel signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [Gimp-developer] gimp-perl-cvs status
[EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) 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. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Bug triage guides
Hi, I just found this page... http://developer.gnome.org/projects/bugsquad/triage/ ...which explains the ideas behind filtering bugs. It's actually quite a simple explanation, and applies quite well to the gimp when you substitute #gimp for #bugs :) Anyone who wants to contribute to the gimp bug triage, but who doesn't have permission to change milestones, please mail me, and I will either get you sorted, or give you a list of people who can change milestones (more likely the former). Be warned, the pointy stick approach will be in effect - if you make changes that you shouldn't (for example, to bugs in other products than the gimp), you will lose your rights. 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
Re: [Gimp-developer] gimp, docbook or apple trees, fruit or seeds
David Neary wrote: 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. my layout is aimed first at html and second at LaTeX. I want a choice of browsers. I think it is easy to make a plugin that calls from a list of available browsers. i think this discussion is really stupid. you could actually tuck the source code to the w3m with the image rendering ability into the documentation and probably no one would know the difference sizewise, especially if you insist on all those stupid levels of tags in the layout. but it is easy for gimp to find the browsers i have installed and add them to a menu. so i really am not going to be following this thread anymore. thanks for the time and thought you all spend writing this crap to the list. carol ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] tentative GIMP 2.0 release plans
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 ___ 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
Am Die, 2003-07-22 um 21.57 schrieb David Neary: 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. What do you mean by not needing to be local? The problem is exactly that the filenames have to be known in advance so we can link to them; this means that for HTML the files have to be in a known place (defined at compile time) and there has to be a mapping. And the user gets to choose what help client they use. There's no problem at all using a normal browser to read the full docs in HTML format. It simply doesn't make a whole lot of sense to me trying to remote control a browser to feed it with correct links while at the same time having the problems that - a webbrowser is by design not the optimal tool to view online help while working with the application - a webbrowser cannot provide fulltext search over all documentation since it doesn't see the whole text at once 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? That's exactly my point. Sorry to be negative here but I have the very strong feeling that we will not get gimp-help-2 into adequate shape until the projected date of release of GIMP 2.0 and as such it doesn't make a whole lot of sense to me to bend over trying to somehow get the transformation and the help-browser in place because it's a waste of precious time when not knowing that it'll be used for a longer period of time. The explanation I proviced about displaying HTML instead of DocBook directly (still just for the online help!) should show why this an inferior solution. I've a few more points in case someone wants to discuss it over, but for me there's no point in supporting a quick hack instead of a proper long term solution which the HTML one simply cannot be, at least not in this form, and I haven't heard of a better one yet. -- Servus, Daniel signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
[Gimp-developer] Re: gimp, docbook or apple trees, fruit or seeds
Daniel Egger wrote: Am Die, 2003-07-22 um 20.47 schrieb Carol Spears: 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. How so? this time, i got stuck and pissy when i tried to attach the author email to the authors name. these damn developers keep making babies and such. if they volunteer for writing gimp plugins, they should not need an affiliation to deliver an email addy. my little layout has a resume area. you can put whatever you want there except for an affilitation. and if you are as creative with my layout as you need to be with docbook, you can actually work this information in. I was actually going to try to substitute corpauthor for email. Do you know how deeply the email string is nested in any docbook? Yes, I know but this is for a purpose. You could also put this information (except it's mandantory) in a normal paragraph; however you don't have the type information in the transformation process later in case you could make some use of it -- like print the Author's name (without emailaddress) on the bottom of every page in the document. a layout and dtd made for gimp by people who use gimp and need for gimp to document itself and such would be useful for many many applications, i guess. i am sick of working with choices that were not made for me. the older i get, the more i need to come up with the answer that work bests and avoid the real answers. working with docbook and gimp information is just like this for me. first the extra reaching (to include the information we need) and then how hard it is to grab the information back out. this is too much like real life broken-ness. where is syngin, btw. you write this as a layout designer. i am writing as someone who tried to actually contribute content with it. i tried to make sensible web site information out of it. syngin would have far more to contribute to any discussion about everyday use and handling volunteers with it. i think syngin is depressed and gone. i am so sorry about that. i blame docbook and sgml layouts for this, unless i hear something else about it. your hearsay about usage, my hearsay about being depressed and quitting. trust me and my recent experience, docbook was not written at all with gimp in mind. It was written with documentation in mind which is exactly what we need; I wouldn't use it as a fileformat for images at all. okay. GNU/Image Manipulation Program. gimp can write most of this stuff himself. i however will not hook my gimp up to a docbook spew. i have better things to do. for instance, it is obvious to me that the docbook people could not imagine an app that can take its own screenshots. They didn't design this (because it *IS* overkill) but you can certainly express it using the given hooks. i think i needed more coffee when i wrote this. actually, the screenshots should be easy with gimp, but not with gimp-1.2. i made the unfortunate mistake of starting the mmmaybe resource images with the palettes. palettes don't go to the pdb that way for gimp-1.2. neither do gimp-impressionist resources. i got discouraged. 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 cannot imagine how this auto-screenshot feature is supposed to work; but given that one can do anything within the bounds of imagination and knowledge I cannot see why it wouldn't well, you can download the gimp-web module. my crappy little resource making python scripts make brush images and the html surrounding it. it could just as easily be LaTeX mark up or sgml or xml or cmsl or whatever. gimp just types what he is told to. if he types xml, then i can make it read the urls from one place and it doesn't matter if the url is to a local file or an away site. maybe it is too simple and you need to be an idiot to use these tools. and i am asking way too much from gimp-developer geniuses. i hate to limit the scope and imagination though, by being so disgusted with the docbook* set up. I can write up a installation documentation for docbook + compilation of xsltproc in less that 10 comprehensible lines... Remember we're not talking about DocBook/SGML anywork -- that's a disgusting piece of work. cool. you will then proceed to author the information and tell others how to author it? awesome! this is a huge job and someone needs to do it. daniel, do you have something to attach to an email? like i did? What did you have in mind? work
Re: [Gimp-developer] gimp perl.
Joao S. O. Bueno wrote: On Wednesday 23 July 2003 1:49 am, Seth Burgess wrote: 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. How is the parasite editor doing? I will be needing it soon - in 1.3. Happy GIMPing, Seth snip on the versioning squabbling is it worth building the gimp-perl module from cvs yet? carol parasite editing is easy. save as jpeg. edit in the save dialog. my gallery scripts write a comment without me thinking about it. carol ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp-perl-cvs status
[EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) wrote: 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) 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 ___ 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
Am Die, 2003-07-22 um 21.03 schrieb Sven Neumann: usually need a small subset only. I am sure that people who want to contribute documentation can learn the necessary bits pretty fast. Or even better: Don't need to... -- Servus, Daniel signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [Gimp-developer] gimp-help2
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... -- Servus, Daniel signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [Gimp-developer] gimp, docbook or apple trees, fruit or seeds
Hi, Daniel Egger [EMAIL PROTECTED] writes: That's exactly my point. Sorry to be negative here but I have the very strong feeling that we will not get gimp-help-2 into adequate shape until the projected date of release of GIMP 2.0 and as such it doesn't make a whole lot of sense to me to bend over trying to somehow get the transformation and the help-browser in place because it's a waste of precious time when not knowing that it'll be used for a longer period of time. I think we could get the framework done for 2.0 and fill in the content when 2.0 is out. The help files are supposed to be distributed separately anway so I don't see the long period of time you are speaking of. The explanation I proviced about displaying HTML instead of DocBook directly (still just for the online help!) should show why this an inferior solution. I've a few more points in case someone wants to discuss it over, but for me there's no point in supporting a quick hack instead of a proper long term solution which the HTML one simply cannot be, at least not in this form, and I haven't heard of a better one yet. I tried to outline one. Should I try to explain it again? 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
Hi, Kelly Martin [EMAIL PROTECTED] writes: 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 am not afraid of such comparisons. Competition can only improve things and I would love to see a list of the things that PS7 does better than GIMP. I am not claiming that GIMP is superiour, I would vote for calling it GIMP-8.0 if that was the case. 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. The ball is rolling now and any further discussion about it is only hurting GIMP's reputation. 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
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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: gimp, docbook or apple trees, fruit or seeds
Am Mit, 2003-07-23 um 16.41 schrieb Carol Spears: [ mail stripped down to points that haven't been answered a gazillion times... ] a layout and dtd made for gimp by people who use gimp and need for gimp to document itself and such would be useful for many many applications, i guess. Don't guess, do it! It's an awful lot of work and needs experienced people who can design a DTD for such a complex application, write it down in the correct syntax and last but not least one needs transformations otherwise all that can be done is walking in the trees... i am sick of working with choices that were not made for me. After some consideration I removed my intended answer where is syngin, btw. you write this as a layout designer. I'm no layout designer, I just have some real-life experience in building documentation systems. i think syngin is depressed and gone. i am so sorry about that. i blame docbook and sgml layouts for this, unless i hear something else about it. Mel worked with me quite a lot on the docs and he never signalled any signs of unsolvable problems. Also he did all the files he commited all on his own and surprised me quite a few times with high quality DocBook sources, not just in content but especially in markup! your hearsay about usage, my hearsay about being depressed and quitting. I've instructed more than 10 people in DocBook. No one ever complained. okay. GNU/Image Manipulation Program. gimp can write most of this stuff himself. Interesting. How come I didn't notice? :) What are you talking about? i think i needed more coffee when i wrote this. actually, the screenshots should be easy with gimp, but not with gimp-1.2. i made the unfortunate mistake of starting the mmmaybe resource images with the palettes. palettes don't go to the pdb that way for gimp-1.2. neither do gimp-impressionist resources. i got discouraged. ??? cool. you will then proceed to author the information and tell others how to author it? awesome! Sure. will you forward all the mail if whatever information scooper interested parties use doesn't scoop from information that deeply nested? Sorry, sometimes I really have trouble parsing your sentences... i have not really had a chance to look to what is required and not required in that twisted mess (docbook). Get the DocBook book from the internet, check it online or even buy the book if you prefer it in printed form. It'll tell you how to do the stuff you want to do and what is required for it to work *including* examples. See, I already offered to take content in *any* and enrich it using the appropriate tags. Why? Because I'm not an good content writer because I'm not creative enough. I know how to deal with DocBook, XML and XSLT pretty well though. this tells me that you would have no problem skipping docbook. it is an unnecessary step. It's NOT! XML alone won't let you do dick, you need a DTD which gives it a meaning and this is DocBook in our case. I wouldn't have a problem with any other DTD but you have failed to show me one which provides: a) all documentation facilities we need b) corresponding XSLT stylesheets In fact you just claimed it would be easy to design a designated DTD just for GIMP documentation but so far haven't backupped this claim. my format is posted publically. i am scheduled to discuss it after camp. i am thinking about scheduling Neditcon1 for the same week, i dunno yet. You're going to Berlin? Maybe I can stop by for a few hours since I'll probably be in town this week. you can look at that and comment. I'd like to, where did you say can one pick it up? please, do not start this shit on the gimp-user list! I will ask on the gimp-users list for volunteers to write DocBook documentation (actually because I've been asked to do so). This thread here never was intended as a flamewar I still don't see it as one; a lot of FUD and unfounded information was spread in a thread that started (and still continues) as a quite informative one. Set your facts straight or simply back up and this will be forgotten. -- Servus, Daniel signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [Gimp-developer] tentative GIMP 2.0 release plans
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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] tentative GIMP 2.0 release plans
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. -- 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] Re: tentative GIMP 2.0 release plans
[EMAIL PROTECTED] (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
___
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, Kelly Martin [EMAIL PROTECTED] writes: 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. You must be having a hard day or something or you wouldn't have interpreted _this_ into my words. I do care about your opinion. I am only saying that the version number change has happened and that we should try turn towards the future. Pointing out what features you miss most is a good start and that is why I asked which features make you prefer PS7 over GIMP. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp-perl-cvs status / wingimp
On Wed, Jul 23, 2003 at 09:47:37AM -0400, Carol Spears [EMAIL PROTECTED] 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. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] gimp, docbook or apple trees, fruit or seeds
Sven Neumann wrote: Hi, Carol Spears [EMAIL PROTECTED] writes: you and I are scheduled to discuss this after camp. if you continue to insist to reply to my mail, i will continue to insist that you stick to *your* scheduled time for this discussion. I said that I want to wait till after the camp before I take a closer look at the XML format for plug-in infos that you are designing. This seems to be definitely a post-2.0 thing and if you need me to look at it, it will have to wait a bit. The format we use for writing our help pages is a completely different topic and I would welcome if you would try to keep them distinct. If I am wrong about this being a different topic, this may be because you never explained what you are actually doing with this plug-ins XML file that you are working on. are you begging to change your scheduled time to discuss this with me? i am really so busy. carol ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp-help2
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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp-perl-cvs status
[EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) wrote: 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) 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp-perl-cvs status / wingimp
[EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) wrote: On Wed, Jul 23, 2003 at 09:47:37AM -0400, Carol Spears [EMAIL PROTECTED] 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 ___ 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
Daniel Egger wrote: Am Die, 2003-07-22 um 21.57 schrieb David Neary: 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. What do you mean by not needing to be local? The problem is exactly that the filenames have to be known in advance so we can link to them; this means that for HTML the files have to be in a known place (defined at compile time) and there has to be a mapping. I may be missing the point, but if you use relative paths for linking, there wouldn't be a problem, would there? In any case, I bow to your greater knowledge :) I really know very little about documentation mark-up. - a webbrowser is by design not the optimal tool to view online help while working with the application - a webbrowser cannot provide fulltext search over all documentation since it doesn't see the whole text at once I understood that docbook2html xslt was out there, and that there were utilities that did docbook to pdf, html or text fairly easily. until the projected date of release of GIMP 2.0 and as such it doesn't make a whole lot of sense to me to bend over trying to somehow get the transformation and the help-browser in place because it's a waste of precious time when not knowing that it'll be used for a longer period of time. The explanation I proviced about displaying HTML instead of DocBook directly (still just for the online help!) should show why this an inferior solution. I've a few more points in case someone wants to discuss it over, but for me there's no point in supporting a quick hack instead of a proper long term solution which the HTML one simply cannot be, at least not in this form, and I haven't heard of a better one yet. It's clear that I don't understand the problems involved, so as I said before, as far as deployment goes, I bow to your better judgement. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
