On Mon, Nov 24, 2003 at 07:25:01PM +0100, Raphaël Quinet wrote:
I am questioning this because I think that the fact that the toolbox
is special is an artificial limitation that should go away in a
future release in order to make the user interface more consistent and
easier to use.
Artificial
On Fri, Sep 12, 2003 at 12:38:26PM +0200, Sven Neumann wrote:
Oh, will you? I am sorry but if I remember correctly we postponed this
until after 2.0 since we hope that until then there well be an
accepted Free Desktop standard for this. Our prefered solution would
be to offer the image data as
On Thu, Sep 11, 2003 at 06:49:42PM +0100, Alan Horkan wrote:
I only ask that you take a moment and consider if there might be a way to
make things faster for the user which is where speed really counts.
Could some of the handling of the system clipboard be done automatically
and only when
On Wed, Jul 16, 2003 at 05:35:42PM +0200, Sven Neumann wrote:
I don't think we should use a compressed archive. Instead the binary
data in the archive should be compressed. That allows to choose the
best compression scheme for the data and to combine different
compression techniques in the
On Mon, Mar 17, 2003 at 12:38:59PM +0100, Sven Neumann wrote:
I'm surprised by the silence. Should I interpret it as an approbation?
Sounds pretty bad. The GIMP is developing a history of adding cool
features which then become unmaintained and are ultimately just turned
off in CVS. Maybe future
On Mon, Nov 18, 2002 at 08:50:16AM -0500, David Weeks wrote:
Also, I've noticed my gimp png's transparentcy isn't showing correctly in
Microsoft IE. Is this a bug with gimp, or MSIE?
Windows IE bug, known by Microsoft for at least five years.
Re: MNG support
GIMP needs better animation
On Fri, Nov 01, 2002 at 06:35:10PM +0100, Guillermo S. Romero / Familia Romero wrote:
some places use 32 bit float
This probably ought to be on our horizon too. Modern FPUs are very fast
and RAM gets ever cheaper. Are there any concrete advantages (other than
the 50% saving on storage) for
OK, so the big problem is Script-Fu because it's fairly embedded and it's
somewhat hairy. The ordinary plugins aren't much of a problem, in the very
worst case they can be removed from the distribution temporarily.
Surely the #1 thing someone should be doing (preferably someone who actually
On Wed, May 29, 2002 at 01:26:07PM +0200, Raphaël Quinet wrote:
./gimp-1.2.1.in (Spencer Kimball, Peter Mattis)
./gimptool-1.2.1.in (Owen Taylor, Manish Singh)
This is gibberish. Someone bolted on some boiler plate which claims that
the whole of the GIMP is covered by an
On Fri, May 03, 2002 at 11:12:12PM +0200, Sven Neumann wrote:
I didn't say how soon it will be possible. This depends on a lot of
things, mostly http://bugs.gimp.org/stable-milestone/.
#77283 was actually fixed for 1.2.x already, but I've just done the extra
stuff to mark it FIXED in both
On 29 Mar 2002, at 11:37, Piotr Legiecki wrote:
So I'd like to load amp files from photoshop from Curves window, just
like native gimp curves.
On Fri, Mar 29, 2002 at 11:10:12PM +0100, Branko Collin wrote:
Regis Rampnoux recently made a plug-in which can be found at
On Thu, Mar 21, 2002 at 05:27:16PM +, Austin Donnelly wrote:
I've just heard about Valgrind, a memory debugger much like Purify,
but which works on Linux.
Better/ Different than Purify because it treats the code as a black box,
and so it finds bugs in your compiler, libraries and so on.
http://www.ecs.soton.ac.uk/~njl98r/chocbox1.png
http://www.ecs.soton.ac.uk/~njl98r/chocbox2.png
A potential UI for a textual metadata editor using Dublin Core's element
names (and of course internally it could use any parasite names that
were deemed fit, but since parasite names are arbitrary
[re-formatted for your 80x25 pleasure]
On Sun, Jan 20, 2002 at 12:22:44AM -0600, Russell Valentine wrote:
Gimp Developers:
This patch was made against The Gimp stable 1.2.2 file plug-ins/common/tga.c.
It allows a user to save a tga in down-top format instead of top-down
format.
On Sun, Jan 20, 2002 at 04:15:09PM +0100, Sven Neumann wrote:
I have committed a rather inelegant change to gimp-1-2 that should
remove the need to have glib-2.0 and pkg-config installed in order
to compile the gimp-1-2 branch. Please let me know if you experience
any problems with the build.
On Mon, Jan 07, 2002 at 10:15:23AM +0100, Sven Neumann wrote:
Read your own words and thing again. If you were having problems to
compile gimp-1.2 from CVS months ago, why didn't you go ahead and ask?
There are only few people left working actively on gimp-1.2 and they
do communicate (by
I was hoping that the problems I had with 1.2 CVS were temporary and that
the attitude I got when trying to get it working was a result of someone's
long day. That was back in early December (or was it November?)
On a system that was perfectly adequate for building Gimp a few months
ago I now
On Sun, Dec 16, 2001 at 02:58:20PM +0100, Sven Neumann wrote:
my whole point was that we should try to come up with a reasonable
interchange format for multi-layered images instead of using XCF
which isn't really well-suited for this task. Introducing XCF support
into various other apps will
Maybe I said this before, I can't remember, but the standard for trying
to describe generic metadata is Dublin Core. So before burning too much
midnight oil trying to organise metadata into neat categories at least
type Dublin Core into a search engine. Even if one decided that DC
itself was
On Sat, Nov 17, 2001 at 06:38:32PM +0100, Sven Neumann wrote:
GIMP is an image manipulation program, mng is an animation format.
so what?
He's wrong anyway, MNG is a multi-image format, with the primary target
being replacement of GIF anim features because those features were
missing in PNG
On Wed, Sep 19, 2001 at 09:51:05AM +1000, Steven Goodwin wrote:
This is a patch and long-winded README for the targa file format plugin
(tga.c). It simply checks the value of the extension area offset before
reading it from file. An offset value of 0 means that no extension area
exists in
On Wed, Aug 29, 2001 at 07:58:52AM -0500, Kelly Martin wrote:
In my opinion, a library which crashes when fed inappropriate external
data is buggy by definition.
Let's be more specific:
Does the GTK+ UTF8 implementation meet the requirements for security
purposes laid down in Unicode 3.0.1
Guillermo S. Romero / Familia Romero wrote:
I tried video, and I got a blue image... fun. I run with depth 24 and
fbbpp 32, so I guess this has something to do about it, cos when
moving the video window, I get blue areas (I am still discovering the
nice and bad things of the new driver for my
On Wed, Aug 08, 2001 at 01:54:53PM +0200, Raphael Quinet wrote:
If we want to avoid 404 errors from the web servers, we could decide
to use # instead of / as a separator between the real file name
and the extra path to the image. I initially thought about this and
then rejected the idea
On Tue, Aug 07, 2001 at 05:28:15PM +0200, Raphael Quinet wrote:
4) Feedback
Any comments?
IMHO you'd be better off just using:
wad://home/raph/slimy.wad/p/alien.foo
This can be handled today in Gimp 1.2, see url.c
Non-interactive stuff would go exclusively through these URLs while the
(Petr CC'd in case he is not in fact on the list)
On Wed, Aug 01, 2001 at 04:41:57PM +0200, Petr Mejzlik wrote:
I tested it by generating a 5x5 grayscale image with the following
pattern:
Interestingly I found a new bug in the Gimp 1.2.x TGA loader while testing
these 5x5 grey images. This
On Thu, Jul 26, 2001 at 01:27:59AM -0400, Malcolm Tredinnick wrote:
For CVS gimp, it is definitely not a problem to require the current
bleeding edge GTK.
Malcolm did you ask me first? If you didn't, how did you come to the
conclusion that it wouldn't be a problem for me (a developer, even if
On Wed, Jun 06, 2001 at 07:37:23PM +0200, Sven Neumann wrote:
Argh, I knew the heavy usage of g_assert() in the convert code would
bite us some day.
But assuming the assertions aren't invalid we have found a bug that
would otherwise be very hard to find?
IIRC People who don't care why their
On Sun, Jun 03, 2001 at 04:22:40PM +0200, Guillermo S. Romero / Familia Romero wrote:
If what people want is to change the comment without changing the
image data, they should use rdjpgcom to read the comment and wrjpgcom
to overwrite / append.
I've always planned to build a pair (at least)
On Mon, May 21, 2001 at 05:47:33PM +0200, Raphael Quinet wrote:
One of the things that has been mentioned several times while
discussing the distribution of plug-ins is the fact that the menus are
too crowded, and new users can easily get lost. The user interface is
indeed a significant
30 matches
Mail list logo
