On Sun, Jul 16, 2000 at 05:37:56PM +1000, David Hodson wrote:
> OK, this has been bugging me for some time. I'm convinced that Gimp's
> alpha handling is wrong, in more than a few places.
OK, but please provide some concrete examples...
> (Minor disclaimer - I don't have the code in front of me
On Wed, Jul 19, 2000 at 12:53:31AM +1000, David Hodson wrote:
> > Can you justify that (all images should be pre-multiplied)?
> > Or is this just your unsupported opinion?
>
> Well, that was attempted editorial humour to some extent, but it's also
> the opinion of (for example) Jim Blinn, and Tho
On Tue, Jul 18, 2000 at 10:39:26PM +0100, I wrote:
> No the program which produced your example PNG image is broken.
> The PNG specification requires straight RGBA, pre-multiplied alpha is
> prohibited and this is spelled out several times. Gimp can't hope to
> interpret an invalid image correctl
What is the "forbidden" colour picker mouse cursor for? By this I mean
the cursor where the picker is joined by a crossed-out circle, the
universal symbol for prohibition.
There doesn't seem to be any situation in which the picker doesn't work
(perhaps you could argue that its not working when th
DocBook sounds fine to me presuming that the tools are validating (ie users
who just type nonsense into their text editor will be rewarded with a
screenful of errors) and so we get some decent structured documents, not
the hacked-together nonsense you usually get when people write HTML.
I don't k
On Thu, Aug 10, 2000 at 09:24:42PM +0300, Tor Lillqvist wrote:
> GTK+ 1.3 (and 2.0) uses UTF-8 internally, while the file system
> related C runtime calls like stat(), open() and opendir() uses a
> "current codepage" (the Windows term, on Unix you want to use whatever
> encoding/charset the user's
I have been a busy bunny writing a transfer mini-thesis so that I can get
on with my PhD. However I should have a spare moment between writing to
handle some of these issues and write more help.
1. Yes, Gimp can't read 16-bit TGA files ATM, I have some samples and
the TGA specification so I'll lo
On Thu, Aug 31, 2000 at 03:48:37PM -0400, Federico Mena Quintero wrote:
> If p is a null pointer then "free (p)" may (and should!) crash. You
> are incorrect here.
You are completely wrong, see K&R's treatment of ANSI C
Standard Library, Section B6
void free(void *p)
free deallocates the sp
On Sat, Sep 09, 2000 at 07:45:17PM -0400, Brandon wrote:
> Below is a patch to add support for saving TGA files upside down.
> Although it sounds
> strange to do, it is a supported feature of the file format and OpenGL
> expects its
> textures to be upside down. Support already exists for reading
On Mon, Sep 11, 2000 at 01:17:25AM +0200, Marc Lehmann wrote:
> On Sun, Sep 10, 2000 at 07:16:22PM +0100, Nick Lamb <[EMAIL PROTECTED]> wrote:
> > > strange to do, it is a supported feature of the file format and OpenGL
> >
> > apply the patch and (b) I don'
On Mon, Sep 11, 2000 at 03:38:29PM +0200, Marc Lehmann wrote:
> Ah! ;) Still gimp would not support uncommon errors by giving the user more
> freedom.
Allowing users to needlessly create bizarre image files that will then
cause them trouble in other packages is just _asking_ for trouble.
> This
On Sun, Sep 17, 2000 at 10:53:40AM -0400, Garry R. Osgood wrote:
> but one can set the example by hand.
Probably some UI improvements needed in the gradient editor then,
other packages I've seen use a separate edit bar for alpha. I would
not advocate such a change to Gimp, but it is at least insp
On Sun, Sep 17, 2000 at 02:12:22PM -0700, Kevin Turner wrote:
> Then on Sun, Sep 17, 2000 at 06:33:09PM +0100, Nick Lamb wrote:
> > Pre-multiplying is a performance hack only, please don't let people
> > think of it as something that will cure "black fringes" -- it
On Mon, Sep 18, 2000 at 05:24:20PM -0400, Garry R. Osgood wrote:
> Nick Lamb wrote:
>
> > Pre-multiplying is a performance hack only, please don't let people
> > think of it as something that will cure "black fringes" -- it won't.
> > Perhaps
Right, one of the formal things Linus' little toy project does which
allows him to ship only a year or two late is to have a list of stuff
that needs doing before release. Of course, none of that stuff gets
done, but you can document it and move on. Another toy project, named
after that monster w
On Mon, Oct 09, 2000 at 11:37:47PM -0500, Jon Winters wrote:
> Hi,
>
> Can we just ban messages from non-list members? That is how I've done
> things on the lists that I maintain.
We shouldn't, because it makes it very difficult to reach "a Gimp
developer" in reasonable time. #1 preference sho
On Mon, Oct 09, 2000 at 05:23:04PM +, Brendan Byrd/SineSwiper wrote:
> I don't see how this is a problem with anything besides The GIMP. I'm using
> BlueSteel (to match my BlueSteel E theme), and it works just fine on all of my
> other GTK applications.
Occam's razor is a crude and unreliabl
On Fri, Nov 24, 2000 at 08:35:10AM +0100, Martin Weber wrote:
> Certain jpg/tiff files cannot be loaded correctly.
> http://homepages.go.com/~martweb/gimp.zip
>
> Sorry that I mail this bug, but the bug report page currently doesn't seem
> to work.
Go.com seem to be a rather Mickey Mouse operati
On Thu, Nov 30, 2000 at 01:13:33AM -0500, Maneesh Yadav wrote:
> No one knows how to get the offsets for a layer from libgimp do they? I
> see a set_offsets but no get...
> Shouldn't we put an accessor method in there...I would add it myself, but
> I don't get that pdb meta code...
gimp_drawable_
On Tue, Dec 05, 2000 at 07:39:11PM +0100, Marc Lehmann wrote:
> > This patch _fixes_ GIMP translations. Currently it's _impossible_ to
>
> And givne that a large amount of similar fixes went into the gimp not too
> long ago this patch really should be considered.
Those fixes made Gimp have more
On Tue, Dec 05, 2000 at 10:17:23PM +0100, Marc Lehmann wrote:
> Probably not ;) Probably it makes sense because, at one point, all
> drawables might have useful offsets.
Do layer masks have offsets? Obviously you wouldn't be able to set the
offset on the mask, but perhaps it has one anyway (the l
On Mon, Dec 11, 2000 at 10:37:11PM +0900, [EMAIL PROTECTED] wrote:
> On the side note, one thing that could use serious serious improvement is
> the preferences dialog. I think, the "Tree" structure of organizing
> preferences is truly confusing. Reserve tree structures for directory
> lists and
On Tue, Dec 12, 2000 at 11:39:43AM +0900, [EMAIL PROTECTED] wrote:
> > There is no way to resolve duplicates - and what does it help if the
> > shortcut-key is the third letter of the Word you want to select? You
> > want to accelerate your work - and decyphering from some accidentally
> > underl
On Tue, Dec 12, 2000 at 05:08:03PM +0100, Lourens Veen wrote:
> I realise that it's probably too late already, but dare I say C++? Did
> anyone ever even consider this?
We don't vote here, but FWIW twelve months on kImageShop is still an
argument, some screenshots and a dormant CVS tree. I vote n
On Wed, Dec 13, 2000 at 03:29:41AM +0100, Marc Lehmann wrote:
> I think the best way would be to make any gtk label/text widget be
> selectable. I don't know why this has not been done so far, but it might be
> an interesting experiment.
Yes, I've often thought this. And everyone knows that if Ma
On Wed, Dec 13, 2000 at 04:36:16PM +0100, Tino Schwarze wrote:
> Look at Netscape's shortcuts, e.g. "Close Window".
> - on Sun: ALT-W
> - on Irix: CTRL-W (consistent with other Irix applications)
> - on Linux: ALT-W
> - on Windows: CTRL-W
That's a legacy feature, caused by the Emacs lobby. In mod
General purpose compose operations usually include a division by 255 of
a number in the range 0 ... 65025. While fixing up Mozilla's alpha
compositor I disturbed a sleeping hacker who has provided a (tested and
working) macro which computes this operation much more quickly than
any other solution
On Wed, Dec 20, 2000 at 02:34:19AM -0600, Federico Mena Quintero wrote:
> You have to make sure that the code that uses such techniques indeed
> has 255*255 as an upper bound. A long time ago the GIMP was full of
> inconsistencies where some parts assumed 256*256, others 255*255, yet
> buggier on
On Fri, Dec 22, 2000 at 12:26:54PM -0600, Federico Mena Quintero wrote:
> "Adam D. Moss" <[EMAIL PROTECTED]> writes:
>
> > Right, this is a bad-data problem, and "WON'T FIX". The
> > source XCF image contains pixels with an index of 34 (the
> > screen on the computer icon) but only declares a pa
A potential patch for the histogram tool in 1.2.x (assuming we do plan
to release e.g. file handle leak fix as a 1.2.1) has been uploaded
as gimp-ruth-010109-0.patch.gz
This patch addresses several problems I found in the 1.2.0 release tool,
Sven and I discussed some of this already, but the foll
On Thu, Jan 18, 2001 at 12:42:23AM +0200, Tor Lillqvist wrote:
> (No, I don't know why duplicate PDB procedures cause strange errors
> and not just warnings. Anyway, GIMP seems to handle this situation
> better in the current gimp-1-2.)
It's a long standing bug in Gimp. I would really like to cha
It seems as though it should be possible to use Gimp with two mice (or
similar devices) to some advantage, using them to control different
tools, using different settings.
With AlwaysCore and the Xinput extended devices disabled (probably a
common setup) you get what you'd expect - more physical
On Tue, Jan 23, 2001 at 11:40:30AM +0100, Mirar wrote:
> Doing tiled images for textures used in 3d worlds, the best method
> I've found out isn't very good, it's the procedure of:
>
> 1) make an image the right size that looks tiled
> 2) tile it 2x2
>2a) did it tile? finished!
> 3) fix
On Sun, Feb 04, 2001 at 04:45:58AM +0100, Sven Neumann wrote:
> The colorselector has already undergone a major overhaul in the HEAD tree.
> The color previews as well as all sliders are now global to all color
> selector notebooks so all selectors should behave identically. Have a look
> at http:
On Mon, Feb 05, 2001 at 02:26:23AM +0100, Hans Breuer wrote:
> The windoze version of gimpwidgefts can't include two symbols for
> different implementation of the same function. There is only one
> version of the dll in memory, even if loaded by another process.
> The code is shared across proces
On Thu, Feb 08, 2001 at 01:36:10PM +0100, Roel Schroeven wrote:
> The value in the gimp histogram is calculated as the maximum of the red,
> green and blue channels now. Wouldn't it be better to use the average of the
> three color channels?
We discussed this when I was fixing the histogram for 1
On Mon, Feb 12, 2001 at 07:21:07AM +0100, wolfgang hofer wrote:
> I guess that NLS specific print representation of float numbers
> can cause those troubles in the PDB Interface.
Yes, if you used the Gimp's API as described you would not have had this
problem. It deliberately disables i18n functi
Maybe it's just me, but it seems that channel previews have been broken
in CVS HEAD for some time. I'm not complaining, it just seems possible
that no-one has bothered looking at that entire tab for say, two weeks
and didn't realise that they'd broken it.
Nick.
On Sun, 10 Oct 1999, Federico Mena Quintero wrote:
> lseek() returns the offset to which you seeked, so lseek (swap_fd, 0,
> SEEK_END) will give you its size.
I think this will just give you the LENGTH of the file? So, I don't
know if it matters, but ISTR that Gimp uses files with holes, and
the
Almost every Gimp user I've met has one or more dead gimpswap files in
their home directory, and they're often completely unaware of them.
Fixing that in Gimp 1.2 would be really great, and if NFS is a problem
for the less than 5% of Gimp users stuck with gimpswap on NFS, then I
guess (unlink-on
On Mon, 11 Oct 1999, Jay Cox wrote:
> I can't remember the last time gimp crashed on me without the signal handler
> being called. I have had it hit infinite loops though...
Which reminds me, do end-user builds of Gimp have the built in debugger
code enabled? It's great if you're hacking Gimp,
The Export functionality slowly creeping into CVS Gimp is really nice,
but it leaves me with a dilemma somewhat related to my last set of
changes (ie fixing Save As... list of save formats)
Should plug-ins which have working Export declare themselves capable of
all image formats for the purposes
Michael's other plug-in (s) go into CVS?
-- Forwarded message --
Date: Tue, 26 Oct 1999 10:10:58 -0400
From: Michael Taylor <[EMAIL PROTECTED]>
To: Nick Lamb <[EMAIL PROTECTED]>
Subject: Re: PIX changes in Gimp CVS
[lots snipped]
I don't know if you'r
I've been testing out Export to make sure it is idiot proof, and I have
some problems to report:
TIFF (and for the moment PNG too) can't handle INDEXED ALPHA, though they
can handle either alone, they can't handle both at once. There's no way
to reflect this in the Export API - either a way must
On Mon, 1 Nov 1999, Carey Bunks wrote:
> I think that Michael has a good point here. Why is it useful to
> declare a feature freeze? In my opinion the answer is so people can
> begin making plans with respect to the upcoming new stable release.
> If just anything is allowed after a feature fre
On Wed, 3 Nov 1999, Alexander Schulz wrote:
> Hello,
>
> The bmp-plugin as used in 1.2.6 has several serious bugs. (can't load
> grayscale images, segfaults on some RLE-encoded images) I would very much
> appreciate if you could include a more recent version of this plugin. It can
> be found at
Is there some reason why people who fix bugs from the bug-tracker (and
even note that fact in their CVS commit) don't log a close, or even a
"probably fixed, please test..." message to the appropriate bugs?
If it's just lack of time, I understand but I wondered if there was
some other reason...?
On Tue, Nov 09, 1999 at 01:27:29AM +0100, Ewald R. de Wit wrote:
> Anyway, today I went over the Gimp sources and noticed how complicated
> the tile architecture makes things and I couldn't help wondering why
> the heck it was put in. All it seems to do is to give you an order of
> magnitude slowe
Further to my last post (and possibly related to Ewald's complaints too)
Why does my 7274 x 9985 RGB image (212743Kb of data by my calculations)
result in the creation of a gimpswap which is up to 500Mb in size?
The performance for such images seems adequate to me (can't compare
PotatoShop beca
On Tue, Nov 09, 1999 at 04:57:16PM +0100, Sven Neumann wrote:
> > s/help/perl/
On Wed, Nov 10, 1999 at 03:09:46AM +0100, Marc Lehmann wrote:
> However, perl works on many _many_ more platforms than the help system,
> which only works on a very limited number of systems.
Well, PERL certainly work
On Wed, Nov 10, 1999 at 12:36:34AM -0500, Kevin Cozens wrote:
> The idea of a help system as part of GIMP sounded interesting and I had
> hoped to try it out and comment on it but I now discover I won't be able to
> do so.
Why not?
Nick.
Further to my original observations, here is something more detailed:
Gimp is set to ~24M tile cache, on a 64Mb machine with ~64Mb of swap
The TIFF is enormous (see previous post for exact dimensions) and as a
naive RGB array (3 bytes per pixel) would use ~210Mb of space
Stage --->
On Thu, Nov 11, 1999 at 01:40:28AM +0100, Uwe Koloska wrote:
> Nich Lamb wrote on Die, 09 Nov 1999:
> >Why does my 7274 x 9985 RGB image (212743Kb of data by my calculations)
> >result in the creation of a gimpswap which is up to 500Mb in size?
> >
> Where do you think can the undo information res
On Fri, Nov 12, 1999 at 11:38:57AM +0100, Ewald R. de Wit wrote:
> You can always read in the linear file in row order (and write the
> results in column order to memory in the case of 90 degree rotation).
> This will go at full disk speed.
This has optimal performance when the image data is on
On Fri, Nov 12, 1999 at 05:32:10PM +0100, Marc Lehmann wrote:
> You saying that the tile system in Gimp is faster is not useful.
^^^
I didn't. Please don't leap into every discussion just to bait me Marc,
it's very annoying and I somehow doubt that others are
On Fri, Nov 12, 1999 at 02:51:04PM +0100, Ewald R. de Wit wrote:
> > This has optimal performance when the image data is on disk, and there is
> > precisely enough memory spare to store a duplicate image in memory, and
> > assuming that your disk is very slow and your memory is very fast, which
>
On Tue, Nov 16, 1999 at 08:43:59PM +0100, Daniele Medri wrote:
> Hi,
> i just ask myself when 1.2 could be ready.
> I stopped the Italian translation after the announce of plugins-i18n
> compatible and other raisons.
> When the develop could be ready for the official release i think that all
> the
On Tue, Nov 16, 1999 at 11:48:55PM +0100, Sven Neumann wrote:
> The feature that was added here was iirc part of the list of features we want
> to have for 1.2. I have tested this patch heavily and found and fixed some
> problems that have been in fileops.c before applying the patch.
I hope Adam
On Fri, Nov 19, 1999 at 05:12:47PM +0100, Marc Lehmann wrote:
> Is there a way to disable the libgimp signal handlers? (Yes, I could add
> a disgusting hack myself, but I don't want to). They do not serve any
> purpose that a coredump wouldn't as well (so I don't see the advantage).
(me too)
I t
On Mon, Nov 22, 1999 at 02:49:50PM +0100, Marc Lehmann wrote:
> In current gimp you will notice lot's of bnad things happening when more then
> one oepration (regardless of which) is being done at the same time. It gets
> much worse when you do it on the same image.
Are these "bad things" fatal?
Mon Nov 22 13:18:40 GMT 1999 Adam D. Moss <[EMAIL PROTECTED]>
* app/channel_ops.c: Disabled the copy-on-write for gimage
projection. Duplicate op will now take as much time and
memory as GIMP 1.0 in this respect. That sucks, but I'm
damned if I can follow the t
On Tue, Nov 23, 1999 at 04:28:48AM +0100, Marc Lehmann wrote:
> It often ends up with gimp spinning in an endless loop or a segfault or
> corrupted images (including undo).
Eeek! This is definitely something wrong in the current implementation
rather than a missing feature, I wonder if all these
On Thu, Nov 25, 1999 at 03:32:40PM +0100, Marc Lehmann wrote:
> I just declare all linux distributions (exc. DIY) as broken, as i18n works
> perfect on my machine.
Not to be contrary Marc, but it is not the fault of the vendor if a user
or admin screws up their machine some how. No-one except SuS
On Thu, Nov 25, 1999 at 04:32:27PM +0100, Raphael Quinet wrote:
> So... errr... I don't know what to do. Does anybody have strong
> preferences for one solution (several calls in each script) or the
> other (two PDB calls hiding the gory details)? Or a third one (fixing
> gimp_undo_push_group_s
On Fri, Nov 26, 1999 at 01:03:08AM +0100, Sven Neumann wrote:
> And, yes I can reproduce this on a set of different machines. There's no
> need to question Marc's statement...
The only statement of Marc's that I'm questioning is the one where he
blames Linux vendors for a problem that's only hap
On Fri, Nov 26, 1999 at 01:03:08AM +0100, Sven Neumann wrote:
> > In French I can say "Fichier->New"
> > and then choose "Type d'image RVB, OK"
> > Resulting image is called "SansTitre-0.0"
> >
> Well, if would be working correctly, it would say "Fichier/Nouveau...".
... but people are busily re
On Sat, Nov 27, 1999 at 03:23:02AM +0100, Marc Lehmann wrote:
>
> We still need to work the perl plug-in names in. The problem is that
> gettext does not support this (and I see no way to modify the makerules
> without re-writing them totally. Just another reason why automake is
> evil).
Doesn't
On Sat, Nov 27, 1999 at 09:46:59PM +0100, [EMAIL PROTECTED] wrote:
>
> This bug appeared with the the widget that GIMP uses for its toolbox.
> IMO this one is too broken to stay for release, the old one approach
> instead is not that flexible but it actually works...
>
> I hereby offer to r
On Mon, Nov 29, 1999 at 11:03:02PM -0600, Miles O'Neal wrote:
> Marc Lehmann said...
> |
> |I don't know what you feel, but I think the new Reset button is definitely
> |the worst improvement ever.
> |
> |Not that such a button is nice, but putting it at the same place where we
> |had the OK butto
On Tue, Nov 30, 1999 at 12:29:36PM +0100, Sven Neumann wrote:
> Hey, hey! Calm down, guys, ok?!
OK
> The Reset button in the "File New" dialog has been in CVS since May 18th.
> It just wasn't placed consistently in all places, so correcting this is a
> bugfix and nothing else (and a very harmle
On Fri, Dec 10, 1999 at 12:17:49AM +0100, Max Moritz Sievers wrote:
> Hello,
> is there a plan to support JPEG2000?
I don't think so, unless JPEG change their mind about the direction for
future imaging standards.
IMHO JPEG 2000 is an attempt to fix a mistake made in the original JPEG
design wh
Disclaimer: I don't use GAP, though perhaps I should learn now...
On Mon, Dec 13, 1999 at 09:59:53AM +0100, Sven Neumann wrote:
> Oh, how much do I love when new features that would be really useful but
> would need some good thoughts and probably even the redesign of some core
> menus are hacke
On Sun, Dec 12, 1999 at 11:56:57PM +0100, Eduardo Perez wrote:
> [...]
>
> > If it becomes widely used, I'm sure someone will be willing to risk
> > being sued (as I have with TIFF implementation) and provide an
> ^^
> Could you talk a bit more about
On Sat, Jan 08, 2000 at 11:16:45AM +0200, Tor Lillqvist wrote:
> The PNG apparently claims to have the display (and print) resolution
> of 0 pixels/inch... Set it with Image>Scale Image>Print Size & Display
> Unit>Resolution X and Y and the image appears. The PNG plug-in
> probably should check fo
On Sat, Jan 08, 2000 at 01:21:44PM +0100, Sven Neumann wrote:
> I have changed the core so that it does not accept zero resolutions.
>
> Additionally I have changed all plug-ins that try to set the resolution
> to check the value and simply don't set it at all if it is invalid. Gimp
> will then
On Mon, Jan 10, 2000 at 10:29:29AM +0100, Sven Neumann wrote:
> Oops, I thought (but should have checked) that image_set_resolution_invoker
> was calling the gimp_image_set_resolution() in app/gimpimage.c. And probably
> it should since the core function keeps the undo_stack in sync by calling
>
On Mon, Jan 10, 2000 at 01:56:01PM +0100, Sven Neumann wrote:
> > * Error Console (well, here it is, but where are my errors?)
>
> I don't see your problem. I do get my errors in the error-console. All
> that's missing IMO is a way to set the error_console as the default
> error_handler in the pr
On Tue, Jan 11, 2000 at 11:50:28AM +0100, Sven Neumann wrote:
> As said, I can't reproduce your problem here. As soon as I open the
> error_console, all errors produced with g_message () appear in that
> dialog instead of popping up a message window.
Oh, I see. Somehow I expected that all my e
On Tue, Jan 11, 2000 at 06:15:11PM +0100, Raphael Quinet wrote:
> So maybe what we need is a new option in the gimprc, something like:
> make-error-console-visible-on-first-g-message-and-leave-it-open
> If you set that to true, then the error console would do what you were
> expecting. Or did I
On Mon, Jan 17, 2000 at 08:14:05AM +0900, Tamito KAJIYAMA wrote:
> I wonder if we need to escape the values of the SF_FILENAME type
> in the same way, although I believe that few people use double
> quotes in file names.
Didn't look at the patch, but it sounds like a good idea to do this
to SF_FI
On Mon, Jan 17, 2000 at 11:56:31PM +0100, Marc Lehmann wrote:
> I've got an 34k tiff file that xv cannot load (many errors), and gimp
> gives an error message "Falling back to RGBA, image might be inverted" (two
> times) and then the tiff-plug-in segfaults ...
This (the segfault) is now fixed in
On Sat, Jan 29, 2000 at 02:28:47PM -0600, Dean Johnson wrote:
> Howdy,
> Is there a feature request database for Gimp?
Yes, file a bug as usual, but set your (is it urgency? priority? I
don't remember, but I'm pretty sleepy right now) to show that it's a
feature request/ request for enhancement.
On Sat, Jan 29, 2000 at 04:38:52PM -0500, Kelly Lynn Martin wrote:
> If by "color table" you mean the indexed color palette, that will
> require core modifications (I believe) because I don't think palettes
> are exposed to plug-ins well enough to do operations on them.
What do you mean by "well
On Sun, Jan 30, 2000 at 12:10:16AM +0100, Marc Lehmann wrote:
> Probably "You cannot read/modify/list/do anything with the colormaps in
> the gimp."
Well, the mail I replied to (from Kelly I think) talked about indexed
palettes or colourmaps or somesuch, and the word indexed to me means
the kind
On Sun, Jan 30, 2000 at 02:38:07AM +0100, Marc Lehmann wrote:
> So plug-ins should duplicate the palette file parser, scan all direcrories
> where gimp looks for palette files to find the palette is looking for, and
> then restart gimp to take notice of the changed files?
"duplicate the palette f
On Mon, Jan 31, 2000 at 01:53:47PM +0100, Sven Neumann wrote:
> In the core the short description and the longer help strings for the PDB
> functions are not marked for translation. This decision was made since the
> PDB help strings are considered to be targeted mainly at developers and
> script-
On Mon, Jan 31, 2000 at 11:23:48PM +0100, Marc Lehmann wrote:
> Just to throw in my opinion: gimp is _NOT part of gnome, other than in a
> technical way, and I personally think it is important that it stays so.
>From the user's perspective The Gimp is part of GNOME. For 1.2 this
won't be really t
On Sat, Feb 05, 2000 at 01:46:14PM +0100, Sven Neumann wrote:
> Do you have any idea how much work is needed to integrate it with the
> Paths dialog? A number of new bugs would certainly be introduced by doing
> so. That's why I say: It's too late!
Agreed. Broken stuff with no-one working on it
On Mon, Jan 31, 2000 at 11:23:48PM +0100, Marc Lehmann wrote:
> Just to throw in my opinion: gimp is _NOT part of gnome, other than in a
> technical way, and I personally think it is important that it stays so.
>From the user's perspective The Gimp is part of GNOME. For 1.2 this
won't be really t
I'd like to change the Toolbox to do this:
.. or .___. or ..
| File Xtns Help || File Xtns Help|| File Xtns H|
rather than (as now) this:
.. or .___. or ..
| File Xtns Help || File Xtn H
On Thu, Feb 10, 2000 at 04:47:48AM +0100, Marc Lehmann wrote:
> a) what does HCI mean? ;)
Someone already answered this. To see bad examples, either look at
http://www.iarchitect.com/mshame.htm or look in a good bookstore.
> b) I always see programs do it the way gimp does it, so there must be
>
On Wed, Feb 09, 2000 at 11:31:16AM -0600, Miles O'Neal wrote:
> Phillip Hoerter said...
> |
> |I hope this is the right place to send this, if not please forgive me.
> |I have a few .tiff files of clip art I am attempting to work with. They
> |load just fine on a windows machine. but on mine I g
On Wed, Feb 09, 2000 at 09:55:26PM -0700, Michael J. Hammel wrote:
> He sort of said so, but it wasn't clear to me at first either. The problem
> is that with the Toolbox squeezed in tight horizontally, the Help menu's
> text button can be squeezed off the right side. His way, that button is
> b
On Thu, Feb 10, 2000 at 09:55:19PM +0100, Peter Kirchgessner wrote:
> How about hard-coding it into the plug-in and creating temporary files
> on runtime that are passed to gs ?
Even given that we have a secure place to write temporary files (in
the user's private .gimp directory probably .gimp/t
On Sat, Feb 12, 2000 at 05:32:41PM +, Austin Donnelly wrote:
> I think that given the number of people who are bitten by this, is
> there nothing we can do in the gimp to work-around the GTK problem?
Is this bug fixed in a new version of the theme? If not, why not?
If it is fixed, perhaps we
While scripts are in the air, should we remove mkbrush.scm before 1.2?
This script takes a bunch of parameters and makes a new brush, almost
exactly like the "New" or "Edit" features of the brush dialog, but
it's a Script-Fu. Do we need it for anything? Otherwise we should
remove it to reduce en
On Mon, Feb 21, 2000 at 01:37:39PM +0100, Marc Lehmann wrote:
> I have a question: what standard do the po-filenames follow?
[Sleepy misunderstanding deleted]
Just in case anyone else is as tired as Marc was when he wrote that,
we're using the same convention as everyone else in gettext-land,
ba
On Fri, Feb 18, 2000 at 12:50:05PM -0500, Glyph Lefkowitz wrote:
> I think that this sort of munging would be a good idea. Duplicate replies
> bother me, and that's the default behavior for a list such as this
> one. Howver, don't flame me about it, just read this essay for an
> alternative poin
FWIW I agree with Raphael, installing "scripts" which actually just
blow up when run is pointless, if it can't at least manage to register
itself with Gimp's PDB we shouldn't install it.
Similarly, even if they did have "sensible defaults" the GUI scripts
are not functional enough to be installe
* Is the end-user installation stuff broken, or is it just me? On my
system, cleaning out all old Gimp installs, installing latest CVS and
then trying to install Gimp as a new user (ie to create .gimp-1.1 and
all the rest) does not work. This seems to result from the changes to
the system data di
1 - 100 of 123 matches
Mail list logo
