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 always
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
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 new
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 lengths you
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
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 worth
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
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... there
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 remaining
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 be
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 strictly
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,
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
indentation
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 lines
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, 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.
No,
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
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
possible.
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 entries.
Why
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 standard vim
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
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
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
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
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
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 (invalid
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
29 matches
Mail list logo