___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
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
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
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
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
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:
##
##
#
##
##
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
[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.
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
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
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
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
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
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
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:
***
***
* ***
**
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
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)
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
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.
38 matches
Mail list logo