Hi,
Martin Weber [EMAIL PROTECTED] writes:
Could we now start and add new plugins to GIMP cvs?
No, but we should settle on a system for plug-in development,
maintainance and distribution and start to move plug-ins out
of gimp CVS soon. Some ideas have come up, but the discussion
calmed down
Could we now start and add new plugins to GIMP cvs?
Martin
--
Sent through GMX FreeMail - http://www.gmx.net
Tuomas Kuosmanen ([EMAIL PROTECTED]) wrote:
Speaking of old stuff to be ported to 1.2.. If I remember correctly, the 0.54
version (yes, kids. It did exist and it ruled.) had antialiased Threshold
tool.
Hmm - i just compiled gimp 0.54 and did not manage to find *any* threshold
function. Can
On Fri, Dec 29, 2000 at 05:48:07PM +0100, thus said Simon Budig:
Martin Weber ([EMAIL PROTECTED]) wrote:
Now that we have the new gimp 1.2.0 out, we should think about adding
new plugins to the gimp. Here my proposal:
Speaking of old stuff to be ported to 1.2.. If I remember correctly
Now that we have the new gimp 1.2.0 out, we should think about adding
new plugins to the gimp. Here my proposal:
1. Stable plugins:
Anti-Alias 0.8.1
Fixer
Homogenizer
logconv-1.2.1
mathmap-0.12 (make seamless in 0.11 works correctly in the Linux
version, but in the windows version, the picture
Martin Weber ([EMAIL PROTECTED]) wrote:
Now that we have the new gimp 1.2.0 out, we should think about adding
new plugins to the gimp. Here my proposal:
Basically the number of plugins distributed with the gimp will most probably
shrink. We are thinking about a new scheme of distributing
I was recently looking at the possibility of a gimp tile editor. After looking in to
it I have
found that this is really quite difficult to do with the plugin api.
As far as I can see it would be possible but at the user end it would be messy.
The plugin would have to create a new canvas,
tile editor? you so you can make seamles tiles? (im guessing here, dont
know what you mean by tile editor)
maybe just make a plug in that displays the drawable(s) in an offset view.
of course you would have to have an update button or poll the image
regularly or something silly like that (which
On Mon, 7 Feb 2000, Tuomas Kuosmanen wrote:
On Sun, Feb 06, 2000 at 07:04:12PM -0500, Garry R. Osgood wrote:
[zap]
What it does:
[zap]
So it is basically Gradient Map on steroids?
Tuomas
I experimented with it a little last night. The thing rocks!
--
Jon Winters
Sven Neumann wrote:
Hi,
snipped...
If you'd ever
seen how Karin turns an old b/w photo into a colored one in a few minutes,
you would know how good and useful his plug-in really is. (I had the
chance to make this joyful experience last year in Berlin, when Karin and
Olof presented the
Hi,
So it is basically Gradient Map on steroids?
The option to use a gradient as colorsource is an extra goodie. The normal
usage is colorizing grayscale photos with the use of color photos as color
source. Ever tried to colorize human skin using standard techniquees like
painting in color
Martin Weber wrote:
Here a list of buggy plugins in GIMP-1.1.16:
snipped...
Did you make bug reports of these?
(http://www.xach.com/gimp/news/bugreport.html)
1. With 55 days (count'em) to a supposed release date,
and lots of issues outstanding, Gimp needs all the resources
it can possibly
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 sele
On Sun, Feb 06, 2000 at 11:41:50AM +0200, Tuomas Kuosmanen [EMAIL PROTECTED] wrote:
If I remember correctly the progress window also happens on lot of the save
plugins. In theory those all could be in the statusbar if the window has
The api for that, however, is quite a hack. If you call
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
In ChangeLog :
Fri Jan 28 01:16:35 CET 2000 Marc Lehmann [EMAIL PROTECTED]
* PLUGIN_CVS: updated to give Kevin Turner write access to
the maze plug-in (therefore, the maze plug-in is no longer
managable within the gnome cvs server. If you have any
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
' release before they get all the new nifty
functionality that 1.2 has to offer.
So get the GIMP 1.2 release out, with the crufty plugins and all, and THEN
start making changes like this. for 2.0.
---
Even if you can deceive people about a product through misleading statements,
sooner or later
cing a unitary build, then eventually we have everything
depending upon everything else, and we get into the Windows mess all
over again. It *must* be possible to build and install plugins
separate from the Gimp tree.
Now, that doesn't mean that anything should change *right now*. It's
entirely too
Michael J. Hammel spontaneously blurts out:
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?
-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
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
which are set up by GIMP at startup time not
by the plugins...
GTK supports internationalization, right?
Errr, let's say: a little bit
So
shouldn't the plug-ins be responsible for the language issues?
Yes, they SHOULD, but it's not possible, at the moment...
--
Servus
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
Thus spoke Marc Lehmann
This is not at all a distribution issue. Linux is a *multi*-user system, so
there is not much sense in tailoring the number of installed plug-ins to the
needs of, say, the admin.
Playing the devils advocate here, you could also say there is not much
sense in tailoring
On Fri, 28 Jan 2000, Michael J. Hammel wrote:
Thus spoke Marc Lehmann
This is not at all a distribution issue. Linux is a *multi*-user system, so
there is not much sense in tailoring the number of installed plug-ins to the
needs of, say, the admin.
Playing the devils advocate here,
On Fri, Jan 28, 2000 at 07:14:49PM -0700, "Michael J. Hammel"
[EMAIL PROTECTED] wrote:
There are some menus that need adjusting to reduce the number of entries.
Some menus (like the file type in the file dialog) still are unusable with
some font/screen combination since most of it will be
In ChangeLog :
Fri Jan 28 01:16:35 CET 2000 Marc Lehmann [EMAIL PROTECTED]
* PLUGIN_CVS: updated to give Kevin Turner write access to
the maze plug-in (therefore, the maze plug-in is no longer
managable within the gnome cvs server. If you have any
On Fri, Jan 28, 2000 at 05:29:48PM +0100, Marc Lehmann wrote:
[snip]
However, since the masses haven't cried out yet, I guess we can try and
see how it works in practise.
Count this as a cry out against it. I suggest waiting for a logical pause in
development, such as the release of GIMP
' release before they get all the new nifty
functionality that 1.2 has to offer.
So get the GIMP 1.2 release out, with the crufty plugins and all, and THEN
start making changes like this. for 2.0.
---
Even if you can deceive people about a product through misleading statements,
sooner or later
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
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
On Fri, Jan 28, 2000 at 02:36:36PM -0700, "Michael J. Hammel"
[EMAIL PROTECTED] wrote:
They do make it moderately easy during installation, but the default
installations include lots of things many users will never need. But
This is not at all a distribution issue. Linux is a *multi*-user
Thus spoke Zach Beane - MINT
On Fri, Jan 28, 2000 at 05:29:48PM +0100, Marc Lehmann wrote:
[snip]
However, since the masses haven't cried out yet, I guess we can try and
see how it works in practise.
Count this as a cry out against it. I suggest waiting for a logical pause in
Thus spoke Kelly Lynn Martin
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
On Thu, 30 Dec 1999 [EMAIL PROTECTED] wrote:
I'm trying (and succeeding!) to build a binary distribution for the Gimp
(1.1.14) on AIX 4.3.2. Everything appears to work, except for the
perl plugins, which generate a core. "make test" in
.../gimp-1.1.14/plug-ins/perl produces:
Hello,
The attached patch should fix different bugs in different plugins
written in Perl in Gimp V 1.1.14. The patch is mostly an updated
version of the patch I send some weeks ago. The things the patch
should fix:
- In the blowinout, innerbevel, randomblends, terral_text, and
windify
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
You wrote on Mon, 08 Nov 1999:
Would it still be a problem for you if only the menu entry itself is
english, but the english menu is sorted under the corresponding german
standard menu (see above for "Add Selection")?
Oh, it's not for me ;-) I think about all the "only" users. I use gimp in
Hi Marc,
Marc Lehmann wrote:
On Wed, Nov 03, 1999 at 10:20:37AM +0100, Michael Natterer
[EMAIL PROTECTED] wrote:
I was (or at least tried to be) very careful not to change any external
interface (which I suppose you mean by "cause other changes as well")
with the context changes
On Tue, Nov 09, 1999 at 11:07:32AM +0100, Uwe Koloska [EMAIL PROTECTED]
wrote:
So what I wanna say: All that makes two menus of the same manner disappear is
a bugfix. The other things like improvement of the i18n-Code to make it
consistent and in toto able to translate all messages is the
On Wed, Nov 03, 1999 at 11:07:32AM +0100, Uwe Koloska [EMAIL PROTECTED]
wrote:
I don't know anything about the actual CVS-release but with 1.1.10 I have to
disable nls-support, because there are so many doubled menus (some german, some
english). Maybe it's because I'm using a libc5 based
On Sun, Nov 07, 1999 at 08:39:51PM +0100, [EMAIL PROTECTED] wrote:
This sounds interesting (explain!).. how can i18n lead to segfaults?
Not again Marc, we have had this discussion before
You told me that all my menus would be shown twice (which was a problem on
your machine only).
On Wed, Nov 03, 1999 at 10:20:37AM +0100, Michael Natterer [EMAIL PROTECTED]
wrote:
I was (or at least tried to be) very careful not to change any external
interface (which I suppose you mean by "cause other changes as well")
with the context changes because playing around with the PDB
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
[EMAIL PROTECTED] 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"...
You mean the context and dnd stuff... Well, as Olof has already
Marc Lehmann wrote:
Note: At the moment featurefreeze is more violated by the changes done
by for example Michael
Or Sven! Even worse, Sven's changes required me to add something else
(which is not bad, but it introduced instabilities again), and Michaels
changes are very likely to
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 Fri, Oct 29, 1999 at 11:46:30PM +0200, [EMAIL PROTECTED] wrote:
Should we leave the plug-ins as they are know or bugfix them i18n-wise?
Real design bugs can´t be solved for 1.2, so either we can do it
painlessly or we can´t do it (in 1.2).
bugfixing way... Otherwise I would suggest du
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
installing this package, the user would customize the gimp for his special
needs by adding special functionality
For example this would like:
gimp-plugins-artistic (gimppressionist, mosaic, oilify, ...)
gimp-plugins-webdesign (imagemap, html, animoptimize
On Mon, Oct 18, 1999 at 10:04:35AM -0500, Kelly Lynn Martin
[EMAIL PROTECTED] wrote:
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
plug-ins that don't compile or don't survive beta tests just wouldn't be
distributed (or the plug-in cvs would become a seperate tarball, which
IMHO is not useful, though).
What do we do for i18n? Today, there are two translation files:
gimp - core
gimp-std-plugins - plugins
On Mon, Oct 18, 1999 at 11:53:09AM -0400, [EMAIL PROTECTED] wrote:
organization of the translation effort (if there is to be one at all).
What is needed is a place where programmers can put their plug-ins
(and their associated *.po files) and where translators, who are
presumably different
56 matches
Mail list logo
