ged". In any case it seems these scripts are being
corrupted
on startup.
Thankfull for any advice,
Darren Kelly
On Sun, 23 Jul 2000 20:45:32 -, "somnorici " <[EMAIL PROTECTED]> said:
>Kelly: no, I'm not asking gimp to not store the image decompressed, I
>just want it to use a display buffer sized to the window size, not to
>the image size. Of course, several copies of th
Doctrine of merger would probably apply
(there's only so many ways to draw a paintbrush).
Kelly
cal to
swap image data from the source file; most image storage formats are
compressed such that it is not possible to read data out of the file
except sequentially from the start.
Kelly
log should adequately document all contributors
since then.
Kelly
On Tue, 30 May 2000 11:27:37 -0400, Phil Schwan <[EMAIL PROTECTED]> said:
>Do you know who all of the copyright holders of that code are?
At least myself, Peter, Spencer, and Adam Moss. There are almost
certainly others.
Kelly
lugins for it, which is all to
>the good.
It will also force us to develop tools for the separate compilation of
plugins and develop a plugin interface that is versionable
Kelly
ize the window as
>I work, rather than digging through dialogs to choose a setting...
The problem is that the buttons in the toolbox are themselves
resizable.
Kelly
t;useful for other long-running things (and some of the filters take a
>long time to run).
Erk. I looked into this a while ago to solve the related "GIMP does
Bad Things if you delete an image while a plugin is using it" bug.
It's not easy. The code for running plug-ins is NOT very friendly.
Kelly
fix the problem (although I believe it's already been
fixed and released)? In the past when GIMP development has uncovered
GTK bugs, we've just gone and fixed the GTK bug. Never forget that
GTK is the *GIMP* toolkit. :)
Kelly
hat pops up the menus. People
would probably go "Where the hell is the menu?" if we did that,
though.
Kelly
an idea as any I've seen so far.
Kelly
ts to decide
what size the window will be.
Kelly
ly only
>useful in the context of specific output devices, which is what the
>print plugin deals with.
Full CMYK (that is, at least 8 bits per channel, not the twiddly 2-bit
stuff you deal with working on the printer drivers) is _absolutely
necessary_ for GIMP to be viable for prepress work.
Kelly
On Mon, 7 Feb 2000 09:22:09 +0200, Tuomas Kuosmanen <[EMAIL PROTECTED]> said:
>So it is basically Gradient Map on steroids?
Yeah, Gradient Map with a "preserve luminosity" option and the ability
to synthesize a gradient on the fly from an input image.
Kelly
7;? I forget ... ;), so some people
>may find this plug-in to be lots and lots of fun.
I've found Sample Colorize to be occasionally interesting, and
certainly harmless. It should be an optional plugin post-1.2, but I
see no reason not to include it in 1.2 if rendered relatively
bug-free.
Kelly
On Sun, 6 Feb 2000 01:18:12 -0600, "Shawn T . Amundson" <[EMAIL PROTECTED]> said:
>Wilber t-shirts and hats for everyone!!! ;)
Hell, that would be fine with me. :)
Kelly
>pnm plugin:
>When I save pbm in GIMP it is not saved as pbm but as pnm.
Here's a novel idea: file bug reports, eh?
Kelly
ey? Just curious.
It goes to Yosh, who will decide what to do with it.
Kelly
;edges (anyone needing that "feature"?)...
I find it very useful when working on small pixmaps (like icons).
Kelly
with you more. I'm radical enough to suggest taking
all the plugins out of the standard distribution entirely. :)
Kelly
wo
>different cvs servers.
Well, hopefully this sort of thing shouldn't have to happen; that
would occur because of a noncompatible interface change and I'd like
to think we can avoid that. (If the interfance needs to be changed,
we should offer a "legacy mode" so unadapted plug-ins continue to
function.)
Kelly
My position is sourceforge should be used at this time only for
plug-ins which are not already in the source tree. Such plug-ins will
not be a part of 1.2 anyway because 1.2 is frozen at this time. When
1.3 development begins, we can decide what to do with the plug-ins
currently in the distribution.
Kelly
I can find no evidence that this is actually used anywhere in the
GIMP. Anybody know what it's for and whether it even works?
Kelly
package from the GIMP
core; I would be quite happy to see the plugin directory go away
_entirely_ from the main GIMP CVS. This really isn't that big a
deal. Lots of applications require multiple packages to get
"everything", and GIMP is a _large_ application.
Kelly
On Fri, 4 Feb 2000 20:32:33 -0500, Federico Mena Quintero <[EMAIL PROTECTED]>
said:
>What does Photoshop do?
What does that matter?
Kelly
ed to the existing behavior, and I
>don't think it should be changed.
>I know it hasn't been customary in the past, but I think such a
>user-visible change should be discussed a little bit.
I also concur and recommend a reversion.
Kelly
nice to catch SIGXCPU and try to do an orderly
shutdown before the SIGKILL does ya' in, though. :)
Kelly
good idea to have a compile-time configuration option
for maximum cache size, and it might also be a good idea for gimp to
check its ulimits and adjust its cache size so as to avoid running
over its data segment limit or maximum resident set size. Some
admins use these as a way to prevent resource hogging.
Kelly
term (even if the gnome&kde
>communities themselves might feel the same).
Did you miss all the screaming when there was initial talk of a Win32
port? :)
Kelly
Netscape product, rather than
Mozilla. I can't speak to why Mozilla made the decision to use their
own toolkit.
Kelly
less work. We
should be able to as well.
Kelly
single biggest reason for opposing gnomification: we'd lose
at least two architectures (Win32 and OS/2). Yeah, I know, Windows is
Evil and OS/2 is dead. So what? We support them because people
want them.
Kelly
L grants a software
license in copyright; it does NOT grant any rights to any other
property, intellectual or otherwise.
Kelly
this dependency is NOT FUD. Nobody at GNOME appears even
interested in pursuing this problem (which is quite subtle and
evidence of very poor concern for portability); the only reason I can
think of for this is that popt is universally present on Red Hat
machines because it's part of RPM.
Kelly
rt is easily available separately
from gnome-libs, we can't.)
Kelly
s GIMP as part of GNOME because GIMP is better than any of
the existing GNOME apps. They're trying to piggyback on our success.
Personally, I think this is odious, but hey...
Kelly
separately exported, forcing you to install all the junk
you don't want to get the stuff you do.
Kelly
tom-developed widget set, and some of GNOME's developers are/were
GIMP developers.
Perhaps it is time for GIMP to move out of GNOME CVS.
Kelly
On Mon, 31 Jan 2000 16:33:53 -0500, Federico Mena Quintero <[EMAIL PROTECTED]>
said:
>Kelly, please don't spread FUD. People build gnome-libs on Debian
>boxes, old broken Slackware boxes, FreeBSD, Solaris, and other
>beasts. What library are you talking about?
popt
On Mon, 31 Jan 2000 08:57:59 +0100 (CET), [EMAIL PROTECTED] said:
>>>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. :)
Kelly
al c++ compiler!". Ever since I became sensitive with such claims
>;)
That's KDE for ya. :)
Kelly
to sell it." However, it
>also says: "I have now released lcms under GNU Lesser license
>agreement" (and the actual source files also refer to the LGPL),
>which seeems a bit confusing.
Just a note: ambiguities in the terms or scope of a license are
resolved in favor of the licensee.
Kelly
have had, at times, THOUSANDS of
custom gradients.) I'm not even sure that the PDB exports the reload
option, either.
>We shouldn't add more PDB interfaces to 1.1.x unless they fix a bug
Unexported functionality, IMO, is a bug.
Kelly
On Sun, 30 Jan 2000 02:09:21 +0100, Michael Natterer <[EMAIL PROTECTED]> said:
>The main part of this standard will be: "Use the libgimp
>constructors" ;-)
Are those documented anywhere? (yeah, right)
Kelly
On Sun, 30 Jan 2000 00:11:47 +0100, Marc Lehmann <[EMAIL PROTECTED]> said:
>If there were a way of adding a prominent notice like "DO NOT USE
>THIS BUG-TRACKER TO REPORT GIMP BUGS, INSTEAD, GO TO http..."...
Have you asked Sourceforge?
Kelly
at are badly exposed. IIRC, there's no
PDB call to create, modify, or destroy a palette. Indexed colormaps
are obvously editable or the GIF plugin wouldn't work. :)
Kelly
e I don't think palettes
are exposed to plug-ins well enough to do operations on them.
Kelly
On Sat, 29 Jan 2000 11:27:16 -0600 (CST), Dean Johnson <[EMAIL PROTECTED]> said:
>EVERY gui developer (casual or not) should be required to read
>Tufte's design books before being allowed to code.
Heh. Send me copies and I'll gladly read them. :)
Kelly
isting plug-ins, I
think would be nice of him to write up exactly what standards he
followed so we can have a nice document on plug-in UI standards. :)
Kelly
On Sat, 29 Jan 2000 10:53:54 +0200 (FLE Standard Time), Tor Lillqvist <[EMAIL PROTECTED]>
said:
>Drag small circles clockwise to increase V, counter-clockwise to
>decrease V, for instance. It's hard to say without experimenting...
Ew! What an evil idea!
Kelly
from 1.0 to 1.2. :)
Kelly
pace
>problem).
One of the things I would change is allow the user to specify where in
the menu system a plug-in goes, when it is installed. The plug-in
would provide a default. (Actually, I have a more progressive concept
than this, but it's not fully fleshed out.)
Kelly
Especially since
gnome-libs appears to depend on a library that is only available if
you have RPM installed.
Kelly
On Fri, 28 Jan 2000 21:40:56 +0100, Marc Lehmann <[EMAIL PROTECTED]> said:
>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. :)
Kelly
not
>the stable branch)?
No mirroring at all is my recommendation. Plug-ins should be out of
the main branch altogether starting with 1.3.
Kelly
. It is my considered position that the first thing
we should with 1.3 is remove all, or virtually all, of the plug-ins
from the standard distribution. Moving them to the gimp-plug-in
repository on sourceforge seems practical. All we need to do is
develop a good installer tool before 1.4 rolls, which will probably be
sometime in 2002.
Kelly
My position is sourceforge should be used at this time only for
plug-ins which are not already in the source tree. Such plug-ins will
not be a part of 1.2 anyway because 1.2 is frozen at this time. When
1.3 development begins, we can decide what to do with the plug-ins
currently in the distribution.
Kelly
wo
>different cvs servers.
Well, hopefully this sort of thing shouldn't have to happen; that
would occur because of a noncompatible interface change and I'd like
to think we can avoid that. (If the interfance needs to be changed,
we should offer a "legacy mode" so unadapted plug-ins continue to
function.)
Kelly
I can find no evidence that this is actually used anywhere in the
GIMP. Anybody know what it's for and whether it even works?
Kelly
package from the GIMP
core; I would be quite happy to see the plugin directory go away
_entirely_ from the main GIMP CVS. This really isn't that big a
deal. Lots of applications require multiple packages to get
"everything", and GIMP is a _large_ application.
Kelly
ing asked where to
install the plugin in the menu tree and so forth. I've never gotten
back to it, though.
Kelly
't gate
them automatically to their own folder, unlike this list, which means
they get at least trivial immediate attention.
PLEASE file bug reports, even if the matter seems trivial. Just try
to ensure that the report has enough information that a developer can
figure out what is going wrong.
Thanks,
Kelly
On Tue, 25 Jan 2000 20:53:30 +0100, Marc Lehmann <[EMAIL PROTECTED]> said:
>As a matter of fact, I couldn't. Why do you think I could?
Anybody can do anything, with enough effort. :)
Kelly
On Tue, 25 Jan 2000 13:54:33 +0100, Marc Lehmann <[EMAIL PROTECTED]> said:
>PLUGIN_MAINTAINERS is just a file... fatc is that bugs _do_ _not_ _get_
>_fixed_, so script-fu is basically unmaintained.
You could, of course, fix them yourself. :)
Kelly
Anybody understand what the guy in #2355 is asking for? It looks like
he wants DynText layers to rerender on layer scale, which would be
a major architectural change (not impossible, just not something that
should be squeezed in under a freeze). Is this just a user
misunderstanding?
Kelly
n. I
haven't approved it being added to CVS, and if nobody removes it
before I get around to it I'll do so myself. If nothing else, the UI
needs a lot of work before it should go in a production version.
Somebody please kick Martin in the butt for me.
Kelly
GPL. That's not saying
very much. :)
Kelly
t since 1.00) from CVS by
requesting specific versions of the splash file.
Kelly
g balloon)
>and the brush one could be modified for the About image?
We could be really evil and have multiple splash images, randomly
selected at startup. :)
Kelly
venient user-accessible parasite editor would make this sort of
thing MUCH friendlier -- instead of having to use magic cookie layer
names you'd just click on a button on the layer dialog and edit the
layer's externally-defined properties
Kelly
it is invalid. Gimp
>will then use the default set up by the user.
Please make sure that XCF loading is not exempt from these checks.
(XCF loads seem to bypass core sanity checking sometimes..)
Kelly
d of using pixel regions. Doing direct
iterations across a gimp image thrashes the system badly and is an
evil thing to do. Please rewrite your code to use pixel regions and
rerelease. (I'd do it myself but I'm on other tasks ATM.)
Kelly
y stronger legally (because the
notary can testify).
A copyright registration might not be sufficient since you're not
required to deposit the full source code for a TX Unpub registration.
It would provide evidence of prior art, at least; whether it would be
sufficient, I can't say. Ask a patent lawyer.
Kelly
d virtually useless. All doing that does is
provide proof of date of authorship. It ceased to be legally
meritorious in 1978 when the Copyright Act of 1976 took effect.
Kelly
Could someone with an Alpha look at bugs #2223 and #3414? Something
odd is going on here and I can't for the life of me figure out what.
Thanks,
Kelly
t's alive and well, but rather seriously divergent from the head
branch. Merging the two would be a substantial effort.
Kelly
d have to be
converted to standard 8-bit RGB (with concomitant information loss) to
be manipulated.
Kelly
On Thu, 21 Oct 1999 15:28:48 -0400, "Byong Mok Oh" <[EMAIL PROTECTED]> said:
>Hi, Has anyone written a plug-in that reads in a high dynamic range
>images?
You'll have to define what you mean by "high dynamic range image".
Kelly
em with using perl. People who don't have perl
installed (are there really such people anymore?) can manually install
things. :)
Kelly
to Perl's CPAN module would be a good idea for
GIMP plugins. Don't look at me to write it, though
Kelly
Adding more is just making a bad situation even worse.
Kelly
I am aware of the alternative to make a written offer. I didn't tell
them about that option because I would MUCH prefer that they
distribute the source. They can read the license for themselves if
they want to find out about the other option.
Kelly
urce along with
it.
Please immediately reply indicating that you intend to comply with the
license. Failure to comply may result in legal action being taken
against you.
Thank you for your cooperation in this matter.
Kelly Martin
84 matches
Mail list logo
