On 8 Apr, Marc Lehmann wrote:
Yes, I got the impression from all what I was told:
a) msgmerge is not checked for by gettext itself
b) binary .mo files are being distributed with the gimp
Since I was no gettext expert, I just ate it. But now we know better:
a) is wrong, since msgmerge
On 1 Apr, Marc Lehmann wrote:
I think using optional(!) tags (which will be more verbose) will be
even more useful: Not much added strain on the programmer, not much
strain on translators (we need one more translator for the en
mapping).
Please note that adding "tags" to the messages will
On 30 Mar, Stanislav Brabec wrote:
I18n wishes:
-- Please do anything with the fact, that main panel menu with default
GTK theme can contain exactly 15 letters. Too few for three items
inmost languages.
What exactly would you suggest? That's actually a matter for the
On 25 Mar, Blue Lang wrote:
A lot of laptops, especially running linux @ 1024x768, will only
support 8 bit depth. Dunno if it matters to ya or not. :P Gimping on
the plane, ahh.
Really? But that's not a limitation of the notebook I hope...
The techniques used in notebook LCD's allow normal
On 10 Mar, Raphael Quinet wrote:
P.S.: I identified this problem when I tried to start an old version
of the Gimp in order to check why the "Frosty" script was not
giving the same results as in 1.0. If anybody knows why this
logo script does not produce the same effects as
On 26 Feb, Kelly Lynn Martin wrote:
It will also force us to develop tools for the separate compilation of
plugins and develop a plugin interface that is versionable
The first one is definitely a need but "a plugin interface that is
versionable"? We do have versioned libraries ensuring
On 25 Feb, Sven Neumann wrote:
Which is exactly what I proposed at the end of my last mail. Despite
that I proposed to build up the menu-structure (actually only the
strings) in a hash-table before actually creating it.
For a new translation function I guess?
Would be much
faster then
On 25 Feb, Sven Neumann wrote:
Don't waste your time at that. I already did that and I tried to
explain you why there is no way to hook into that place since GTK+
creates the submenu on the fly. At the time we create the tearoff
menu, the submenu is already created. But when the submenu is
On 23 Feb, Ludovic Poitou wrote:
SunOS bondi 5.8 Generic sun4u sparc SUNW,Ultra-5_10
UltraSPARC-IIi
But I haven't compiled with the 64 bit flag on !
A simple program like this :
main(){
printf("%d\n", sizeof(unsigned char *));
}
Do the plugins work for you? We've got dozens of
mark owned by Daniel
Egger
Hey Sven, come on...
--
Servus,
Daniel
On 24 Feb, Sven Neumann wrote:
Eek, yes of course, that does not work any more. There are
two ways to solve this: Either we search in the gimp domain
if the lookup of the menupath failed (like we used to do (*))
or we move the dummies into the plugins. I prefer the latter,
since it is the
On 23 Feb, Sven Neumann wrote:
gimp_plugin_add_locale_domain (gchar *domain_name,
gchar *domain_path)
and can only be called in the query function of a plug-in. The
domain_path may optionally be NULL. Proposals for a better name are
welcome.
I'd recommend
On 23 Feb, Sven Neumann wrote:
No, that won't work. Of course you need to hook somewhere into
plug_in.c or at least use the plug_in_defs list. Otherwise plug-ins
won't be able to register their domain on the first call.
Of course you are right, just a braino.
The only thing missing now is
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
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 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 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
On 21 Feb, Marc Lehmann wrote:
I have a question: what standard do the po-filenames follow? In the
current gimp, we have a en_GB translation, however, GB is not a
toplevel domain, but the iso-3166 code for the UK.
On the other hand, we also have uk (which is a toplevel domain, but
not for
On 21 Feb, Blue Lang wrote:
did that. :)
if you have time, would it be possible to get someone with better
bandwidth than i to download a clean copy of CVS gimp and see if it
builds?
Yes, it builds it's in our SuSE internal database
i've done distclean and autogen, etc, etc -
On 13 Feb, Kelly Lynn Martin wrote:
This can be dangerous; you can get a resizing loop if your code isn't
carefully written. Window managers can refuse to accept a client
resize request or can modify it, which could result in a duel between
GIMP and the window manager as the two fight over
On 10 Feb, Raphael Quinet wrote:
Flexibility is ok.. but some time create problems.
Why don't set fixed sizes x*y to cover all the dimension of toolbar?
This could be usefull to have right dimension and good
rappresentation.
Unfortunately, this is not so simple. Constraining the
On 9 Feb, Marc Lehmann wrote:
Since about two weeks, setting LANG to any value results on a
segmentation fault on startup.
Since I cannot reproduce this (i.e. GIMP works just fine)
I'd need more input on this.
Your stacktrace seems like it crashes when initialising the
help_pages but I
Okay people,
since there seems to be some i18n which I can't reproduce but
a lot of people seem to experience it's time to take the next step.
According to the bug report #6052 and the inline stacktrace it seems
that menus_create_item in menus.c calles gtk_item_factory_create_item
which
On 9 Feb, Mike wrote:
Here is the file log you requested in order to have an easier
debugging. Hopefully it can be useful, so that you fix this bug! BTW:
On my box, not all locales (as Mark said in his report) are broken. I
tested out them all, and I found that only it and de crash gimp.-
On 6 Feb, Marc Lehmann wrote:
This has been mentioned at least three times on this list: one of them
works, the other doesn't.
Both don't work correctly, as I stated before. Do you read my mails?
The Bezier Select Tool behaves very strange: Points appear automatically
here and there and
On 5 Feb, Nick Lamb wrote:
Please do not step forward and say "I'll do it", the time for that was
in November or at the latest December, and there was conspicuous
silence during my last Triage thread from those named to defend their
code.
You are right, it's time to cleanup. Unfortunately
On 5 Feb, Marc Lehmann wrote:
Thats not the point. The point is effective user feedback.
Now, where are the users? :)
Here is one. If you are not a user you should not decide whats best
for them. Especially not if you limit your horizon to a single person
(yourself).
I'm running tests
On 5 Feb, Tuomas Kuosmanen wrote:
Argh.. I am used to toggle between paintbrush and pencil. Like I
pointed out in my previous mail on this thread, I use the paintbrush
as a "fine tuning" tool together with the "real" tool I am drawing
with. And if it is the paintbrush, then there is no way
On 4 Feb, Raphael Quinet wrote:
I wouldn't be too sure about that. On a system that I was previously
administering (students' network at the university), I have seen some
users that were using /var/tmp or /tmp to store their applications
while they were logged in, and deleted the stuff
On 4 Feb, Steinar H. Gunderson wrote:
I'm constantly finding myself looking for tools. I know that they are
there, but I have to stop and look closer at almost every single tool.
There are simply too many tools (some of them could well be combined),
and the icons look very much the same
Hiho!
I think it's time to remove that useless pencil before the release
of the magic version 1.2. Did anyone use it in the last time?
It contains no functionality that paintbrush doesn't have except of
hard edges (anyone needing that "feature"?)...
Anyway: This is up for discussion on
Hi developers,
At the moment we have got 2 Pathtools in GIMP. One which is called
Bezierselect in the Toolbox but has a Path dialog
(in the Layers/Channels dialog???) and another one called Path tool.
The latter works a lot nicer IMHO but I haven't managed yet to
transform a path into a
On 4 Feb, Kelly Lynn Martin wrote:
What does Photoshop do?
What does that matter?
Photoshop is the most used graphicstool out there and it makes sense
to have a closer look on their behaviour especially in the UI sector.
Anyway, even if books do now say that Fill fills with the
On 5 Feb, FUJITA Yuji wrote:
Which one should we keep? Or better: should we
merge it into one Tool which works nicely AND has a support dialog?
I hope them to be merged into one tool with support dialog.
Anyway, the dialog window title should be something like
"Layers, Channels and
On 5 Feb, Sven Neumann wrote:
It is a very important feature, believe me!
It's your right to consider it useful, I don't and won't believe you...
But the pencil can easily
be merged with the Paintbrush by adding a "Hard Edges" option.
Yes, if you appreciate. But the makes the eraser
On 5 Feb, Sven Neumann wrote:
It works much better now (/me thanks Kelly).
"much" is a bit too much... :)
It definitely works better but the current behaviour isn't acceptable
for the release anyway
Well, if you don't see the advantages of a more configurable toolbox
layout, I
On 5 Feb, SHIRASAKI Yasuhiro wrote:
I'm all for removing the Path Tool, the Xinput Airbrush and and
merging Pencil and Paintbrush. If I counted correctly this would
reduce the number of tools to 24. This is a perfect number of tools
since 24 % [2|3|4] == 0 which means we always get a nicely
On 5 Feb, Sven Neumann wrote:
Do you have any idea how much work is needed to integrate it with the
Paths dialog?
No, not yet, but I'll have a closer look on this.
A number of new bugs would certainly be introduced by
doing so. That's why I say: It's too late!
Every line of code
On 3 Feb, Arcterex wrote:
I think that this was discussed some time back and the conclusion was
that if you have 5 users on your system all using gimp and each using
50%... well, you see where that could be a problem.
In that case you could adjust the value manually. But bear in mind:
If
On 3 Feb, Raphael Quinet wrote:
I think that asking the user is the best solution in any case, because
you can hope that the user has some vague idea of how much memory is
or will be available on the system he is using (shared or personal
computer). This will not work in all cases (e.g.
On 3 Feb, Marc Lehmann wrote:
Hmm... I removed gimp-perl.pot now. However, all the other .pot files
_are_ in cvs.
Shouldn't be, the files are generated at compile time and ignored by
CVS...
Whats the logic behind that?
Server:/usr/src/gimp/po # less .cvsignore
*.gmo
*.mo
Makefile
On 3 Feb, Marc Lehmann wrote:
You seem to want to move the catalogs to the home directorys, which is
much worse (one copy for each user is insane).
But would work
Do you have any _reasons_ not having a seperate domain (speed?
usability?) AFAIK it'S only in a few places neede
On 3 Feb, Marc Lehmann wrote:
Now that you mention it, I have the same problem since around 1.1.13
or so. However, that was the time I installed XFree-3.9.1x, so I
thought this is a bug in my X-Server.
XFree-3.9.1* isn't guilty, at least not general as I cannot reproduce
this without
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.
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?
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 1 Feb, Kelly Lynn Martin wrote:
additional plug-ins. Some things, like translations, must be part
of the distribution currently.
This needs to be fixed. :)
Do you volunteer?
I don't understand translations at all. :)
What a pity... I'm currently trying to dissolve all these
On 1 Feb, Sven Neumann wrote:
You don't seem to be very familiar with gnome-libs, especially not
with the progress that was/is being made towards the next release.
Uhm, not quite except that I'm trying to compile it every three days...
gnome-print for printing (preview, native printer
On 31 Jan, Marc Lehmann wrote:
BTW: we need to
consult a ~/.gimp/po/ directory for translations as well at some point
in the future!
Bad luck, I don't know why you like to have a personal catalog
directory but with gettext you have either ... or ... and setting up
such a system which uses
Hiho developers...
I discovered some name glitches in GIMP.
1. The "Settings" in the preferences Dialog wasn't in everything and is
useless nevertheless because a preferences dialog is supposed to
contain settings...
2. Some tools had a "Tool" in the options dialog and some not.
On 1 Feb, Marc Lehmann wrote:
Macro recording and XML are two *completely* orthogonal things. Macro
recording gets possible by programming it, not by using a difefrent
format to save config files.
You could use XML for saving macros. Of course you could also use
scheme BUT: There are
Hi developers,
Having no real documentation of the sourcecode is really a burden
when searching for bugs. Do you agree that having a documentation
would be fine? I'd like to introduce a in-source-documentation
which an extractor program could use to make a TeX or HTML file of
it.
Using
On 1 Feb, Sven Neumann wrote:
This is supposed to be first class font-rendering and if it prooves to
be useful, I see no reason not to use it, even it has gnome printed
on it.
Well, if it really is first class rendering, then I'd like to see it
in GIMP I haven't yet seen this package,
On 2 Feb, Sven Neumann wrote:
We have already brought up this issue lately and I think the
conclusion was that we try to add documentation for libgimp before
1.2. Most certainly we will use gtk-doc with comments embedded into
the source. Marc volunteered to write the necessary scripts to
On 1 Feb, Steinar H. Gunderson wrote:
Well, we _do_ have gimp-perl available...
Uhm, yes...
With XML, we'd have to write _both_ loader and saver
There are fantastic parsers available, no need to write any of those.
-- with gimp-perl (or Perl-Fu, whatever name
you like best), we'll
On 1 Feb, Martí María wrote:
So, any volunteers?
This piece of code is highly interesting but since this won't make
into GIMP before 1.2 because of the featurefreeze I really hope that
all GIMP developers will concentrate on the project until we released
the next stable version.
--
On 1 Feb, Shawn T . Amundson wrote:
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.
Not yet... at the moment it's possible to use even gtk or qt for the
UI but they are slowly migrating to their
On 31 Jan, Sven Neumann wrote:
(A) do nothing, ignore the problem
(B) don't mark the strings for translation, not in the core, neither
in the plug-ins (C) mark the core PDB strings for possible
translation too
Kick them
--
Servus,
Daniel
On 28 Jan, Michael J. Hammel wrote:
Do you mean language locales? I'm not very familiar with working with
multi-language issues, but I have wondered why this isn't handled by
the plug-ins directly.
Because it won't work entirely this way... localisation works for
everything but the menues
On 27 Jan, Robert L Krawitz wrote:
diff -rc print/README /tmp/print/README
Please use diff -u for further patches to preserve readability and
attach them to prevent line wrapping to slash the patch
--
Servus,
Daniel
On 25 Jan, Marc Lehmann wrote:
I really do not understand this. The stacktrace simply does not work.
Attaching a debugger is much better, but still: the core file a segv
would create would be _far_ more reliable.
I buy the argument that users can do bug reports better with an
automatic
On 24 Jan, Raphael Quinet wrote:
Any suggestions for the name of the new option? It could be something
like "--disable-stack-trace" or "--disable-crash-query", assuming
that the default behaviour would be to have it enabled in unstable
releases. Note that I also support the idea posted
On 14 Jan, Marc Lehmann wrote:
So, if at all possible, could some translation expert find a fix for
this problem, and I'll just add Logulator to app/menus.c in the
meantime. Or did I misunderstand the general plan for translation? I
thought that would already have been fixed?
At the moment
Hiho!
I recently discovered that using one of the spinbuttons in the filenew
dialog causes redrawing of the whole upper table and thus flickering.
This is quite annoying because it prevents users from using the spinbuttons
to choose their imagesize because it is impossible (on my AMD K6-2
On 4 Jan, Sven Neumann wrote:
on our way from 1.0 to 1.2 we included a few plug-ins that were
considered not to be stable enough to be included with a stable
release. This was done in the hope that the inclusion into the
1.1 developement tree would encourage people to work on those
On 2 Dec, Marc Lehmann wrote:
However, if we solve this problem by *linking* libintl against
libgimpui we get another problem: linking against libintl
automatically puts libgimpui under the GPL.
If you are using glibc2 then you've got not problem with lgpl, because
its LGPL itself then...
On 23 Nov, Michael Natterer wrote:
I did some debugging there and noticed that gettext() returns
"/Datei/tearoff1" for _any_ string which has the form "*/tearoff1"
().
This is either a bug in our po-files, a bug in gettext or a feature of
gettext which allows to do some magic by
On 27 Nov, Marc Lehmann wrote:
PS: does gimp now translate by component or still using the whole
path?
Componentwise...
BTW: Is there any special reson I can't unsubscribe from this list and
subscribe again with another address? Quite annoying
--
Servus,
Daniel
On 23 Nov, Marc Lehmann wrote:
(btw, can anybody tell me why redhat ignores LANG? and what is this
LINGUAS thing anyway? maybe because other variables like LC_ALL are
also set and take precedence?)
LANG will be just used if no other LC_* is set to something... and
LINGUAS are all possible
On 10 Nov, Kevin Cozens wrote:
Reading the discussions re: the help system has made me think I
understand why compiling GIMP always broke at a point where it needed
a GtkXmhtml header file. I use a RedHat system without Gnome installed
and I'm beginning to understand that GtkXmhtml is a
On 8 Nov, Marc Lehmann wrote:
Hint: It's the way menues are handled by Gtk...
And if this leads to segfaults it is surely a bug in gkt+? No, really,
I am _simply_ interested in how a call to gettext can result in a
"legal" segfault.
The most likely way to cause a segfault is to write
On 10 Nov, Marc Lehmann wrote:
That all plug-ins that are part of the distribution should have
corretc translated menu entries is (for me) obvious. The problem is
new (third-party) plug-ins.
These problems are solvable by a consistent way to handle the
translations. Im working on these but
On 11 Nov, Andrew Kieschnick wrote:
Hmm, that sure as hell looks like an LGPL to me. I seriously doubt
your copy of gimp is different than mine...
LGPL stands for "Lesser GNU Public Licence". Now do me a favour and
count the word lesser in this COPYING file... Then do this again
for the
On 9 Nov, Sven Neumann wrote:
Daniel Eggert wrote:
BTW: My name spelled E g g e r without any 't'
Ok, here's my setup:
glib: uptodate from CVS (1.2 branch)
gtk+: uptodate from CVS (1.2 branch)
gimp: uptodate from CVS
glibc: libc-2.0.7
Well, my version is glibc is a bit
On 2 Nov, Andrew Kieschnick wrote:
Gimp plug-ins are not linked into the calling program (they are run as
separate processes), so you can call them from any program you like
without violating the GPL.
However you have to link Plug-ins against libgimp and possibly
libgimpui and here
On 1 Nov, David Monniaux wrote:
The stupid I18N behaviour of the week: when menus are translated, any
string for which the system finds no translation gets translated to
"Fichier" (in French), which means "File".
I don't know the innards of the translation system, but a fact is that
On 3 Nov, Marc Lehmann wrote:
This sounds interesting (explain!).. how can i18n lead to segfaults?
Not again Marc, we have had this discussion before
Hint: It's the way menues are handled by Gtk...
Me included! Maybe I shouldn´t even reply here.. ;-
Maybe :)
Well, half-translated
On 3 Nov, Michael Natterer wrote:
Just because I didn't write for many files "using the context here
fixes a bug" doesn't mean it didn't. E.g. the device status dialog was
totally unusable after a "refresh" and ensuring it's consistency
without the context would have needed another weird
On 4 Nov, SHIRASAKI Yasuhiro wrote:
Is your translation table fr.po ?
It seems to be broken when I tried to "make update-po".
Duplicated entries, possibly a merging problem. Patch is on its way...
--
Servus,
Daniel
On 4 Nov, Sven Neumann wrote:
If it is, the german de.po is broken too, since I experience the same
weird problem here.
No, the catalogs are definitely all right (but the French one, but
that incorrectness can't cause the explained behaviour)
--
Servus,
Daniel
On 5 Nov, SHIRASAKI Yasuhiro wrote:
What menuitems are replaced by Datei?
I could not reproduce the problem.
Me, too... I'll try to investigate the problem
--
Servus,
Daniel
On 3 Nov, Michael Natterer wrote:
Note: At the moment featurefreeze is more violated by the changes
done by for example Michael than by the ideas I'm having which would
be something like "little changes with big positive effects"...
Just because I didn't write for many files "using the
On 23 Oct, Tuomas Kuosmanen wrote:
Speaking of that, how hard would it be to make the toolbar buttons
also use the .xpm format? Now the icons are in the header files.. it's
pretty hard for a art.geek like me to change the icons or try
different versions.. Also for 'T0olb4r ThemeZ' it would
On 29 Oct, David Monniaux wrote:
I agree with Daniel. I18N maintainers already have too much to do.
Frankly, I think we should try to ship 1.2 before changing how
plug-ins are handled.
It would be really helpful to know the thoughts of other developers or
even or great maintainer to this
On 5 Oct, Federico Di Gregorio wrote:
Mmm... what is a gimpmodule?
A module is an extension which has much more control over the GIMP then
a plugin.
How is it supposed to work?
Use the source... :))
Where can I find some examples? (The current distribution comes
without any
92 matches
Mail list logo
