On Tue, 22 Feb 2000, [EMAIL PROTECTED] wrote:
> On 22 Feb, Manish Singh wrote:
> > True, although we have a couple other inconsistencies already. The
> > coding style needs to be the same as the rest of gimp though.
>
> I tried to bring it as near as possible. Of course a lot things could
> be
On 22 Feb, Raphael Quinet wrote:
> I did not like the GNU style at first (especially the space before the
> opening parenthesis) but now I understand that it is very important
> to keep a consistent coding style in each project, because it keeps
> the code manageable and maintainable. So I alway
Raphael Quinet said...
|
|I did not like the GNU style at first (especially the space before the
|opening parenthesis)
I still don't. Two spaces just isn't enough. Three
or four is much better. And I like space before the
paren only if it isn't after a function or procedure
name.
|but now I u
Hi,
> This idea will cirumvent most of the problems which gettext alone
> just can't deal with. It's little and as such not very likely to
> introduce many new bugs.
With the usage of static array and buffer lengths you demonstrated in
your patch it will most likely introduce one or two n
On Tue, Feb 22, 2000 at 10:50:55AM +0100, Sven Neumann wrote:
> Hi,
>
> > This idea will cirumvent most of the problems which gettext alone
> > just can't deal with. It's little and as such not very likely to
> > introduce many new bugs.
>
> With the usage of static array and buffer length
This is the first version on the 3.1 (development) series. It is
available at http://gimp-print.sourceforge.net. In addition to the
plug-in for the Gimp, the same source base is used as the nucleus of a
GhostScript driver to support Epson Stylus printers.
Gimp developers, should I send these an
On 22 Feb, Sven Neumann wrote:
> With the usage of static array and buffer lengths you demonstrated in
> your patch it will most likely introduce one or two new bugs, but
> that could easily be hacked up a little cleaner
Of course I could have used a linked list, but I'm not sure if
it's wort
On 22 Feb, Manish Singh wrote:
> True, although we have a couple other inconsistencies already. The
> coding style needs to be the same as the rest of gimp though.
I tried to bring it as near as possible. Of course a lot things could
be better
> It's not that much code, and does fix a gap
On Tue, 22 Feb 2000, Sven Neumann wrote:
> I also don't like the format of the localerc you proposed since it doesn't
> look like the other files in ~/.gimp-1.1. Why not use the scheme-like
> syntax people are used to use and that the gimp can parse anyway?
I agree strongly with this... ther
On 22 Feb, Sven Neumann wrote:
> With the usage of static array and buffer lengths you demonstrated in
> your patch it will most likely introduce one or two new bugs, but
> that could easily be hacked up a little cleaner
Okay, I took some of the comments and updated the files.
I'm now using a
[EMAIL PROTECTED] wrote:
> Hi developers,
>
> as you might know that gettext solution works quite nice for
> GIMP itself but may cause trouble with plugins. To circumvent
> the problem that every plugin must have it's domain registered
> within the GIMP source, I'll offer you a new idea here:
On Tue, Feb 22, 2000 at 02:59:18PM +0100, Raphael Quinet <[EMAIL PROTECTED]> wrote:
> scripts and, to a lesser extent, the Perl scripts. Is there a
> recommended style for these?
Yes, just copy mine ;)
For perl-only-syntax-questions, the reference should be "perldoc
perlstyle". All the remaini
On Tue, Feb 22, 2000 at 10:50:55AM +0100, Sven Neumann <[EMAIL PROTECTED]>
wrote:
> I'm not yet convinced that this goal is worth all the hassle. What do
> other people on this list think about this?
Being able to add plug-ins with i18n support is _extremely_
important. Unless the release would
Hi,
> While we are on the subject of coding style, there are two areas of
> the Gimp that are not using a consistent coding style: the Script-Fu
> scripts and, to a lesser extent, the Perl scripts. Is there a
> recommended style for these?
Oh well, there are more areas. Not even the core strict
On Tue, Feb 22, 2000 at 03:56:44PM +0100, [EMAIL PROTECTED] wrote:
> Okay, will turn from the Standard vi indention into GNU coding style.
"Standard vi indentation" is fine. Just follow the GNU coding style on
when to indent, and when not (and when to add spaces, when not...) ;)
The idea, howev
On 22 Feb, Marc Lehmann wrote:
> "Standard vi indentation" is fine. Just follow the GNU coding style on
> when to indent, and when not (and when to add spaces, when not...)
> ;)
Uhm, I use vim and vim uses tabs by default and doesn't indent
the { after an if like GNU suggests. Du you have work
Hi,
well there seems to be a consensus that your changes make sense.
I have however a few questions about the implementation:
You want the plug-ins to register their domain and a path to the
catalog. If I understand you correctly, this is done by calling
gimp_domain_add () in the query function
On 22 Feb, Sven Neumann wrote:
[ ... many thought about localerc deleted ... ]
Well, you are right in all your points. I just decided
to use a new file because I don't need much functionality
and therefore could keep it simple as well as the functions
in GIMP and libgimp to deal with it.
> Uhm, I use vim and vim uses tabs by default and doesn't indent
> the { after an if like GNU suggests. Du you have working settings to
> achieve this?
I don't know if this will be useful at all, but the GNOME Programming
Guidelines has a snippet for .vimrc to set the Linux kernel
indentati
Hi,
> [ ... many thought about localerc deleted ... ]
>
> Well, you are right in all your points. I just decided
> to use a new file because I don't need much functionality
> and therefore could keep it simple as well as the functions
> in GIMP and libgimp to deal with it.
IMHO adding line
On Tue, Feb 22, 2000 at 07:59:21PM +0100, [EMAIL PROTECTED] wrote:
> Uhm, I use vim and vim uses tabs by default and doesn't indent
vim, like vi and emacs, has a manual and can be configured quite freely ;)
> the { after an if like GNU suggests. Du you have working settings to
> achieve this?
On 22 Feb, Sven Neumann wrote:
> IMHO adding lines into the pluginrc is much easier than to add
> code to parse another file.
Well, my code is there, now you'll have the chance to prove that
this assertion is true, I don't think so BTW after thouroughly
studying the code.
> Which just means
On 22 Feb, Marc Lehmann wrote:
> vim, like vi and emacs, has a manual and can be configured quite
> freely ;)
Yes, I read the manual and tried a whole hour to get it the GNU
way but I couldn't manage to get that.
> set formatoptions=croql cindent cinkeys={,},:,0#,!^F,o,O,e
> cinoptions={.5s,}
On 22 Feb, Federico Mena Quintero wrote:
> I don't know if this will be useful at all, but the GNOME Programming
> Guidelines has a snippet for .vimrc to set the Linux kernel
> indentation style.
This is the standard vim style.
> If you tweak it a bit it may work for GNU indentation style.
I was just looking over some of the additions to libgimp, and had a few
comments about the colorspace functions...
This style:
void gimp_rgb_to_hsv (gint *red /* returns hue */,
gint *green /* returns saturation */,
gint *blue /* returns value */);
On Tue, Feb 22, 2000 at 11:54:03PM +0100, [EMAIL PROTECTED] wrote:
> Well, that the thing I'm talking about.
> I tried this options and think that it doesn't match it very good.
> After the first { of a function the source isn't indented for example.
Then, most probably, you have a very very
On Tue, Feb 22, 2000 at 03:24:44PM -0800, Kevin Turner <[EMAIL PROTECTED]>
wrote:
> is, do you use three seperate buffers, or a single buffer like RGB data
> is commonly in? I am not sure of this one-- people will surely want
> rgb data in one buffer, but my experience suggests that if you are
> > If you tweak it a bit it may work for GNU indentation style.
>
> No, unfortunately I couldn't get vim used to GNU indention style.
>
> > Please tell me if this works or if you had to change something; I'd
> > like to keep that part of the programming guidelines as accurate as
> > pos
Hi,
> > Actually I don't see hundreds
> > of internationalized plugins in addition to the ones that come with
> > gimp
>
> But even those will have their own entry. One entry per plugin.
> Considering the amount of plugins we ship with GIMP nowadays this
> would alone lead above hundred entr
On 22 February, 2000 - [EMAIL PROTECTED] sent me these 0.6K bytes:
> On 22 Feb, Federico Mena Quintero wrote:
>
> > I don't know if this will be useful at all, but the GNOME Programming
> > Guidelines has a snippet for .vimrc to set the Linux kernel
> > indentation style.
>
> This is the stan
Hi,
I have thought about the problem a little more and there's one
question that has not been addressed until now. How should the
plugin now where its mo-file will be installed? If we want to
stay with the existing procedure that the plug-in may be
installed in a configured list of paths, it do
On 23 Feb, Marc Lehmann wrote:
> Then, most probably, you have a very very old or broken version of vim
> (or maybe you use another editor, or vim in vi-emulation mode).
Actually it's the latest stable version of vim.
> The whole point of these options is to make indentation automatic and
> mor
On 23 Feb, Sven Neumann wrote:
> The current solution for the plugins
> distributed with The GIMP works reasonably good.
Really? I wouldn't call "we have to pre-add the menuentries to GIMPs
core source otherwise it wouldn't work" working good. Actually my
patch doesn't really address those pr
I did a 3.0.7 this evening, and then decided to port a few of the
juicier GUI features over from the mainline (specifically the
separation of printrc save from cancel and print, the positioning
entry boxes, and the correct sizing computations), so I quickly did a
3.0.8. I sent Sven the patches fr
On 23 Feb, Sven Neumann wrote:
> The core would then have to try to bindtextdomain() to all
> possible paths until success (or total failure if no message
> catalog was found).
You can't find out whether bindtextdomain failed or not. The only
way to get the information whether a catalog is ava
I'm getting a crash in gimp when trying the Outline tutorial from
http://www.obscurasite.com/artstuff/tutorials/gimp-text-outline/
When doing the Edit Stroke command : (brush selected circle 3).
/usr2/gimp/bin/gimp: fatal error: sigbus caught
/usr2/gimp/bin/gimp (pid:1152): [E]xit, [H]alt, show
I'll be away from now until March, 13. Chances are low that I will be able
to answer mail during that time.
If you visit the CeBIT, be sure to meet me at the Linux international
booth, and stay away from non-free software! If you don't come to the
CeBIT, consider visiting the 2nd German Perl-Wor
Hi,
Let's say I have 2 images, and one is RGB, and the other is indexed. If I drag
a layer from the RGB image to the indexed image, the RGB bit gets converted to
indexed. I am not saying this is a bug, but it would be nice to be warned about
it, with a 'don't tell me this ever again' button on the
On Tue, Feb 22, 2000 at 09:37:28PM +0100, [EMAIL PROTECTED] wrote:
> Hiho tigert,
>
> Can you still reproce bug #6444 or is it like the
> others I recently merged together with this one, fixed?
Yes, my gimp is built on Feb 22th from CVS.
I get this gdk error:
Gdk-ERROR **: BadDrawable (inval
Targa files have no magic header, and cannot be reliably identified that way.
The TGA plugin tried to register some nonsense magic string which didn't work
anyway, and any attempt to load a TGA file without explicitly selecting the
load format will usually cause gimp to handle it as a group 3 fax
40 matches
Mail list logo
