Re: An experiment (was Re: Move help menu item...)

2000-02-13 Thread Kelly Lynn Martin

On Thu, 10 Feb 2000 19:50:07 +0100 (CET), [EMAIL PROTECTED] said:

 Hm, couldn't we use the event handling system to automatically resize
 the toolbox to a new good value on every resize event:
 If you enlarge the toolbox the window size automatically snaps on the
 next convenient size and vice versa...

This can be dangerous; you can get a resizing loop if your code isn't
carefully written.  Window managers can refuse to accept a client
resize request or can modify it, which could result in a duel between
GIMP and the window manager as the two fight over who gets to decide
what size the window will be.

Kelly



Re: Toolbox layout and Help menu

2000-02-13 Thread Kelly Lynn Martin

On Fri, 11 Feb 2000 14:05:42 -0500 (EST), Glyph Lefkowitz [EMAIL PROTECTED] 
said:

It seems like this is really the only reasonable option -- I think
that there should be a 'menu' spot in the tools, like the top-left
menu in the image windows, since the toolbar is frequently too thin
for the menus anyway (vertical layout, try using a large font in your
gtk theme sometime...) and if it's not (horizontal layout), then the
menubar is taking up far too much screen real estate for no reason.

It would not be hard to add a "button" that pops up the menus.  People 
would probably go "Where the hell is the menu?" if we did that,
though.

Kelly



Re: Problems with gimp-1.1.17?

2000-02-13 Thread Kelly Lynn Martin

On Sat, 12 Feb 2000 17:32:41 + (GMT), Austin Donnelly [EMAIL PROTECTED] said:

Maybe we should make it our problem.

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?

Why not just 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



Re: resend

2000-02-13 Thread Kelly Lynn Martin

On Sun, 13 Feb 2000 10:06:24 -0500, Robert L Krawitz [EMAIL PROTECTED] said:

So one thing that springs to mind here is if the Gimp itself were to
warn if you attempt to exit while a plug-in is in progress of
execution.  Gimp folks, would that be feasible?  That would seem
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



Re: An experiment (was Re: Move help menu item...)

2000-02-13 Thread Kelly Lynn Martin

On Mon, 14 Feb 2000 14:21:39 -0500 (EST), Glyph Lefkowitz [EMAIL PROTECTED] 
said:

Rather than doing this, wouldn't it be possible to do the same thing
that terminals do, I.E. make the window resizable by char cells
rather than pixels?  I like the fact that I can resize 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



Re: CMYK when?

2000-02-09 Thread Kelly Lynn Martin

On Wed, 9 Feb 2000 19:47:42 -0500, Robert L Krawitz [EMAIL PROTECTED] said:

CMYK is a bit of an oddball subject.  Partly this is because there
are so many variants (CMY, CMYK, CcMmYK, CcMmYy, CcMmYyK), and partly
because (to the best of my knowledge) this color space is really 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



Re: Sample Colorize [Was: Re: Buggy plugins]

2000-02-07 Thread Kelly Lynn Martin

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



Re: Buggy plugins

2000-02-06 Thread Kelly Lynn Martin

On Sat, 05 Feb 2000 23:50:56 -0800, "Martin Weber" [EMAIL PROTECTED] said:

Here a list of buggy plugins in GIMP-1.1.16:
tileable blur plugin:
the status bar is appearing in an extra window
--
color exchange / color mapping plugins:
color selection: you can choose a color but black is taken instead
--
sample colorize plugin:
when starting this plugin you get:
Gtk-CRITICAL: file gtkwidget.c: line 3313 (gtk_widget_set_sensitive):
assertion 'widget!=NULL' failed.
--
max rgb / value invert plugins:
the effect is only applied to a small rectangle
--
curve bend plugin:
no undo possible
--
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



Re: Sample Colorize [Was: Re: Buggy plugins]

2000-02-06 Thread Kelly Lynn Martin

On Sun, 06 Feb 2000 19:04:12 -0500, "Garry R. Osgood" [EMAIL PROTECTED] said:

Personally, I think similiar tricks may be pulled fully in the confines
of the Curve tool, but as Marc pointed out, not everyone is a copy of me
(or is it 'a copy of Daniel Egger'? 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



Re: important: automatic mirroring to the gimp cvs

2000-02-05 Thread Kelly Lynn Martin

On Fri, 28 Jan 2000 01:38:32 +0100, Marc Lehmann [EMAIL PROTECTED] said:

Ok. I've just enabled automatic mirroring from the sourceforge cvs
back to the gimp cvs.

FWIW, I think this should be used sparingly.  It is my belief that
we should try to move plugins into a separate 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



Re: Plugins at Sourceforge

2000-02-05 Thread Kelly Lynn Martin

On Fri, 28 Jan 2000 12:40:32 -0500, Zach Beane - MINT [EMAIL PROTECTED] said:

Count this as a cry out against it. I suggest waiting for a logical
pause in development, such as the release of GIMP 1.2, to begin
making these not-insubstantial changes in source management.

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



Re: Removing pencil?

2000-02-05 Thread Kelly Lynn Martin

On Sat, 5 Feb 2000 11:45:16 +0100 (CET), [EMAIL PROTECTED] said:

 I think it's time to remove that useless pencil before the release
of the magic version 1.2. Did anyone use it in the last time?  It
contains no functionality that paintbrush doesn't have except of hard
edges (anyone needing that "feature"?)...

I find it very useful when working on small pixmaps (like icons).

Kelly



Re: story on advogato

2000-02-05 Thread Kelly Lynn Martin

On Sat, 5 Feb 2000 21:00:19 -0700 (MST), "Michael J. Hammel" 
[EMAIL PROTECTED] said:

The last comment I saw under this story said that a $2K award was
given to "Wilbur the Gimp".  Since Gimp has no non-profit (or for
profit) organization, who got that money?  Just curious.

It goes to Yosh, who will decide what to do with it.

Kelly



Re: Plugins at Sourceforge

2000-02-05 Thread Kelly Lynn Martin

On Sat, 5 Feb 2000 12:33:38 -0800, "Michael J. Hammel" [EMAIL PROTECTED] 
said:

I'm curious why any new plug-ins should be added to the core *at
all*.  Gimp's distribution is fairly large as it is.  Isn't it
getting time to limit additional plug-ins to the core distribution to
plug-ins which are considered "vital" in some way?  Even some estoric
file plug-ins need not necessarily be included with the core package.
Throwing in the kitchen sink is what's starting to bloat some Linux
distros.

I couldn't concur with you more.  I'm radical enough to suggest taking
all the plugins out of the standard distribution entirely. :)

Kelly



Re: Performance

2000-02-04 Thread Kelly Lynn Martin

On Fri, 4 Feb 2000 09:52:30 +0100 (MET), [EMAIL PROTECTED] (Raphael Quinet) said:

I disagree.  This would only encourage some users to re-compile their
own version of the Gimp in a private directory in order to get around
the hardcoded limits.

Frankly, I disagree.  Systems where admins are likely to impose such
restrictions are going to be ones where users don't have enough space
to compile private copies of Gimp.

Being a system administrator myself, I believe that an admin should
always suggest some limits (and maybe use some social engineering to
encourage users to respect these limits) but should avoid hard
limits.   

It depends on the kind of users you have and the hardware you're
running.  Imposing hard limits is sometimes the only way to deal with
certain types of users.

On the other hand, if ulimits are used to limit the maximum file size
or CPU usage, there is not much that we could do about it.  Same if
disk quotas are activated.  The Gimp can have some control over its
memory usage, but many parts of the code assume that the disk space
is unlimited (or is not the main constraint).

Yup.  It might be nice to catch SIGXCPU and try to do an orderly
shutdown before the SIGKILL does ya' in, though. :)

Kelly



Re: Edit Fille behaviour change?

2000-02-04 Thread Kelly Lynn Martin

On Fri, 4 Feb 2000 19:07:37 -0500, Zach Beane - MINT [EMAIL PROTECTED] said:

Fill (by default Ctrl-.) has filled using the background colour in
the GIMP for as long as I can remember. I don't think it's a bug
[snip]

I agree. I have grown very accustomed 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



Re: Performance

2000-02-03 Thread Kelly Lynn Martin

On Thu, 3 Feb 2000 19:33:31 +0100 (CET), [EMAIL PROTECTED] said:

 If you have a shared maschine the best would be to let the
administrator choose how much memory each user will get because
users'll ALWAYS try to get what they can even if it makes no
sense

It might be a 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



Re: Print plug-in

2000-02-01 Thread Kelly Lynn Martin

On Tue, 01 Feb 2000 13:19:03 +0100, Torsten Rahn [EMAIL PROTECTED] 
said:

Of course I read on the
Gnome-Office-site that Gimp would be part of Gnome-Office. Well I was
quite surprised to read that as I didn't see any discussions about
this topic here.

GNOME claims 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



Re: Print plug-in

2000-02-01 Thread Kelly Lynn Martin

On Tue, 1 Feb 2000 19:09:14 +0100 (MET), [EMAIL PROTECTED] (Raphael Quinet) said:

This statement is ridiculous.  They are not claiming that they wrote
the GIMP.  They just state that it will be included as part of the
Gnome-Office suite.

You'd think they talk to the GIMP developers before making that claim,
no?

In case you did not know that, will this fact make you stop using the
GIMP completely just because you think that some of the people on
this list have GNOME stamped on their forehead?

No, but I will stop using the GIMP if it begins to require Gnome
libraries (or, actually, I will split development).

My personal opinion: I'm all for using some of the GNOME things
(especially gnome-font, gtk-pixbuf and gnome-canvas) as long as they
do not have any dependencies on ORBit or other stuff that is
difficult to compile on non-Linux systems or stuff that is simply not
needed.

If Gnome gets its act together and properly cleans up their library
offerings so it's not as monolithic and pointlessly dependent on ORBit
I'll consider using some of their utility libraries.  (GIMP really
should use libart, but until libart is easily available separately
from gnome-libs, we can't.)

Kelly



Re: Print plug-in

2000-02-01 Thread Kelly Lynn Martin

On Tue, 1 Feb 2000 13:15:17 -0600 (CST), Tim Mooney [EMAIL PROTECTED] 
said:

I agree that would be the best solution, but I'm afraid it's not that
easy.  I've submitted quite a few very small portability patches
against ORBit from as far back as the 0.3.X days, and virtually every
one of my patches has been rejected.

I reported a "secret dependency" in ORBit on popt 1.4, and provided a
simple patch.  It has been ignored, and now Quartic is accusing me of
"spreading FUD" even though I've clearly and publically documented
that 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






Re: Print plug-in

2000-02-01 Thread Kelly Lynn Martin

On Tue, 1 Feb 2000 15:11:13 -0500 (EST), Glyph Lefkowitz [EMAIL PROTECTED] 
said:

No, and it's their right not to.  If you believe this should be a
requirement, it should be part of the license.  GIMP is a part of Red
Hat Linux, why shouldn't it be a part of the GNOME office suite?

If I recall correctly, GIMP is licnsed under the GPL, which means as
long as the developers provide the source code changes that they
make, they can make the GIMP a part of anything they damn well
please.

Too many people use this license without understanding (or
considering fully) what it means...

You're confusing legal rights with moral obligations.  

Since you raised legal nonsense, though, it's technically illegal for
GNOME to use the GIMP trademark for promotional purposes without a
license from the GIMP Development Team.  The GPL grants a software
license in copyright; it does NOT grant any rights to any other
property, intellectual or otherwise.  

Kelly



Re: Print plug-in

2000-02-01 Thread Kelly Lynn Martin

On Wed, 2 Feb 2000 03:31:31 +0100, Marc Lehmann [EMAIL PROTECTED] said:

"gnome", just like "kde" are very much political terms nowadays, and
it's very nice to work on a projetc that just wants to be good, and
is not generally linked to some political term (even if the gnomekde
communities themselves might feel the same).

Did you miss all the screaming when there was initial talk of a Win32
port? :)

Kelly



Re: Print plug-in

2000-02-01 Thread Kelly Lynn Martin

On Tue, 1 Feb 2000 17:24:35 -0600, "Shawn T . Amundson" [EMAIL PROTECTED] said:

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.

I was referring to the commercial Netscape product, rather than
Mozilla.  I can't speak to why Mozilla made the decision to use their
own toolkit.

Kelly



Re: Plugins at Sourceforge

2000-01-31 Thread Kelly Lynn Martin

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



Re: Print plug-in

2000-01-31 Thread Kelly Lynn Martin

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.  If you read gnome-hackers you'd already know about it since I
posted there about this problem.

ORBit would NOT build on my old slackware box until I installed this
undocumented library.

GNOME has a _lot_ of problems that it needs to clean up before it's
ready for prime time on anything other than relatively vanilla RH or
Debian box.

Kelly



Re: Print plug-in

2000-01-31 Thread Kelly Lynn Martin

On Tue, 1 Feb 2000 01:18:54 +, Nick Lamb [EMAIL PROTECTED] said:

From the user's perspective The Gimp is part of GNOME. 

There's no good reason for users to have this perception, though,
since the only relation GIMP has with GNOME is that GNOME uses GIMP's
custom-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



Re: Print plug-in

2000-01-31 Thread Kelly Lynn Martin

On Mon, 31 Jan 2000 21:30:48 -0500, Robert L Krawitz [EMAIL PROTECTED] said:

I'd argue that except for gconf and MAYBE gnome-canvas none of this
stuff belongs in GNOME at all; these are all very generic facilities
that shouldn't depend on any of the IPC, desktop, etc. stuff.
Otherwise we wind up with the same kind of confusion and versioning
problems that Windows has suffered with for so long.

THis is one of my big annoyances with GNOME currently: there's a lot
of useful libraries that really have nothing to do with GNOME but
which are not separately exported, forcing you to install all the junk
you don't want to get the stuff you do.

Kelly



Re: Colormanagement

2000-01-30 Thread Kelly Lynn Martin

On Sun, 30 Jan 2000 11:51:37 +0200 (FLE Standard Time), Tor Lillqvist [EMAIL PROTECTED] 
said:

Another thing is the licensing. The webpage says: "lcms is free and
source code is also provided, with only one limitation: you can do
whatsever you want with the code, except 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



Re: Colormanagement

2000-01-30 Thread Kelly Lynn Martin

On Sun, 30 Jan 2000 21:53:25 +0100, Marc Lehmann [EMAIL PROTECTED] said:

As long as they do not claim that their code is ANSI-C. I can
remember my first (and last) patch to the KDE developers that
converted their code to real C++, and they told me "F*ck off! Get a
real c++ compiler!". Ever since I became sensitive with such claims
;)

That's KDE for ya. :)

Kelly



Re: The Gimp: New Generation

2000-01-29 Thread Kelly Lynn Martin

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



Re: feature requests?

2000-01-29 Thread Kelly Lynn Martin

On Sat, 29 Jan 2000 21:53:47 +, Nick Lamb [EMAIL PROTECTED] said:

All the existing plug-ins that work with palettes (INDEXED images
would be even more useless than they already are if no plug-ins could
work with them) use calls like:

I guess it's GIMP palettes that 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



Re: feature requests?

2000-01-29 Thread Kelly Lynn Martin

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



Re: feature requests?

2000-01-29 Thread Kelly Lynn Martin

On Sun, 30 Jan 2000 01:31:52 +, Nick Lamb [EMAIL PROTECTED] said:

Gimp palettes are files :)

Yes, but when you have LOTS of custom palettes, having "Reload" as the
only way to get a new palette into the GIMP is NOT pleasant.  (I have
hundreds of custom palettes and 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



Re: The Gimp: New Generation

2000-01-29 Thread Kelly Lynn Martin

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



Re: The Gimp: New Generation

2000-01-29 Thread Kelly Lynn Martin

On Sat, 29 Jan 2000 10:59:23 +0100, Sven Neumann [EMAIL PROTECTED] said:

This is handled much better after Mitch overworked most plug-ins UI 
once again. If you still find places that should be changed, please 
provide a patch.

If Mitch has gone to the effort to normalize existing 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



Re: The Gimp: New Generation

2000-01-29 Thread Kelly Lynn Martin

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



PDB_PASS_THROUGH

2000-01-28 Thread Kelly Lynn Martin

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



Re: Plugins at Sourceforge

2000-01-28 Thread Kelly Lynn Martin

On Fri, 28 Jan 2000 17:29:48 +0100, Marc Lehmann [EMAIL PROTECTED] said:

As it is now there is the slight danger that the "self-management"
can cause _more_ work for the maintainers. If Sven has to od a
one-line change in every plug-in he would be force to use two
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



Re: important: automatic mirroring to the gimp cvs

2000-01-28 Thread Kelly Lynn Martin

On Fri, 28 Jan 2000 18:49:29 +0100, Marc Lehmann [EMAIL PROTECTED] said:

I am determined to branch the gimp-plug-ins tree at the same moment
the original gimp-cvs tree creates a stable branch. I guess that
might be the right moment to enable mirroring (to the main trunk, 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



Re: Plugins at Sourceforge

2000-01-28 Thread Kelly Lynn Martin

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



Re: Print plug-in

2000-01-28 Thread Kelly Lynn Martin

On Fri, 28 Jan 2000 18:03:32 -0500, Federico Mena Quintero [EMAIL PROTECTED] 
said:

(As for footprint, well, the GIMP is not terribly lightweight either)
:-)

GIMP's a lot lighter than gnome-libs.  I would substantially oppose
any serious dependence on gnome-libs in GIMP.  Especially since
gnome-libs appears to depend on a library that is only available if
you have RPM installed.

Kelly



Re: Plugins at Sourceforge

2000-01-28 Thread Kelly Lynn Martin

On Fri, 28 Jan 2000 23:47:25 +0100, Marc Lehmann [EMAIL PROTECTED] said:

Most (but of course not all) of the problems are related to the fact
that the menus are too full and can'T be changed, not necessarily
that too many plug-ins are installed (which is mostly a diskspace
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



Re: Plugins at Sourceforge

2000-01-28 Thread Kelly Lynn Martin

On Fri, 28 Jan 2000 11:55:20 -0700 (MST), "Michael J. Hammel" 
[EMAIL PROTECTED] said:

I'm curious why any new plug-ins should be added to the core *at
all*.  Gimp's distribution is fairly large as it is.  Isn't it
getting time to limit additional plug-ins to the core distribution to
plug-ins which are considered "vital" in some way?  Even some estoric
file plug-ins need not necessarily be included with the core package.
Throwing in the kitchen sink is what's starting to bloat some Linux
distros.

I agree entirely.  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



Re: [gimp-devel] Re: End-user feedback: Perl logulator innerbevel

2000-01-26 Thread Kelly Lynn Martin

On Wed, 26 Jan 2000 05:12:43 -0500, "Garry R. Osgood" [EMAIL PROTECTED] said:

It is a disservice to individuals on the periphery of the Gimp support
effort who, finding themselves with a spare weekend and a permissive
spouse, then have to trek through message lists to see what's up. 

I read this list infrequently; I have been known to go months without
looking at it.  (I got unsubscribed once and didn't realize it for
five months.)  On the other hand, the bug list I check frequently and
I at least look at bug reports whenever they come in.  I don'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



Re: Speaking of additional plug-ins

2000-01-26 Thread Kelly Lynn Martin

On Wed, 26 Jan 2000 14:31:52 +, "Steinar H. Gunderson" [EMAIL PROTECTED] 
said:

Better yet, a GIMP interface. If we are to change the entire plug-in
architecture anyway, we should make a single way of compiling and installing
them.

I've thought about this somewhat.  I had a vague idea in mind for how
to redo the UI for 1.4/2.0, which included a considerably different
way of handling plugins.  Plugins would be installed w/i the Gimp
interactively (a noninteractive installation procedure would be
offered for system administrators) with the user being asked where to
install the plugin in the menu tree and so forth.  I've never gotten
back to it, though.

Kelly



Re: [gimp-devel] Re: End-user feedback: Perl logulator innerbevel

2000-01-25 Thread Kelly Lynn Martin

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



Re: [gimp-devel] Re: End-user feedback: Perl logulator innerbevel

2000-01-25 Thread Kelly Lynn Martin

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



bug #2355

2000-01-23 Thread Kelly Lynn Martin

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



Re: Addition of new plug-ins

2000-01-21 Thread Kelly Lynn Martin

On Fri, 21 Jan 2000 00:44:36 +0100, Sven Neumann [EMAIL PROTECTED] said:


Hi,
tonight two new plug-ins were checked into the tree. I now that we have not 
officially declared a plug-in freeze, but I think it was somehow clear that 
it is too late to add new plug-ins. The CVS ChangeLog claims:

Thu Jan 20 23:28:35 CET 2000  Stanislav Brabec  [EMAIL PROTECTED]

Added new plug-ins from Martin Weber [EMAIL PROTECTED]:
* plug-ins/common/kaleidoscope.c: New file.

I haven't looked but I assume this is my kaleidoscope plugin.  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



Re: Thanks (Re: Gimp splash images)

2000-01-15 Thread Kelly Lynn Martin

On Mon, 10 Jan 2000 18:43:23 +, alex [EMAIL PROTECTED] said:

Maybe the earlier splash images were only distributed in GIF format,
but then they moved to PPM after Burn All GIFs? Just a guess.

The splash images have always been PPMs.

You can retrieve all of them (at least since 1.00) from CVS by
requesting specific versions of the splash file.

Kelly



Re: gimp SWF plugin

2000-01-15 Thread Kelly Lynn Martin

On Sat, 15 Jan 2000 22:22:05 +0100, Marc Lehmann [EMAIL PROTECTED] said:

I don't see the problem (yet)? Plug-ins do not need to be GPL'ed (at
least not when the last rmeaining license bits have been resolved
;-)

They do, however, have to be compatible with LGPL.  That's not saying
very much. :)

Kelly



Re: Thanks (Re: Gimp splash images)

2000-01-13 Thread Kelly Lynn Martin

On Thu, 13 Jan 2000 09:45:50 -0800 (PST), Arcterex [EMAIL PROTECTED] said:

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 image?

We could be really evil and have multiple splash images, randomly
selected at startup. :)

Kelly



Re: [ANNOUNCE] GimpMill - A Sawmill Theme Tool

2000-01-11 Thread Kelly Lynn Martin

On Tue, 11 Jan 2000 00:55:10 +0800, Ian McKellar [EMAIL PROTECTED] said:

For each of the frame parts create a separate layer in the way
described above, but call each of these "PART: name" where name will
be used in the image name. To set frame part attributes append "name
= value" pairs to the frame part's layer's name (e.g. "PART:
closebutton class=close-button"). Finally to specify the difference
between the default frame decoration and the focussed, mouseover, etc
decoration you can optionally create layers called NORMAL, FOCUSED,
HIGHLIGHTED and CLICKED. These are merged with frame part layers
before they're saved. Often a black layer with 50% opacity in
"Multiply" mode will be what you're after, but if nececarry you can
provide complete replacement images.

A convenient 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



Re: [gimpwin-users] PNG blank display bug

2000-01-08 Thread Kelly Lynn Martin

On Sat, 08 Jan 2000 13:21:44 +0100, Sven Neumann [EMAIL PROTECTED] said:

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 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



Re: New plug-in

2000-01-07 Thread Kelly Lynn Martin

On Fri, 7 Jan 2000 11:16:54 -0500 (EST), Glyph Lefkowitz [EMAIL PROTECTED] 
said:

IANAL either, but the "quick and dirty" solution to this is just to print
out the code to your plugin, stick it in an envelope, and mail it to
yourself.

This is archaic advice, and 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



Re: New plug-in

2000-01-07 Thread Kelly Lynn Martin

On Fri, 07 Jan 2000 17:03:59 +0100, [EMAIL PROTECTED] (Guillermo S. Romero / Familia 
Romero) said:

A question about patents. Is putting something on the web enough to
prevent someone patenting it, or could someone download my plug-in and
then patent the algorithm?

Your plugin is prior art so patents can not be taken. But web is still a
weird place, so you will have to convice lawyers that it is your and since
day X.

What I would do is to register your plugin (copyright office) or get an
official stamp (notary? I hope that is the correct word for the guy who does
that). In other words, an official doc that says that since day X your app
exists, and is yours.

The best thing I can think of is to have a copy of the source code
notarized and stored in a safe-deposit box.  You could mail it to
yourself, but a notarization is probably 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



Re: New plug-in

2000-01-07 Thread Kelly Lynn Martin

On Fri, 7 Jan 2000 23:40:02 +1100 (EST), Paul F Harrison [EMAIL PROTECTED] said:

I have made a plug-in that does some interesting things, like applying
a theme taken from one image and applying it to another, or making an
image tilable. More details at

http://yoyo.cc.monash.edu.au/~pfh/fixer/

This is my first plug-in (and my first post to this list). Any comments
would be appreciated, especially about any GIMP conventions i may have
inadvertantly missed.

It's incredibly slow, probably because you did a naive iteration
across the image instead 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



Re: high dynamic range images

1999-10-21 Thread Kelly Lynn Martin

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



Re: Plugins

1999-10-18 Thread Kelly Lynn Martin

On Sat, 16 Oct 1999 22:31:09 +0200, Marc Lehmann [EMAIL PROTECTED] said:

So lets talk about alternative and sensible ways to solve this. ACE
is definitely more useful for the average gimp user than gap or
mosaic (although these are highly useful to some).

IMO, something akin to Perl's CPAN module would be a good idea for
GIMP plugins.  Don't look at me to write it, though

Kelly