[Gimp-developer] (no subject)
___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: patch for gimp/po/fr.po
David Odin wrote: Hi, You'll find a patch for the gimp/po/fr.po file attached to this mail. I hope this is the right list for this. Thanks, I'll commit your patch. Librement, -- Christophe Merlet (RedFox) ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: patch for gimp/po/fr.po
Hi, Christophe Merlet [EMAIL PROTECTED] writes: You'll find a patch for the gimp/po/fr.po file attached to this mail. I hope this is the right list for this. Thanks, I'll commit your patch. feel free to commit, but please commit to the stable branch (gimp-1-2). Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: current gimp status and a patch for apply_lens.
Hi, David Odin [EMAIL PROTECTED] writes: Well, at least to make the jpeg plugins to compile (and works!) again, I just had to remove the '#' in front of its definition in plugin-defs.pl. Did I miss something important? if I remember correctly, the JPEG plug-in uses a textarea which is still in the GTK+-2.0 API but declared deprecated. This needs to be ported to GtkTextBuffer/GtkTextView. We have already done this for example in the Preferences dialog. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: patch for gimp/po/fr.po
Hi, Christophe Merlet [EMAIL PROTECTED] writes: This was a patch against the HEAD branch of gimp... then I've commited to the HEAD branch... fine. I just want to take the opportunity to explain once again how we treat translations at the moment and why we do it this way. The CVS HEAD version of The GIMP is under heavy development, it changes a lot and it is not intented to be used by anyone but developers working on it. It will crash, bring down your computer, wipe your harddisk and don't tell us later, we didn't tell you. For this reason it is a waste of time to keep translations uptodate. Instead translators should focus on updating and correcting the translations in the stable branch. The plan is to have a 1.2.3 release at some point with updated translations and help files plus probably a few bug-fixes. At some point (pretty soon now), I will merge the translations from the stable branch to HEAD so your updates won't get lost. If you update HEAD, but fail to update the stable branch, chances are your work will be lost. One more thing to consider: Localisation in GIMP HEAD is considerably broken since we have to switch all the po files to UTF-8. You can create some nice crashes if you try to start GIMP from CVS HEAD with LC_ALL != C since GTK+-2.0 doesn't like to be passed invalid UTF-8 strings. The number of warnings I see when trying to start unstable GIMP with LC_ALL=fr_FR makes me one more time believe that translators don't even try their translations before committing them or asking people to commit. It would be very nice if David could create a patch against the stable version since his updates look very good and I wouldn't like to loose this work. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Thin lines using pencil
I have a problem with drawing lines with pencil. Horizontal and vertical lines are OK, but slash lines are too thick. In zoom, they look like: ### ### ## ### ### ## ### ### and IMO they should look like: ## ## # ## ## # ## ## In other words: line goes like rook in chess, but should go like queen. Why? And how to force it to go like queen? Preview lines for measure tool and for line draw are queen-like, so why actually drawn line is rook-like? In addition, Photoshop draws queen-like lines when set to non-antialiased. I have asked this question on gimp-user, but I haven't got solution. Please, help me! _ Grzes \___|___/ [EMAIL PROTECTED] (_) http://gnu.univ.gda.pl/~grzes/ 'Nam chodzi o odglos paszczowo.' 'Patataj patataj patata...' annoy echelon fbi militia bomb action president mossad delta force militia action anthrax operation fbi codes top secret /annoy echelon ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Translating The GIMP
Hi, I plan to merge translations from the stable gimp branch (gimp-1-2) to the HEAD branch very soon now and hereby ask all translators to assure that the translations in the stable branch are up-to-date. If you have committed changes to the HEAD branch, please make sure the stable branch contains your fixes, otherwise your changes will get lost. The po files in GIMP HEAD will be converted to UTF-8 since GTK+-2.0 requires strings to be UTF-8 encoded. I will check in some simple tools that allow you to convert between native encodings and UTF-8 since only few editors out there support UTF-8 directly. For now you don't have to worry about this and I will post some detailed explanations after I have completed the changes in the HEAD branch. For now, all you have to care about are the po-files in the gimp-1-2 branch. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: patch for gimp/po/fr.po
Sven Neumann wrote: One more thing to consider: Localisation in GIMP HEAD is considerably broken since we have to switch all the po files to UTF-8. You can create some nice crashes if you try to start GIMP from CVS HEAD with LC_ALL != C since GTK+-2.0 doesn't like to be passed invalid UTF-8 strings. Oups, I've forgotten to convert fr.po file to UTF-8. Sorry :-( But I'm not the one... The number of warnings I see when trying to start unstable GIMP with LC_ALL=fr_FR makes me one more time believe that translators don't even try their translations before committing them or asking people to commit. It's right, most of the time, I translate application without even trying to start the binary... I just check the validity of the file with : $ msgfmt -c --stat fr.po But this command doesn't detect bad charset encoding... Librement, -- Christophe Merlet (RedFox) ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Translating The GIMP
Hi, Karl Eichwalder [EMAIL PROTECTED] writes: It isn't up to you as the program maintainer to merge translations from STABLE to HEAD or something like that. Provide hints how translators might proceed, but please don't change contents of the files. I have always asked people not to touch po files in CVS HEAD at all. Until we change this rule, the po files are in the maintainers responsibility. Some people working on the po files don't have CVS commit access, so I can't simply ask them to do the conversion. Here is what needs to be done, so we can work out a plan how it can be done best: (1) Some new languages have been added to the stable branch. These need to be added to the unstable branch. (2) Updates to translations from the stable branch need to be merged. Merging in this context means copying the po files from the stable branch to unstable and running msgmerge on them. Since we haven't changed many strings yet, this should give reasonable results. (3) We need to handle the UTF-8 problem somehow. GTK+-2.0 solved this by keeping UTF-8 encoded po files in the tree and I do like this solution but I'm open for suggestions. But that's not a valid reason to force the translators to deal with UTF-8 if they don't want to. GTK developers think they need .mo files using UTF-8 (why?) convert them at installation time, please! what benefit does this give? Converting at installation time is not possible since we can not require the user to have the appropriate tools installed. We could do it at release time, but this wouldn't fit into the 'make dist' scheme. I see no real alternative to UTF-8 encoded po files in the tree. PO files are translators land. Maintainers don't have the right to convert them into another charset. Leave these files alone, please. as said above, I consider po files in gimp CVS HEAD maintainers land. Translators have been asked not to enter this area multiple times. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] (no subject)
Hi, How could I unsubscribe, from the GIMP mailing list? Regards, Zoltan Vranyecz ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Thin lines using pencil
On Wed, 29 Aug 2001, Simon Budig wrote: Please note, that these problems are already solved in the Gimps Paintcore. When you draw a line with the Paintbrush you will see that it is perfectly antialiased and the accumulating color problem is solved too (you can even disable this in the tool options). In fact it is this generality that creates the problems with the Pencil... Yes, paintbrush lines work well. But with my approach, I suppose both paintbrush and pencil lines would work well. Or maybe as extraordinary exception for pencils use just Bresenham? It will less general, but much neater. And implementing Bresenham is extremely simple to do. How do you all feel about it? Is it a good idea, or not? I think you will be more able to implement it and insert in proper place in GIMP's source. If would use a lot of time to analyze sources (in fact, I would have to learn how to use GIMP sources and thouroughly study it) and find this proper place, and although this I would however have doubts if this is correct place and if it does not conflict with GIMP's internal architecture, assumptions and whatever. These deep gimp internals are quite powerful and compicated. I have not yet a full clue what happens there, but it involves a lot of Subsampling, filling an area with color/patterns/brush data, mask the area with the brush mask and finally apply the result to the drawable, respecting the current selection and the current paint mode. And I guess that even this is simplified... :-) What is done when I click with pencil on image? Those complex actions are performed, and a dot is a result. What's a problem with implementing my tool_t function as just triggering all those actions on certain pixel? This certainly won't make it into the 1.2-versions of Gimp. However, I think we should attack the problem in CVS-HEAD. But please be aware, that there is *much* work to do until a first 1.3.0 release happens. :-( IMHO ugly pencil lines are a major drawback of GIMP... _ Grzes \___|___/ [EMAIL PROTECTED] (_) http://gnu.univ.gda.pl/~grzes/ 'Nam chodzi o odglos paszczowo.' 'Patataj patataj patata...' annoy echelon fbi militia bomb action president mossad delta force militia action anthrax operation fbi codes top secret /annoy echelon ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Thin lines using pencil
Hi, Grzegorz Borowiak [EMAIL PROTECTED] writes: Thank You guys. It seems drawing a good thin non-antialiased line is so foar not implemented, I hope it will be. I could do it, but it would take a long time for me to understand code and the whole conception of GIMP. right now pencil and paintbrush are exactly the same tool with the slight difference that the paintbrush calls gimp_paint_tool_paste_canvas() with BrushApplicationMode == SOFT (or PRESSURE for pressure-sensitive painting) while the pencil uses HARD here. This leads to different ways how the brush_mask is prepared. For SOFT mode the brush mask is subsampled to the brush position using a 5x5 subsampling kernel while HARD mode solidifies the brush by setting all pixels to full opacity that are non-NULL in the brush pixmap. The relevant code for painting can be found in app/tools/gimppainttool.c. There could be problem if brush size is big and line has to be half-transparent. E.g. brush radius is 10 and intensity is 0.5. There would be 1-pixel-close overlapping brush hits, whose intensities would accumulate. But this problem can easily be compensated if we use more sophiscated tool_t function, which would reasonably decrease its intensity (simply dividing nominal intensity by radius size and then by sine/cosine value of line angle) for all pixels except two ends, and these two ends would be painted with full nominal intensity, but only half of brush would be painted (this half which does not overlap with any mid-line brush hit). I don't think this would work well. Instead I'd suggest to draw the brush totally opaque to intermediate tiles, then blend these with the choosen brush opacity onto the drawable. Might be more memory-intensive but should give perfect results. On the other hand it would diverge a lot from what happens if you draw a line by hand. Would it make sense to consider a line-drawing tool? I think it would be especially useful to stroke selections and paths. Our current approaches to stamp the brush at equidistant positions along the outline does not give pleasant results and all attempts to improve this will most probably only mess up the (already weird) code. Such a line-drawing tool wouldn't work with brushes but would have configurable line-width and cap settings. I might be wrong, but I think the ink tool might be suited reasonably good for proper line drawing. If it would have support for drawing straight lines using the Shift key, we could test it and this should be easy to implement. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Thin lines using pencil
Grzegorz Borowiak ([EMAIL PROTECTED]) wrote: On Wed, 29 Aug 2001, Simon Budig wrote: Please note, that these problems are already solved in the Gimps Paintcore. When you draw a line with the Paintbrush you will see that it is perfectly antialiased and the accumulating color problem is solved too (you can even disable this in the tool options). In fact it is this generality that creates the problems with the Pencil... Yes, paintbrush lines work well. But with my approach, I suppose both paintbrush and pencil lines would work well. Or maybe as extraordinary exception for pencils use just Bresenham? It will less general, but much neater. And implementing Bresenham is extremely simple to do. As I said: I am not too familiar with the paintcore. I don't know how easy it is to remove all subsampling magic - maybe it is as easy as feeding a new set of coordinates to the paintcore. What is done when I click with pencil on image? Those complex actions are performed, and a dot is a result. What's a problem with implementing my tool_t function as just triggering all those actions on certain pixel? The Pencil is a brush based tool (try selecting another brush and you will see the difference). So it is not simply a dot as a result. It is basically the same as the paintbrush, but with a different interpretation of the mask of a brush. So implementing your scheme will break the way the paintbrush works. I think it is *way* easier to just change the way how the coordinates for the pencil are computed. This certainly won't make it into the 1.2-versions of Gimp. However, I think we should attack the problem in CVS-HEAD. But please be aware, that there is *much* work to do until a first 1.3.0 release happens. :-( IMHO ugly pencil lines are a major drawback of GIMP... I agree with you there, but we have to be very careful to determine, what is worthy enough to enter the stable series, since there already is lots of printed documentation. Changing some fundamental interna of a tool might also introduce bugs. It may be worth a try, but I doubt that this will be done in 1.2. Sorry if this sounds disappointing, but it would have been easier to introduce this if you had asked for this a year ago (or so)... Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: patch for gimp/po/fr.po
On 29 Aug 2001 10:59:06 +0200, Sven Neumann [EMAIL PROTECTED] said: One more thing to consider: Localisation in GIMP HEAD is considerably broken since we have to switch all the po files to UTF-8. You can create some nice crashes if you try to start GIMP from CVS HEAD with LC_ALL != C since GTK+-2.0 doesn't like to be passed invalid UTF-8 strings. Has this been reported as a bug in GTK? Kelly ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Thin lines using pencil
On 29 Aug 2001, at 13:55, Branko Collin wrote: [...] Think before you post, I cannot say that enough to myself. The reported 'problem' of course only happens if you use a brush that gets more transparent to its outside than in its center. It may not be solvable (and a solution might introduce other problems). Still, I think it is odd that a mostly round brush should generate different results depending on the angle of the two connected lines. Maybe it is just a matter of redefining those brushes? -- branko collin [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Translating The GIMP
Hi, Karl Eichwalder [EMAIL PROTECTED] writes: what benefit does this give? Converting at installation time is not possible since we can not require the user to have the appropriate tools installed. We could do it at release time, but this wouldn't fit into the 'make dist' scheme. release time sounds good to me. I'd recommend to modify the 'make dist' target and send a feature request to Bruno Haible. There's at least one project which goes this road since a year(?). I don't think release time is a good solution. First, we need this feature now and I don't want to require gettext from CVS. Second, we want to have useable po files in the tree all the time so gimp from CVS is useable even if LC_ALL != C. I see no real alternative to UTF-8 encoded po files in the tree. I'm all for UTF-8, but every single language team should decide when the time has come. do you really think the additional step of converting to UTF-8 before committing is too much for our translators? I don't think so. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] (no subject)
Hi, Vranyecz, Zoltan [EMAIL PROTECTED] writes: How could I unsubscribe, from the GIMP mailing list? ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer the answer is right there in your mail (check the URL above). Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: patch for gimp/po/fr.po
Hi, Kelly Martin [EMAIL PROTECTED] writes: On 29 Aug 2001 10:59:06 +0200, Sven Neumann [EMAIL PROTECTED] said: One more thing to consider: Localisation in GIMP HEAD is considerably broken since we have to switch all the po files to UTF-8. You can create some nice crashes if you try to start GIMP from CVS HEAD with LC_ALL != C since GTK+-2.0 doesn't like to be passed invalid UTF-8 strings. Has this been reported as a bug in GTK? Huh? It's not a bug, it's a feature. All strings in GTK+-2.0 are UTF-8 encoded and the application has to assure that only valid UTF-8 strings end up at the toolkit level. This is the only reasonable solution to the encoding mess and it works just perfect. It allows for example to have different languages with different native encodings in the same widget. Why do you consider this a bug? Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Thin lines using pencil
On 29 Aug 2001, Sven Neumann wrote: and IMO they should look like: ## ## # ## ## # ## ## IMO what they should look like is: # # # # # # # essentally what we do when drawing lines is we move the brush along the line and draw points in equal distances. If the point does not fall exactly on the pixel grid, it gets wider. This is bad and thin lines drawn with the pencil really look akward. A possible solution would be to implement the pencil tool totally different from the paintbrush. Instead of drawing brush pixmaps onto the canvas at equidistant spots along the line as the paintbrush does, the pencil tool could use a real line-drawing algorithm (Bresenham). This would imply that our brushes couldn't be used with the pencil tool any longer since this algorithm would only work for rounded or square pencil tips (or am I wrong here?). The problem with the 'placing overlapping brush pixmaps' approach is only really obvious at very narrow line widths. IMHO, the pencil tool should be left alone for consistancies' sake and there should be a new tool to deal with the very special case of drawing single-pixel-wide hard-edged lines. This hypothetical gadget could use Bresenham's algorithm or something like that because it wouldn't *NEED* to deal with pixmaps and need only hit pixels dead-on. I really like this idea since the old functionality of the pencil tool could be easily implemented in the paintbrush (all we'd have to do is to add a Hard edge option like the Eraser has) and having a real line-drawing tool would be a major benefit. Yes. That would work. Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation Training (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.link.com Home: [EMAIL PROTECTED] http://web2.airmail.net/sjbaker1 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Thin lines using pencil
IMHO, the pencil tool should be left alone for consistancies' sake and there should be a new tool to deal with the very special case of drawing single-pixel-wide hard-edged lines. This hypothetical gadget could use Bresenham's algorithm or something like that because it wouldn't *NEED* to deal with pixmaps and need only hit pixels dead-on. I really like this idea since the old functionality of the pencil tool could be easily implemented in the paintbrush (all we'd have to do is to add a Hard edge option like the Eraser has) and having a real line-drawing tool would be a major benefit. Yes. That would work. If you make a new line tool, which would be awesome by itself, it would also eliminate the repetitive stupid questions on gimp-user and #gimp about how do i draw a straight line AARGH! ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Translating The GIMP
Hi, Branko Collin [EMAIL PROTECTED] writes: On 29 Aug 2001, at 11:22, Sven Neumann wrote: I plan to merge translations from the stable gimp branch (gimp-1-2) to the HEAD branch very soon now and hereby ask all translators to assure that the translations in the stable branch are up-to-date. If you have committed changes to the HEAD branch, please make sure the stable branch contains your fixes, otherwise your changes will get lost. I noticed that somebody else than me has commited Dutch translations to HEAD. I tried to contact that translator once, but got nowhere. I will try again (also contacting the person who actually commited the new strings, as that was a third person), but ask in the meanwhile that the stable translation will not be merged with those changes without contacting me first, as I do not want to start juggling three different translations (the one in HEAD, the one in 1.2.2 and the one on my hard drive). whoever committed to HEAD made a mistake and it is my intention to not merge the translations but simply take the ones from gimp-1-2 into HEAD thereby overwriting any changes that have been applied to HEAD but not to the stable branch. For this reason I've asked the translators to update their translations in the stable branch now. All I want to achieve at the moment is to get a set of working translations for the 1.3.0 developers release. Those translation need not to be complete and there will be plenty of time to update the translations when we approach the stable 1.4.0 release. For the HEAD branch, we should try to find a responsible translation maintainer for each language. The language maintainer should have CVS commit access and is responsible for coordinating his/her team of translators. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Translating The GIMP
On Wed, 2001-08-29 at 15:44, Sven Neumann wrote: Hi, Branko Collin [EMAIL PROTECTED] writes: On 29 Aug 2001, at 11:22, Sven Neumann wrote: I plan to merge translations from the stable gimp branch (gimp-1-2) to the HEAD branch very soon now and hereby ask all translators to assure that the translations in the stable branch are up-to-date. If you have committed changes to the HEAD branch, please make sure the stable branch contains your fixes, otherwise your changes will get lost. I noticed that somebody else than me has commited Dutch translations to HEAD. I tried to contact that translator once, but got nowhere. I will try again (also contacting the person who actually commited the new strings, as that was a third person), but ask in the meanwhile that the stable translation will not be merged with those changes without contacting me first, as I do not want to start juggling three different translations (the one in HEAD, the one in 1.2.2 and the one on my hard drive). whoever committed to HEAD made a mistake and it is my intention to not merge the translations but simply take the ones from gimp-1-2 into HEAD thereby overwriting any changes that have been applied to HEAD but not to the stable branch. For this reason I've asked the translators to update their translations in the stable branch now. All I want to achieve at the moment is to get a set of working translations for the 1.3.0 developers release. Those translation need not to be complete and there will be plenty of time to update the translations when we approach the stable 1.4.0 release. For the HEAD branch, we should try to find a responsible translation maintainer for each language. The language maintainer should have CVS commit access and is responsible for coordinating his/her team of translators. Can I coordinate the English language? :-) Actually I should proofread the texts... Sometime you should pull English-to-English po files out of the source for me and I can proofread it. Of course committing my fixes would break any other language, so I can ahndle english-to-english po in the long term if preferred. :-) bex ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Translating The GIMP
Hi, Karl Eichwalder [EMAIL PROTECTED] writes: Sven Neumann [EMAIL PROTECTED] writes: I don't think release time is a good solution. First, we need this feature now and I don't want to require gettext from CVS. Sure, but a simple script calling iconv or recode will do it. we can not assume that iconv or recode is available on all target platforms. Second, we want to have useable po files in the tree all the time so gimp from CVS is useable even if LC_ALL != C. I don't understand this argument. I don't understand your argument either, but let me explain mine. The GIMP should work as checked out of CVS, so either we have UTF-8 po files in CVS (like GTK+ does) or we need to convert to UTF-8 during generation of the mo files. This would require the availability of the necessary tools on the build platform which we can not safely assume. IMO the easiest solution is to go for UTF-8 po files in CVS. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Translating The GIMP
Sven Neumann wrote: It isn't up to you as the program maintainer to merge translations from STABLE to HEAD or something like that. Provide hints how translators might proceed, but please don't change contents of the files. I have always asked people not to touch po files in CVS HEAD at all. Until we change this rule, the po files are in the maintainers responsibility. I do not agree. Committing PO files to HEAD in any project is always risky business (large frequent changes im messages), and time for translating is always better spent in the stable branch, if there is one. HEAD is secondary at best, and translators should know what they are doing if they touch the HEAD branch. That I agree on. But I think it's stupid to entirely forbid committing translations to the HEAD branch, if the translators know what they are doing. Why? Because of testing. Testing translations is as needed as testing code - translations for new/changed messages in the HEAD branch might be wrong, and we'd like to spot and fix those before any release. Also, having a complete or near complete translation in HEAD helps finding i18n bugs - If I know my translation is complete, a message that appears in English almost certainly indicates that a developer forgot to gettextify a message, and those bugs can be reported/patches made/fixed before a release. This is not an uncommon situation for many applications. GTK+ has/had a similar policy for HEAD - Translators were strongly encouraged not to translate HEAD. I chose to ignore that and committed an updated complete UTF-8 translation for HEAD anyway (stable is of course still my top priority). I knew about the danger of translating a rapidly moving target, and I decided that I still wanted to try it. What happened? A month later a GTK+ developer thanks me for the translation because it gave him something to test UTF-8 cleanliness in new GTK+ code with. A month later the once complete HEAD translation is at only 50% because of added/changed messages, but I knew that this would happen at some time, before I started working on the HEAD translation. But the net result is still that this GTK+ HEAD translation helped others, including a GTK+ developer. So, please, advise translators to put their efforts in the stable branch, but please don't forbid those translators that feel that they can afford it to also commit translations in HEAD. PO files are translators land. Maintainers don't have the right to convert them into another charset. Leave these files alone, please. as said above, I consider po files in gimp CVS HEAD maintainers land. Translators have been asked not to enter this area multiple times. PO files are translators' land. They maintain them. Don't touch them. The translators know the language, developers in most cases don't. Translators know what charset is best suited for the locale, and works with the translation tools they use, developers don't. If you want to maintain a translation, you are free to translate yourself¹. ;) I myself would probably convert the sv.po in Gimp HEAD to UTF-8, like in GTK+, if I was kindly asked to, and it was recommended, but I still don't want others to touch the PO file. I think I could live with having to run iconv back and forward every time I touch the file, maybe I could also live with the different charset breaking the translation memory I use. But please let me still maintain the file, and don't touch it! For the HEAD branch, we should try to find a responsible translation maintainer for each language. The language maintainer should have CVS commit access and is responsible for coordinating his/her team of translators. You've just described the GNOME Translation Project. Christian ¹ I know you are translating de.po. But that's only 1/27 of the translations. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Translating The GIMP
Hi, Christian Rose [EMAIL PROTECTED] writes: I have always asked people not to touch po files in CVS HEAD at all. Until we change this rule, the po files are in the maintainers responsibility. I do not agree. Committing PO files to HEAD in any project is always risky business (large frequent changes im messages), and time for translating is always better spent in the stable branch, if there is one. HEAD is secondary at best, and translators should know what they are doing if they touch the HEAD branch. That I agree on. But I think it's stupid to entirely forbid committing translations to the HEAD branch, if the translators know what they are doing. Why? Because of testing. I didn't forbid it, I only tried to encourage people to concentrate on the stable branch. Now I want to weaken this policy since we are approaching a developers release. I had the idea of helping translators by bringing the translations in the unstable tree uptodate with the stable tree so they have something to start with. I think I am now convinced that I shouldn't do this. The problem is however that some of our translators don't have commit access and have been promised that their translations will be added to the unstable tree when the time has come. Well, the time has come, so what am I supposed to do? Translators know what charset is best suited for the locale, and works with the translation tools they use, developers don't. well, I do know that we need UTF-8 encoded strings for GIMP since we use GTK+-2.0. IMO the best solution is to enforce UTF-8 encoding for our po files just like GTK+ does. For the HEAD branch, we should try to find a responsible translation maintainer for each language. The language maintainer should have CVS commit access and is responsible for coordinating his/her team of translators. You've just described the GNOME Translation Project. hmm, not all of our translators are part of the GNOME translation project and GIMP != GNOME. For that reason, I'd like to maintain a list of language maintainers in the GIMP source tree. If the GNOME translation project wants to take this job and thinks such a list is a waste of time, this is something we can and should consider, but it needs to be discussed. I really appreciate all the help I can get here and don't feel comfortable maintaining GIMP translations, but at the moment people send po updates to me. I'd prefer if this job could be taken by someone else and if the GNOME translation project stands up and wants the job, just tell me to whom I should send people with translation updates in the future. I would really love to be able to concentrate on real hacking again. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Translating The GIMP
R.I.P. Deaddog wrote: I myself would probably convert the sv.po in Gimp HEAD to UTF-8, like in GTK+, if I was kindly asked to, and it was recommended, but I still don't want others to touch the PO file. I think I could live with having to run iconv back and forward every time I touch the file, maybe I could also live with the different charset breaking the translation memory I use. But please let me still maintain the file, and don't touch it! There are two kind of people that commit po files into HEAD branch; one kind is so stupid that they can't even distinguish between HEAD and stable branch, and another kind knows very well what they're doing. So how about a method distinguishing these two kind of people? I don't think it has anything to do with stupidity. It's probably just that people don't know about branches and/or how to check out different branches. Every other project using its own system with branches probably doesn't help either. I guess we've all been there, not knowing how to properly use branches, unless we were born with knowledge about CVS. I have no good solution for solving this. I think that information helps though. Every translation request mail to gnome-i18n should contain information about what branch(es) to use IMHO, and if the maintainer is really worried that translations will go to the wrong branch, including instructions in the mail on how to check out the correct branch(es) probably doesn't hurt. Also, some projects use files named TRANSLATORS_READ_THIS or similar in the po directories in the wrong branch, with information about the right branch to use. It's buttugly, but effective, I think. Also, once the maintainer sees a translation go to the wrong branch, replying to the translator as soon as possible and ask if it wasn't really meant for the stable branch probably also helps. Again, I don't think this solves this problem completely, and I also suspect GIMP in particular does many of these things already, but I think it helps. For example, send a piece of email to committer/last translator. If they do reply and acknowledge/reject the overwriting of HEAD branch po files, then one knows they are still actively maintaining the file; otherwise one can safely assume the file is not actively maintained, and can be overwritten freely. Agreed, but it should be done soon after the commit. I don't think reverting a translation update because the translator happens to be away from his mail for a week some time during the summer is a good thing. But yes, I agree, Communication is King. Christian ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Thin lines using pencil
[EMAIL PROTECTED] (2001-08-29 at 1719.07 +0200): If you make a new line tool, which would be awesome by itself, it would also eliminate the repetitive stupid questions on gimp-user and #gimp about how do i draw a straight line AARGH! Xachbot is your friend, it has the URL of the tutorial. Also, would that line tool work in airbrush (or any other different to just lines) mode? If not, you still need the tutorial. And do not worry, you will get a replacement stupid question for which no tutorial has been written rather quickly. ;] GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Translating The GIMP
Sven Neumann wrote: I have always asked people not to touch po files in CVS HEAD at all. Until we change this rule, the po files are in the maintainers responsibility. I do not agree. Committing PO files to HEAD in any project is always risky business (large frequent changes im messages), and time for translating is always better spent in the stable branch, if there is one. HEAD is secondary at best, and translators should know what they are doing if they touch the HEAD branch. That I agree on. But I think it's stupid to entirely forbid committing translations to the HEAD branch, if the translators know what they are doing. Why? Because of testing. I didn't forbid it, I only tried to encourage people to concentrate on the stable branch. Ok, that sounds sensible. I misinterpreted it, sorry. Now I want to weaken this policy since we are approaching a developers release. I had the idea of helping translators by bringing the translations in the unstable tree uptodate with the stable tree so they have something to start with. I think I am now convinced that I shouldn't do this. Ok, good. The problem is however that some of our translators don't have commit access and have been promised that their translations will be added to the unstable tree when the time has come. Well, the time has come, so what am I supposed to do? Ask them. :) Ask them if they want you to do this for their translation. I think you should ask this individually, for every translator, because the responses and wishes might be entirely different. Translators know what charset is best suited for the locale, and works with the translation tools they use, developers don't. well, I do know that we need UTF-8 encoded strings for GIMP since we use GTK+-2.0. IMO the best solution is to enforce UTF-8 encoding for our po files just like GTK+ does. I'll try to stay out of the technical merits. I've been wrong before. What matters to me is that I get to decide what encoding to use in my translation. I'll be happy to take advise and recommendations, and would probably switch to UTF-8 if it helps (I'll take your word that is does), but I want the final say on what encoding to use in my translation. I believe most other translators also want this, since a charset change often breaks existing translation tools and procedures. Some people have said that gettext already supports runtime conversion. Even if this introduces a performerance penalty, I'd argue that any other decision a translator makes on how to localize the application into his locale, *also* effects the look and feel of the application. I don't see how an informed decision on charset, that possibly affects performerance, would be very much different. It affects the look/feel/performerance of the application in that locale. All this is of course given that runtime conversion works, and as I said, I've been wrong before. But I'd really like this possibility to get investigated. Forcing is bad. Encouraging is good. If you have the possibility to just encourage instead of force, I think you should do that. Christian ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Translation teams and the GTP (was Re: Translating The GIMP)
This is a rather separate thread, so I'm replying to it seperately. Sven Neumann wrote: For the HEAD branch, we should try to find a responsible translation maintainer for each language. The language maintainer should have CVS commit access and is responsible for coordinating his/her team of translators. You've just described the GNOME Translation Project. hmm, not all of our translators are part of the GNOME translation project and GIMP != GNOME. For that reason, I'd like to maintain a list of language maintainers in the GIMP source tree. If the GNOME translation project wants to take this job and thinks such a list is a waste of time, this is something we can and should consider, but it needs to be discussed. I cannot speak for all of the GNOME Translation Project (GTP; http://developer.gnome.org/projects/gtp/). However, what you described is confusingly similar to the GTP. Yes, GIMP != GNOME, but noone has to use GNOME to be a member in the GTP, nor do they have to contribute anything to GNOME at all, except the GIMP translation in this case if they want to do that. Also, GIMP uses GNOME CVS, and the GTP is basically just a collection of volunteering translators, some of them with GNOME CVS access, divided into ~40 language teams. Each team has a team coordinator that should keep track of who does what, and most teams also have at least one person with GNOME CVS access (often the coordinator), that can commit translations for their language team. So I don't see many reasons not to use this existing setup. Also, if you have trouble getting much else done besides committing translations that you recieve, I'd suggest also actively encouraging existing GIMP translators to try to submit their translations to their corresponding GNOME translation team so it can be committed that way, and only send it to you if that doesn't work. The people in the GNOME translation teams with CVS access do after all have CVS access because they should commit translations for their language. That's what they are supposed to do. :) I know there are different opinions on this, we've had an extensive debate on this in Galeon (hi Yanko! :) but IMHO this is policy that is suitable in many cases. It reduces workload for developers, and also encourages translators of the same language to work together and communicate, which in turn usually gives better translations. IMHO of course. Christian ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Translating The GIMP
Hi, OK, here's what I came up with as a (preliminary?) solution. I've added a link to the GNOME Translation Project's homepage to README.i18n and will refer all people willing to contribute to GIMP's localisation to the GTP. I'll do the same with people sending me translations and I ask everyone to do the same. The people from the GTP have CVS commit access and some coordination on the i18n front is most probably a good idea. I have added a note to README.i18n in the unstable branch explaining that GTK+-2.0 requires UTF-8 strings and that we require UTF-8 encoded po files (and tips files) for that reason. We do not do any implicit conversions so any po files that are not UTF-8 encoded will not work. If someone comes up with a reasonable way to do on-the-fly conversion, I'll consider adding it, but first I want to hear a good reason from an active translator why she thinks dealing with UTF-8 encoded files in CVS is too much of a burden. I hereby encourage translators to convert their po and tips files in gimp HEAD to UTF-8. The gnome-i18n module in CVS has some scripts that help with this task. If you feel like updating the translations in the HEAD branch, feel free to do so, but expect lots of strings to change. Your main concern should however be to finish and polish translation of stable gimp as found in the gimp-1-2 branch. I will not touch any po files except the german ones any more except for trivial fixes that break the build. Please excuse if I may have sounded harsh during this thread; I didn't want to step on anyone's feet. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
UTF8 in GTK+ 2.0 (was Re: [Gimp-developer] Re: patch for gimp/po/fr.po)
On Wed, Aug 29, 2001 at 07:58:52AM -0500, Kelly Martin wrote: In my opinion, a library which crashes when fed inappropriate external data is buggy by definition. Let's be more specific: Does the GTK+ UTF8 implementation meet the requirements for security purposes laid down in Unicode 3.0.1 and later ? How about other security considerations? Please don't reply with a cop out like The application has to handle this, that's equivalent to saying We needn't fix the bug because there's a known workaround. Conservative implementation is essential here for robustness AND security. Nick. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: patch for gimp/po/fr.po
On Wed, Aug 29, 2001 at 09:38:45PM -0500, Kelly Martin wrote: On Thu, 30 Aug 2001 10:05:15 +1000, Stephen Robert Norris [EMAIL PROTECTED] said: So it's the library's fault if I pass it a bad pointer and it causes a SEGV? Yes. Kelly I'd be interested to know how to avoid that. I'm pretty sure I can construct a scenario (with multiple threads and memory mapping, for example) where it's impossible to tell until you get the SEGV. For instance, I memory map a file, pass a pointer into the mapped region into the library and then unmap it some time later from another thread. Even if the library were checking (and I'm not sure how it could) that the pointer points to valid address space, there will be a time gap between the check and the use, and my unmapping can get in there. Having the library install its' own signal handler is not an acceptable solution, either. Stephen -- Stephen Norris[EMAIL PROTECTED] Farrow Norris Pty Ltd +61 417 243 239 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: patch for gimp/po/fr.po
Ah so it is the libraries fault that it crashes when you pass it an unterminated string? Cool. --Larry On Wed, 2001-08-29 at 07:58, Kelly Martin wrote: On 29 Aug 2001 14:44:49 +0200, Sven Neumann [EMAIL PROTECTED] said: Has this been reported as a bug in GTK? Huh? It's not a bug, it's a feature. All strings in GTK+-2.0 are UTF-8 encoded and the application has to assure that only valid UTF-8 strings end up at the toolkit level. This is the only reasonable solution to the encoding mess and it works just perfect. It allows for example to have different languages with different native encodings in the same widget. Why do you consider this a bug? In my opinion, a library which crashes when fed inappropriate external data is buggy by definition. Kelly ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Thin lines using pencil
Branko Collin wrote: If I draw several connected lines with the paint brush, the joints aren't always perfect. For instance, instead of: *** *** ** * you get: *** *** * *** ** *** * (exagerated for clarity) I don't think it is that big of a problem, because you would probably use the paintbrush more in photo like drawings than in line drawings, but maybe I am wrong about that, and this seemed a good place to mention this behaviour anyway. (Feel free to mention it is a 'feature'.) :-) Thanks for the report. I'm shocked that it has taken this long for someone to complain about this. I have commited a fix for this bug to the 1.2 branch in CVS. Jay Cox [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: patch for gimp/po/fr.po
Stephen Robert Norris wrote: Yes, this is a way the application can avoid the problem; it's not a way the library can. My point was that it's impossible with modern OS's to avoid the possibility of the library crashing. Ah, we agree then, that was the point I was trying to make as well :). Lourens ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: patch for gimp/po/fr.po
On Wed, Aug 29, 2001 at 11:22:26PM -0500, Kelly Martin wrote: On Thu, 30 Aug 2001 13:42:05 +1000, Stephen Robert Norris [EMAIL PROTECTED] said: I'd be interested to know how to avoid that. I'm pretty sure I can construct a scenario (with multiple threads and memory mapping, for example) where it's impossible to tell until you get the SEGV. For instance, I memory map a file, pass a pointer into the mapped region into the library and then unmap it some time later from another thread. Even if the library were checking (and I'm not sure how it could) that the pointer points to valid address space, there will be a time gap between the check and the use, and my unmapping can get in there. Having the library install its' own signal handler is not an acceptable solution, either. Sounds like a fundamental problem with the UNIX environment design, then. Kelly It's a fundamental problem with having pointers. If you were restricted to some sort of object references that the OS controlled (something like MONADS had, or MULTICS sort of had) then you can avoid the problem. Otherwise, it's hard to fix. -- Stephen Norris[EMAIL PROTECTED] Farrow Norris Pty Ltd +61 417 243 239 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: patch for gimp/po/fr.po
Stephen Robert Norris wrote: I'd be interested to know how to avoid that. I'm pretty sure I can construct a scenario (with multiple threads and memory mapping, for example) where it's impossible to tell until you get the SEGV. For instance, I memory map a file, pass a pointer into the mapped region into the library and then unmap it some time later from another thread. Even if the library were checking (and I'm not sure how it could) that the pointer points to valid address space, there will be a time gap between the check and the use, and my unmapping can get in there. Having the library install its' own signal handler is not an acceptable solution, either. Well, call me stupid, but isn't that what mutexes are for? Thread 1 sets the mutex, then calls the library with a pointer to some part of the shared memory. Make sure thread 2 checks the mutex before unmapping and there's no problem at all. Thing is, how is the library going to know whether the pointer is valid or not? All the standard C functions that expect pointers will happily write wherever you point them to, even if it causes a segfault. I don't see how this is a problem with the library. If I divide by zero (which is essentially calling the divide function with illegal values) I get an exception as well. Lourens ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: patch for gimp/po/fr.po
On Thu, Aug 30, 2001 at 07:34:57AM +0200, Lourens Veen wrote: Stephen Robert Norris wrote: I'd be interested to know how to avoid that. I'm pretty sure I can construct a scenario (with multiple threads and memory mapping, for example) where it's impossible to tell until you get the SEGV. For instance, I memory map a file, pass a pointer into the mapped region into the library and then unmap it some time later from another thread. Even if the library were checking (and I'm not sure how it could) that the pointer points to valid address space, there will be a time gap between the check and the use, and my unmapping can get in there. Having the library install its' own signal handler is not an acceptable solution, either. Well, call me stupid, but isn't that what mutexes are for? Thread 1 sets the mutex, then calls the library with a pointer to some part of the shared memory. Make sure thread 2 checks the mutex before unmapping and there's no problem at all. Thing is, how is the library going to know whether the pointer is valid or not? All the standard C functions that expect pointers will happily write wherever you point them to, even if it causes a segfault. I don't see how this is a problem with the library. If I divide by zero (which is essentially calling the divide function with illegal values) I get an exception as well. Lourens Yes, this is a way the application can avoid the problem; it's not a way the library can. My point was that it's impossible with modern OS's to avoid the possibility of the library crashing. Stephen -- Stephen Norris[EMAIL PROTECTED] Farrow Norris Pty Ltd +61 417 243 239 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
