On Wed, Feb 02, 2000 at 01:31:28AM +0100, [EMAIL PROTECTED] wrote:
There are fantastic parsers available, no need to write any of those.
I'm not talking just parsers! A parser does exactly that -- it parses. You'd
still have to write handlers etc. for all the tags.
That's the hitting point,
Daniel, do you know how to modify the Makefiles to do that, and where
a good place to store these files is (probably just besides the .mo
files)? There must be a simple way to find them though (a gimptool switch,
maybe)?
Sven??
Sorry, Gimp-1.2 first.
Salut, Sven
Hi,
Before you start to go crazy about post-1.2 i18n issues,
wouldn't it be nice to first clean up the situation for
gimp-1.1 a bit? I'm speaking about the UI and translation
of the perl plug-in.
The po directory has a totally different mechanism for
storing and building the po and mo files
Hi,
I have some experience documenting the C/C++ source of a project. For
the DODS project (http://unidata.ucar.edu/packages/dods) I use a
package called doc++ which is barely supported, but works well. Doc++
has a home page, and we support a slightly modified (i.e. debugged)
version of
On 2 Feb, Steinar H.Gunderson wrote:
In my illusion at least making tags from events and the
way back should be simpler...
The problem with Perl is the parsing step, not the recording step. We
already have well-working code for parsing/running Perl.
That sentence doesn't make a lot of
On 1 Feb, Marc Lehmann wrote:
Your:
"
Category New File
"
Looks IMHO much worse than the existing:
"
Category New File Settings
"
Not really, you have the word "Preferences" just a few mm above it.
Also there was some inconsistency: The category "Monitor Information"
On 2 Feb, Marc Lehmann wrote:
Well, yes, but I guess they wouldn't want to translated them
themselves, so why personal i.e. with catalog in the home directory?
Because it's the only user-writable place on a machine. I only talk
about installing plug-ins _seperately_ from the gimp.
[EMAIL PROTECTED] (Sven Neumann) writes:
Hi,
I have some experience documenting the C/C++ source of a project. For
the DODS project (http://unidata.ucar.edu/packages/dods) I use a
package called doc++ which is barely supported, but works well. Doc++
has a home page, and we support a
On Tue, 1 Feb 2000, Raphael Quinet wrote:
Well, although it is a kludge, I like it. I think that it would be a
good idea to implement this in Gtk (and if possible, in the 1.2.x
branch). It would not be hard to do: replace all 0xA0 bytes with the
normal space character 0x20 before drawing
Here some performance tests on an Intel Celeron 333 with 128 MB:
BMP file, grayscale (8-bit), 1x7500
loading with ImageMagick 5.1.1: 20 min
loading with GIMP 1.1.15: 10 min
loading with Photopaint 8: 1 min 39 sec
loading with Photoshop 5: 14 sec
saveing with GIMP 1.1.15: 2 min 25 sec
On 2 Feb, Sven Neumann wrote:
/**
* gimp_size_entry_new:
* @number_of_fields: the number of entries
* @unit: the default unit
* @unit_format: a pointer to a format string describing the unit
The good thing is that gtk-doc checks that the documentation and the
source are in sync and
On 2 Feb, Sven Neumann wrote:
Well, does it support the GTK+ object system like gtk-doc does? I
guess not and that's why I suggest that we stop discussing what tool
to use since I doubt we will find something better suited to our
needs.
It supports crossreferences, what else do you want?
ImageMagick has import / export filters for fpx (only import), pbm,
pict and ttf. I think we should include this fileformats also for GIMP
This is probably a generic automake/pgcc problem, but it's exhibiting
itself with the GIMP first, so here it is:
config.guess from CVS is failing for me since it doesn't recognize
my ld supported emulations. I'm using pgcc 2.95.3, and ld is:
GNU ld version 2.9.5 (with BFD 2.9.5.0.24)
The
[EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
On 1 Feb, Marc Lehmann wrote:
Your:
CategoryNew File
Looks IMHO much worse than the existing:
CategoryNew File Settings
Not really, you have the word "Preferences" just a few mm above it.
Also there was some inconsistency: The
Just wanted to let you guys know that I wrote up a story
on advogato.com you guys might want to read for a good
laugh:
http://advogato.com/
'Andover.Net and the deep pockets of Wilber the GIMP?'
-Shawn
--
Shawn T. Amundson [EMAIL PROTECTED]
Research and Development
On Wed, Feb 02, 2000 at 02:25:10PM +0100, [EMAIL PROTECTED] wrote:
That sentence doesn't make a lot of sense to me. I agree that we've got
well-working code for parsing/running Perl, well, that's Perl :)...
Yes, exactly.
The `problem' with Perl is that it can be amazingly complex at times.
On Wed, Feb 02, 2000 at 03:05:30PM -0500, Tom Rathborne [EMAIL PROTECTED] wrote:
This is probably a generic automake/pgcc problem, but it's exhibiting
itself with the GIMP first, so here it is:
Slow, slow... _what_ is breaking? What are you compiling?
my ld supported emulations. I'm using
On Wed, Feb 02, 2000 at 03:28:46PM +0100, [EMAIL PROTECTED] wrote:
You can create domains with nearly no limit. Where the files
reside is completely up to, it may even be the homedirectory...
So that means that we need a new domain, such as "gimp-override",
that resides in .gimp/locale and
On Wed, Feb 02, 2000 at 02:41:57PM +0100, [EMAIL PROTECTED] wrote:
Not really, you have the word "Preferences" just a few mm above it.
No, I haven't.
Also there was some inconsistency: The category "Monitor Information" was
a settings dialog anyway but it had no "Settings" in its name
That's the hitting point, if you want to use perl or script-fu here you
have to produce code for (possibly :)) highlevel languages which isn't
quite simple.
It must be quite simple. the perl plug-in can give you a detailed trace
output of all functions called, which is implemented with less
On Wed, Feb 02, 2000 at 10:58:12AM -0800, Martin Weber [EMAIL PROTECTED] wrote:
ImageMagick has import / export filters for fpx (only import), pbm,
pict and ttf. I think we should include this fileformats also for GIMP
Patches welcome. There is a nice project on sourceforge where you can get
On Wed, Feb 02, 2000 at 11:16:44AM +0100, Sven Neumann [EMAIL PROTECTED]
wrote:
Before you start to go crazy about post-1.2 i18n issues,
wouldn't it be nice to first clean up the situation for
gimp-1.1 a bit?
The usual situation: I can't fix problems that I do not know about. So
just tell
Marc;
On Wed, Feb 02, 2000 at 10:39:10PM +0100, Marc Lehmann wrote:
On Wed, Feb 02, 2000 at 03:05:30PM -0500, Tom Rathborne [EMAIL PROTECTED] wrote:
This is probably a generic automake/pgcc problem, but it's
exhibiting itself with the GIMP first, so here it is:
Slow, slow... _what_ is
On 2 Feb, Marc Lehmann wrote:
So that means that we need a new domain, such as "gimp-override",
that resides in .gimp/locale and is consulted just like gimp-perl and
gimp-plug-ins.
No
The command you're asking for is msgunfmt...
Hmm... sounds like the solution. You pribably made
On 2 Feb, Marc Lehmann wrote:
Not really, you have the word "Preferences" just a few mm above it.
No, I haven't.
Sounds like you should send a bugreport to the authors of your
favourite windowmanager
I have no problems with these!! Consistency is great, I am just
against removing
On 2 Feb, Simon Budig wrote:
Hmm - I dont like the first too, since it is unclear what preferences
are adjusted inside "New File". "New File Settings" is not much
better...
What about "New File Defaults" ?
Sounds good.
So, what about the "Colors-Curves" Thing ? It is a tool isnt it?
On 01 February, 2000 - Kelly Lynn Martin sent me these 0.4K bytes:
On Tue, 1 Feb 2000 17:24:35 -0600, "Shawn T . Amundson"
[EMAIL PROTECTED] said:
But hasn't Mozilla basically given up on this idea and just used
their own toolkit? Mozilla certainly looks crappy on the Mac at any
rate.
I prepared a version of my Gradient-Fu patch that is compatible with
version 1.1.x of the GIMP. As a reminder, Gradient-Fu adds PDB procedures
that can manipulate gradients, so scripts and plug-ins can create and
modify gradients.
The patch can be downloaded from my homepage at the following
On 02-Feb-00 Robert L Krawitz wrote:
Why, FROM THE STANDPOINT OF USERS WHO WANT ALL THEIR APPS TO WORK THE
SAME, should the Gimp work different from their other apps?
I want a real, stable solution that I can use! :-)))
When I upgrade a library I don't want have to upgrade a lot of others
Hello gimp developers!
I've been using 1.1.15 for a while now, and I just downloaded
and compiled the latest updates from the CVS server.
I love it and salute all of you for all the good work!
But I do have a question.A month or two ago I wrote a
plug-in for 1.0.4 (p2m_plugin). (My
1.1.16 is out there. Grab it at:
ftp://ftp.gimp.org/pub/gimp/unstable/v1.1.16/
There's the usual set of bugfixes and i18n stuff. Notably to translators
is there are now separate po files for libgimp.
-Yosh
32 matches
Mail list logo
