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 menu
On 28 Jan, Kelly Lynn Martin wrote:
>>One possible reason is that it is a pain in the ass to install
>>additional plug-ins. Some things, like translations, must be part of
>>the distribution currently.
> This needs to be fixed. :)
Do you volunteer?
--
Servus,
Daniel
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
> automati
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 24 Jan, Jens Lautenbacher wrote:
> I would like to kindly suggest that we at least give a configure
> option to avoid the stacktrace stuff that happens when gimp crashes.
> I'm currently developping a distributed perlfu server and it would
> make life much much easier if gimp would simply cr
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 400
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 mom
On 13 Jan, Kelly Lynn Martin wrote:
>>I personally like both the balloon and brush image. Maybe both can
>>fit in somewhere? I understand I'm just a lurker here and have no
>>real clout, but maybe one can be the splash (I'm thinking balloon)
>>and the brush one could be modified for the About i
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 30 Dec, Marc Lehmann wrote:
>> Nick Lamb pointed out the "make install-strip" option to me last
>> night.
> Didn't know that one, either.
Uhm, one of the most beloved auto* features... :))
> Bad. This (and the missing configure options) should be documented
> before 1.2 indeed.
Patch a
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 25 Nov, Michael Natterer wrote:
> Well, I don't know how to solve this...
> ...but I'd vote to put the gimp + plugin + perl +
> whatever-is-in-cvs-gimp into _one_ catalog.
Hm, but how would you do this... don't forget that some of the plugins
are built conditionally
> What do you thi
On 24 Nov, Marc Lehmann wrote:
> How do I get the perl menupaths into the gimp .po file? it is no
> problem to mark them, but the standard xgettext program is not able to
> parse perl source.
> Should these go into the gimp-std-plugins-file? Should I put all
> translations into that file then?
On 23 Nov, Steinar H. Gunderson wrote:
> There seems to be a bug in the toolbox. If you simply make the window
> taller (on my system, the threshold seems to be about 380 pixels
> high), the gradient selector (and half the color selector) seems to go
> under the visible area, and out of sight. Sh
On 25 Nov, Michael Natterer wrote:
> However, I still didn't find out why my installation is unable to
> lookup translations from "gimp-std-plugins".
In GIMP core? I don't know why it should... you are in the wrong
doamin
--
Servus,
Daniel
On 23 Nov, Marc Lehmann wrote:
> When you mean that the translation must be done inside the gimp, then
> you are right. One obvious reason is that the plug-in is only queried
> once.
The translation of menupaths into another language MUST be done by gtk!
> However, we need a way to communicate
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 possibl
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, 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 a
On 23 Nov, Michael Natterer wrote:
> It seems we're doing _many_ useless translations in the menu system.
> For example all calls to menus_set_sensitive() et.al. are using
> strings which are marked with N_().
Note: A N_ mark is just a mark and as such an pseudo op.
It can't cause bigger exec
On 19 Nov, Marc Lehmann wrote:
> Hmm.. that is interesting... 's' did never produce a stackdump on my
> machine :=)
Here it did, but it has never been very useful... :))
GDB's still programmers choice...
--
Servus,
Daniel
On 11 Nov, [EMAIL PROTECTED] wrote:
> I have the same problem, very most menu's contains the german word
> "Datei".
Which version of GIMP do you use?
> Locale settings:
> LANG=de
> LC_ALL=de_DE
I now did a complete fresh installation of all packages coming in mind
and still can't reproduce
On 11 Nov, Marc Lehmann wrote:
> The difference (IMHO) is that a help system is an integral part of the
> gimp, just like menus, a good ui design or the tooltips are.
IMHO the best solution would be to leave everything out of GIMP that
isn't really necessary for running, including help, catal
On 11 Nov, Tor Lillqvist wrote:
> I don't think gimpenv.c is in any way unique in this sense, probably
> many of the other files in libgimp also contain code snippets that
> have originally been in some file in the GIMP proper.
Hm, the file I created was done on my own or cutted from gimp-libs
On 12 Nov, Andrew Kieschnick wrote:
> LGPL previously stood for "GNU Library General Public License". It was
> changed to be the "Lesser GNU Public License" at some point not all
> that long ago.
> Read http://www.gnu.org/philosophy/why-not-lgpl.html if you'd like to
> know why its name was chan
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 10 Nov, Raphael Quinet wrote:
> So please stop complaining about the help system, because that could
> backfire on Gimp-Perl quickly...
No flamewars, please. Let us concentrate on our work instead of pushing
our energies in a thread which as useless as Win 3.11 ... :))
--
Servus,
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 G
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 b
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 wri
On 9 Nov, Andrew Kieschnick wrote:
> libgimp and libgimpui are LGPLed, so that isn't a problem.
Really? Not mine
Serious: If it'd be LPGLed it would have had such a header in every
source file and in the COPYING file which isn't the case...
--
Servus,
Daniel
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 y
On 5 Nov, Sven Neumann wrote:
> I just used LANG=de, but using LANG=de_DE.ISO_8859-1 doesn't change
> the behaviour here.
Okay, let's start with something simple:
- Version of Gtk+ used
- Version of libc used (compiled when?)
- CVS date of your GIMP version?
- Settings of ALL of your loca
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 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 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 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 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-translat
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
> t
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 "usin
On 30 Oct, Marc Lehmann wrote:
> Real design bugs can´t be solved for 1.2, so either we can do it
> painlessly or we can´t do it (in 1.2).
Of course
> I´m not sure LANG=de works extraordinarily good for me... no extra
> > menus or other problems anymore, so I think we should only disab
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 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 woul
On 22 Oct, Sven Neumann wrote:
> I don't think that internationalisation is our major problem with
> plug-ins right now. This doesn't mean that we shouldn't think about
> it now, but our main problem is the mass of plug-ins shipped with the
> Gimp.
It is and there a quite a couple of reasons wh
On 19 Oct, Marc Lehmann wrote:
> I don't understand - how does the current situation (different dirs
> for plug-in and gimp i18n) differ from having the plug-ins in a
> different cvs tree? Wether we create a tarball from one or from two
> cvs trees is just a matter of some script-hacking, but it
On 17 Oct, Marc Lehmann wrote:
> Just as we do now.. no changes are necessary.
> Just that we change how the plug-ins are stored (cvs) does not
> necessarily change the way they are distributed.
> And a few extra messages in gimp-std-plug-ins for plug-ins we do not
> ship because they are uns
On 11 Oct, Simon Budig wrote:
> Wie Du vielleicht mitbekommen hast, werde ich den Gimp-Stand
> auf der Systems 1999 in Muenchen organisieren.
>
> Ich brauche noch ein paar Leute, die dort sein werden und etwas Zeit
> uebrig haben um Gimp zu praesentieren. Wenn Du Lust hast, mail mir
> so schnell
On 10 Oct, SHIRASAKI Yasuhiro wrote:
> Here is a small i18n fix for AlienMap (2).
> Check it.
No, this is WRONG!
Never ever translate a menupath directly. I know we used this system
(even more bad, I introduced it :)) but that leads to bad problems.
So either leave the path alone or just m
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 module
On 6 Oct, David Odin wrote:
> Hm. Sorry, the compilation works OK. These messages show up during
> the
> linking phase. So maybe it's a faulty libintl.a...
Do you use glibc2 (aka libc6) or libc5? If the latter is the case I
would suggest you to get the gettext package version 0.10.35 and
On 3 Oct, David Odin wrote:
> With the latest patch of David Monniaux, I've decided to try to
> compile the latest gimp-cvs without the --disable-nls option. But then
> the compilation stops with some unreference to __dcgettext.
That's either a wrong include file in your search path or a fault
On 4 Oct, Zach Beane - MINT wrote:
> The buttons now "flow", so you can have a horizontally oriented
> toolbox or a vertical one, or something in between with a square
> toolbox. It's easier to have a different layout than the default now.
Not that long ago I had a nice idea about the toolbox.
On 3 Oct, Paul Gammans wrote:
> My only worry is that it would result in GIMP becoming blot ware.
> Though having photoshop an illustrator open together an swapping
> between them is very common thing i do.
Just make a extra package and concept your piece of software as a
gimpmodule
--
On 3 Oct, Zach Beane - MINT wrote:
> Yosh is still working on this, and when he is done it will Do It
> Exactly Right. Well, perhaps not that good, but certainly better than
> its current in-development state.
I just wonder what the reason was for changing the old behaviour?
--
Servus,
Hi all!
I discovered a strange behaviour of Script-Fu:
When I start GIMP from Bash, let script-fu render a logo (doesn't
matter which one) Script-fu segfault at his try to close the parameter
window of the script.
When I start it from enlightenment it manages to close the window but
kills
Hiho!
Is it the intended behaviour that the toolbar can be resized by the
user at will? If the user makes it too small the icons will mix up and
if the user makes it to large in its height the colorbox and the
brush/pattern/gradient will be drawn somewhere in Nirvana.
The former behaviour
On 2 Oct, David Monniaux wrote:
> Have I forgotten something?
No, not really ... we can see you have understood it :))
--
Servus,
Daniel
101 - 159 of 159 matches
Mail list logo
