On 23 May, Nick Lamb wrote:
Having just come back from WWW9 I'm pretty enthusiastic about SVG
right now. I can't see the point in continuing to use Flash once there
are vendors clambering over each other to produce the best SVG
plug-in and (since it's free) it will be built-in on Mozilla
On 13 Jun, Daniele Medri wrote:
My idea is.. to create a db (..probably with PostgreSQL) to manage all
the label of gimp, script-fu, gimp-plugin e make a coherent work
with these labels for translation. A php-interface could be a nice
add-on that i want to.
Talk to Marc, he showed
On 14 Jun, Sven Neumann wrote:
app/pixel_region.c 1.20
app/paint_core.c 1.90 app/paint_core.h 1.30
app/undo.c 1.60
and couldn't see any problems. I could reproduce the crash after
reverting all those changes, so it seems the problem is elsewhere.
ME TOO. GIMP tries to free unexistant
On 14 Jun, Sven Neumann wrote:
app/pixel_region.c 1.20
app/paint_core.c 1.90 app/paint_core.h 1.30
app/undo.c 1.60
and couldn't see any problems. I could reproduce the crash after
reverting all those changes, so it seems the problem is elsewhere.
Okay, traced this problem further. The
On 25 Jun, Sven Neumann wrote:
I agree with this opinion and would be happy if we could set up a
short email that we send to the Imlib2 people signed by some of the
people owning the copyright of the affected code. Since it seems not
necessary to involve Peter and Spencer at this point, some
On 25 Jun, Nick Lamb wrote:
It "appeared" courtesy of someone identified only as "cK", hopefully
those working on Imlib2 will know that handle (though who knows,
it doesn't look like an expertly managed project to me, maybe anyone
can get CVS write privs) and remove their write privs.
This
Hiho!
I talked to Christian Kreibich, the author of the codemixture and he
told me that it was a mistake to publish the code in this form and
that he'll undo that step.
He and Raster are going to meet next week and then they'll think about
possible solutions for this conflict.
--
On 25 Jun, Marc Lehmann wrote:
He and Raster are going to meet next week and then they'll think
about possible solutions for this conflict.
Don't they think this is demanding some _action_ (like reverting that
patch)? "meet next week" and "possible solutions" sounds, well, not
very
On 26 Jun, DrMartin.Weber wrote:
I took several months' time to compare nearly all available color
quantization algorithms. Shurely GIMP's Median Cut is good but not the
best. SQC (http://www-dbv.cs.uni-bonn.de/quant/) is really the best
one available and it is also fast. I have some code
On 21 Jul, Michael Natterer wrote:
I guess that Gtk+ and Gimp will run more or less automatically
on MacOS X' BSD API once there is an X server, so there should
be no need to "port" it.
A X server for MacOS is due to be released by Apple, soon
--
Servus,
Daniel
On 20 Jul, somnorici wrote:
I set the undo levels to zero and loaded an image. 9376 by 11488
pixels grayscale is 107,711,488 bytes. My display depth is 16 bits. It
didn't take long to link this with the swap file, which after
loading the image was 292,421,632 bytes, plus the 32 megs of tile
On 23 Jul, Charles Iliya Krempeaux wrote:
Will it be free? Will it be a standard part of MacOS?
(Or is it something Mac users will have to pay for?)
Sorry, I have got no details handy. Read about it on slashdot or
somewhere. Have a look at the usual MAC places to get info about that...
--
On 23 Jul, Charles Iliya Krempeaux wrote:
OK, I'll do that (eventually). But my point is, if X Windows isn't
available on every Mac system... or at least if they can't get it
for free... then it is worth porting the GIMP (and GTK+, GDK, etc) to
the native MacOS API.
I'm not against a
On 30 Jul, Andrew J Fortune wrote:
I currently have the latest developers' version of GIMP (v1.1.24). Can
someone tell me if Perl scripting is still available ? (...there used
to be any entry called "Perl-FU" on the Xtns menu).
Perl normally should be there. But since the Perl plugin has
On 30 Jul, Marc Lehmann wrote:
i would really appreciate if you would finally start thinking, as this
is not the first time you claim things that are sooo obviously broken
:(
No need to get insulting. Spend your time fixing the plugin instead.
This would be more helpful for you and me. I
On 30 Jul, Marc Lehmann wrote:
It's you who is unprof(f)essional. You were and are totally wrong with
your today's claim about gcc -- claiming some not-yet-existant
version of gcc causes problems on your machine.
Pardon? Just because a version is not officially released doesn't mean
it
On 30 Jul, Marc Lehmann wrote:
No need to get insulting.
It's pure fact. You keep claiming all sorts of funny things that you
yourself should have known long before you started posting about it.
Ok Marc, it's enough. I will not continue this useless flamewar!
In real life you sometimes
On 30 Jul, Robert L Krawitz wrote:
Pardon? Just because a version is not officially released doesn't
mean it doesn't exist, does it?
For this purpose, I would say it does (mean that it does not exist).
Especially since it isn't even a formal snapshot (which egcs was doing
for a
Hiho!
I'm actually asking myself where we should place the new docs
in the CVS.
It seems we have two choices:
1) Put them in help parallel to the other files
2) Create a new directory for them until everything (automatic creation
of HTML docs and indexing) is working good enough for
On 4 Aug, Michael Natterer wrote:
Just go ahead and populate this directory. In the first time we'll
take care of committing the generated help files into gimp. Once the
build system is working (hopefully soon) we can include gimp-help as a
virtual module into the gimp CVS tree.
We'll
On 6 Aug, Kevin Turner wrote:
gimp-help/whysgml.txt states that we are going to go through all the
bother of writing well-formed XML files (e.g. being strict about
always using closing tags, etc), but that we won't be actually marking
the files as XML. If you have a grudge against xml, why
On 26 Sep, Tim Mooney wrote:
Grepped through the source and couldn't find any C++ style
comments...
cc: Error: lighting_ui.c, line 387: Invalid statement. (badstmt)
// GtkWidget *spinbutton;
--^
This is from 1.1.26/plug-ins/Lighting. I haven't made the build
proceed any farther, to
On 26 Sep, Tim Mooney wrote:
You need to quote the '*.c', it's getting expanded by the shell before
it ever gets fed to find. :-)
Actually that's not the problem since there are no *.c files in the
directory I started the search in...
Anita:/mnt2/src/gimp # find -name *.c
On 28 Sep, Paul Wagland wrote:
First up, I hope that this is the right place to report this bug.
Second thing: This is a great product. You guys should be proud of
yourselves!
We are, hehe :) Now back to bussiness... :)
I have no reason to believe that steps 1-2 make sweet rafoosle
On 28 Sep, Steinar H. Gunderson wrote:
H... Since the JPEG previewing mess originally was made by me,
I've just got a side note: libjpeg is rather unstable at low
qualities. Of course, if this happens with HQ too, it is a GIMP bug,
and not a libjpeg bug.
I cannot reproduce this bug
On 28 Sep, Alejandro Forero Cuervo wrote:
Could someone please help me? Where should I look at? I am
unfamiliar with Gimp's code, as you can see.
GIMPs scripting features are all plugins, thus you should see
pluins/script-fu and plugin/perl how they implement thing and whether
you can
On 29 Sep, Garry R. Osgood wrote:
I cannot reproduce this bug under any circumstances here on i386
while it crashes Kevin's machine hard. Should the dialog block while
a update is running? Just asking because it does here and elsewhere
not
I reproduce it here on both the laptop
On 1 Oct, Marco Lamberto wrote:
I've got a little trouble while rebuilding the rpm of gimp 1.1.26,
when running the "make prefix={a_new_prefix} install" it tries to
install into "/usr" discarding the "prefix" and "PREFIX" values. I
should update someting or someone has forgotten something?
On 1 Oct, Marc Lehmann wrote:
I haven't fixed yet the GIMP Perl plugins installation, please could
anyone fix it or tell me a workaround?
The README.perl suggests PREFIX= for just this case. Daniel Egger
could probably get more info as he works for suse and suse has quite a
few perl
On 28 Oct, Tuomas Kuosmanen wrote:
No clue. Is this a "they want someone to do a demo" or "who the heck
is going to do a gimp demo there??"
BTW: I'm going to show GIMP at the COMDEX in Las Vegas at the SuSE
booth
--
Servus,
Daniel
On 4 Nov, Garry R. Osgood wrote:
Given the nearness of 1.2 release, the Gimp Help Team (bex, Piers
Cornwell, Daniel Eggers apologies if I missed the other contributors)
started a separate gimp-help project last July, and not integrate with
the main tree until help stuff is reasonably
On 5 Nov, Austin Donnelly wrote:
Is it generally known that mouse-down and waiting on brushes and
patterns pops up a larger preview window showing the whole
brush/pattern if it's larger than the preview?
Do many users discover this themselves, or are they ignorant of the
fact?
Just
On 5 Nov, Tuomas Kuosmanen wrote:
Just curious: Is anyone able to get the brush dialog by
doubleclicking the brush in the toolbox using a graphicstablet?
Dunno, I have it always open :)
It works now... I fixed the driver so probably it was a problem in
there
--
Servus,
On 6 Nov, Sven Neumann wrote:
If you want me to change the helpbrowser, I need a detailed list of
the changes that are necessary.
just the changes we talked about: Removal of the HTML navigation bar
and using the supplied links in this bars for the buttons in the
helpbrowser.
--
. [EMAIL PROTECTED]
* Copyright 2000 by Daniel Egger, Germany. [EMAIL PROTECTED]
*
* Modified for Linux USB by MATSUMURA Namihiko.
* FrñÅñÓic Lepied [EMAIL PROTECTED].
* Additional changes by Brion Vibber [EMAIL PROTECTED]
* and Aaron Optimizer Digulla [EMAIL PROTECTED
On 26 Dec, [EMAIL PROTECTED] wrote:
I am not supposed to download 10mb of source code, I have been
patching up since like 1.1.20, no way, you can provide a good patch
from 1.1.32 to 1.2.0.
Why not use CVS and tags? Makes life much easier for both sides.
--
Servus,
Daniel
On 27 Dec, [EMAIL PROTECTED] wrote:
You know since you take time to answer my posts, I might as well too.
Compared to your "limited" 64k how does 9600 that disconnects every 5
minutes sound to you? And the fact that downloading something like a
full gimp 1.2.0 would take close to 2 or 3
On 14 Dec, Sven Neumann wrote:
Please keep in mind that the main intention of our proposal has been
to better distribute work between core and plug-in developers by
seperating the source trees during development. Perhaps this scheme
could be translated to distribution too, but it does not
On 26 Dec, Garry R. Osgood wrote:
The tarballs and patch-sets are really meant for end-users
who prefer to compile from source, but don't otherwise
desire to get involved in maintenance and so don't have
a strong motivation to keep a bleeding-edge source tree
around. Patch sets are
On 28 Dec, Tino Schwarze wrote:
Without having looked at the code - what do we need that many FDs for?!
We don't need to open all palettes at once, do we?
The code for the brushes, gradients and the palettes is (was?)
really nasty. But the file descriptors are closed after the complete
On 1 Jan, Laramie Leavitt wrote:
I have ported a part of my iscissors patch from 1.1.25 to gimp 1.2.
All this patch does is add a livewire boundary to the iscissors tool,
and an option in the tool options to turn it on and off.
Yay! This is way cool. I'll checkin your changes to the new
On 5 Jan, Bennett Keith Portnet wrote:
Sorry to bug you, I found you name and email address in the GIMP files !
I downloaded the GIMP 1.2.0 (for Windows ?!) from Tucows.
It has been uncompressed into a file on my hard drive.
(I am running Windows NT)
NOW WHAT DO I DO TO GET IT RUNNING ?
On 6 Jan, Sven Neumann wrote:
The other ideas seem to be good suggestions. I think we should
set up a web-forum where we collect ideas and suggestions like
this.
What about the bugtracker? It's much mightier now and a good place to
keep things.
--
Servus,
Daniel
On 9 Jan, Christopher Curtis wrote:
Patchsets also have a big problem which timecop already
noticed: They don't contain binary files or patches to
such and thus a patched tree might miss quite a few important
files after a while. xdelta wouldn't cause that particular
problem but is
On 14 Jan, Jens Christian Restemeier wrote:
I recently got a bug report for QBist, and in turn made a new version.
What is the easiest way to get it into CVS-Gimp ? I made a patch, but
the patches directory on ftp.gimp.org doesn's seem to be cleaned for 2
years, and the latest CVS version
On 3 Feb, Sven Neumann wrote:
has the wishlist for features for gimp 1.4/2.0 been started?? If so
where can I find it/add to it?
The source tree contains a file TODO which is a collection of ideas
that have come up over the years. Actually the file should not be
called TODO, but probably
On 6 Feb, David A. Bartold wrote:
I think a better solution would be a definable pressure curve, much
like Wacom's Windows driver has. That'd probably be a feature of the
general mechanism you described and perhaps what you have in mind.
Hm, generating a lookup table and getting the
On 7 Feb, Raphael Quinet wrote:
Since the GIMP/GNOME bug database has moved to bugzilla.gnome.org, the
administrative options have changed. On the old bugs.gnome.org, it
was possible for me to change the status of some bugs easily, but now
I cannot change the status, affected OS, priority
On 17 Feb, Austin Donnelly wrote:
I've been meaning to find a way to update the menu item to include the
filter name so you can get a better idea what will happen, eg:
Filter-Repeat Last (blur IIR)
or something.
Great idea. In case you don't have the time to implement it please file
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
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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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, 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 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
1 - 100 of 141 matches
Mail list logo
