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 dow
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 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 whic
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
Date: Sat, 5 Feb 2000 12:33:38 -0800
From: "Michael J. Hammel" <[EMAIL PROTECTED]>
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 pl
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 th
On Fri, 28 Jan 2000, Zach Beane - MINT wrote:
> 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
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.
We
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 sourc
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
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
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
On 28 Jan, Michael J. Hammel wrote:
> Do you mean language locales? I'm not very familiar with working with
> multi-language issues, but I have wondered why this isn't handled by
> the plug-ins directly.
Because it won't work entirely this way... localisation works for
everything but the menu
On 28 Jan, Kelly Lynn Martin wrote:
>>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. :)
Do you volunteer?
--
Servus,
Daniel
> > This is not at all a distribution issue. Linux is a *multi*-user system, so
>
> a good answer for it. From my point of view, Gimp is not a multi-user tool
> (even if it can run happily on multi-user systems) so should be packaged
> for single users. University admins would probably argue ot
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 ou
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
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 tailorin
On Fri, 28 Jan 2000 19:18:53 -0500, Robert L Krawitz <[EMAIL PROTECTED]> said:
>And yes, I agree with Michael also that 2002 is not a reasonable
>target for the next stable release of the Gimp.
Target dates are impossible to stick to. I offered 2002 because it
took two years to go from 1.0 to 1
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
From: "Michael J. Hammel" <[EMAIL PROTECTED]>
Date: Fri, 28 Jan 2000 14:31:15 -0700 (MST)
Cc: [EMAIL PROTECTED] (Gimp Developer List)
Thus spoke Kelly Lynn Martin
> I agree entirely. It is my considered position that the first thing
> we should with 1.3 is remove all, or virtua
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
Thus spoke Marc Lehmann
> Well, most distros tend to compile every optional feature they cna find
> into a program. It's already not too difficult to tailor a distribution,
> but nobody does that.
They do make it moderately easy during installation, but the default
installations include lots of t
Thus spoke Kelly Lynn Martin
> 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
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, Jan 28, 2000 at 04:09:55PM -0500, Kelly Lynn Martin
<[EMAIL PROTECTED]> wrote:
> >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. :)
Wel... w
On Fri, Jan 28, 2000 at 11:55:20AM -0700, "Michael J. Hammel"
<[EMAIL PROTECTED]> wrote:
> 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
One goal of the seperate cvs is to make the choice between "
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-i
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 th
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
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 sourc
On Fri, 28 Jan 2000, Zach Beane - MINT wrote:
> 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
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.
We
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 1
On Fri, Jan 28, 2000 at 04:42:57AM -0500, "Garry R. Osgood" <[EMAIL PROTECTED]> wrote:
> Maybe there ought to be a line in PLUGIN_MAINTAINERS indicating
> where "authoritative source" resides?
I'll put the word "sourceforge" into the COMMENT field of any such
plug-ins.
Does anybody know of a way
On Sat, Nov 13, 1999 at 03:50:47PM +0100, Michael Natterer <[EMAIL PROTECTED]>
wrote:
> Hm, I don't exactly know how the plug-in stuff works but there surely
> is a pipe to each client and the gimp (or gtk) does a select() at some
> place to wait for the pipes' file descriptors.
Many clients can
Hi Marc,
Marc Lehmann wrote:
>
> On Tue, Nov 09, 1999 at 05:14:07PM +0100, Michael Natterer
><[EMAIL PROTECTED]> wrote:
> > Do you want to use context functions at the pdb interface? (ie writing
> > stuff like gimp_context_get_brush(NULL)) and put all current color/brush/...
> > access function
On Thu, Nov 11, 1999 at 08:34:59PM +0100, [EMAIL PROTECTED] wrote:
>
> Got me here, but since I don't exactly know what the bug is I can
> hardly explain it. I just know the symptoms and you do, too...
You told me that, but I neither buy your explanation nor do I experience
this bug myself.
>
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 b
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 wri
On Tue, Nov 09, 1999 at 05:14:07PM +0100, Michael Natterer <[EMAIL PROTECTED]>
wrote:
> Do you want to use context functions at the pdb interface? (ie writing
> stuff like gimp_context_get_brush(NULL)) and put all current color/brush/...
> access functions to gimpcompat.[ch] or just let all clien
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 t
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 chan
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
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 in
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 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 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
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-translat
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 "usin
Marc Lehmann wrote on Mit, 03 Nov 1999:
>On Tue, Nov 02, 1999 at 03:07:49PM +0100, [EMAIL PROTECTED] wrote:
>>
>> And I can't think of something more bad than halfdone things... we even
>> have Plug-ins which are half-translated... nice feature, right?
>
>Well, half-translated is surely better t
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 lik
[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 alrea
On Tue, Nov 02, 1999 at 03:07:49PM +0100, [EMAIL PROTECTED] wrote:
> At the moment the localisation of plug-ins is really buggy. Of course
> it works flawlessly if you just use LANG=de to test the German menus, but
> running it a bit longer causes segfaults which are definitely caused by
> b
On 30 Oct, Marc Lehmann wrote:
> 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).
Of course
> I´m not sure LANG=de works extraordinarily good for me... no extra
> > menus or other problems anymore, so I think we should only disab
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 d
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
On Fri, 29 Oct 1999 [EMAIL PROTECTED] wrote:
> I could continue this list... In this sector a lot work has to be
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.
Already plug-ins are a pain
On 22 Oct, Sven Neumann wrote:
> I don't think that internationalisation is our major problem with
> plug-ins right now. This doesn't mean that we shouldn't think about
> it now, but our main problem is the mass of plug-ins shipped with the
> Gimp.
It is and there a quite a couple of reasons wh
On Tue, Oct 19, 1999 at 09:55:57AM -0400, "Shawn P. Wallace" <[EMAIL PROTECTED]> wrote:
> >
> > Of course, a simple gimptool wrapper plus some archiving database (the
> > registry!) might suffice.
> >
>
> It doesn't seem as if Gimp development has the critical mass (read:
> sheer number of modu
> 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, ...)
>
Sven Neumann <[EMAIL PROTECTED]> writes:
> Hi,
>
>
> my EUR 0.02 to the plug-in discussion
>
> [stuff deleted]
>
> (3) Let's test all those plug-ins heavily and drop everything that is not
> stable or usable into gimp-plugins-unstable. Do the same thing with what is
> called gimp-plugins
Hi,
my EUR 0.02 to the plug-in discussion
I don't think that internationalisation is our major problem with plug-ins
right now. This doesn't mean that we shouldn't think about it now, but our
main problem is the mass of plug-ins shipped with the Gimp.
The Filters menu is IMHO overcrowded
Why not add this capability to gimptool? Each plug-in could have its own
PlugInName.mo file bundled with it, which gimptool would grab and install
in the proper /usr/local/share/locale/ subdirectories.
--Shawn
On Thu, 21 Oct 1999 [EMAIL PROTECTED] wrote:
>
> Hm, we would have to hack a scrip
On 19 Oct, Marc Lehmann wrote:
> I don't understand - how does the current situation (different dirs
> for plug-in and gimp i18n) differ from having the plug-ins in a
> different cvs tree? Wether we create a tarball from one or from two
> cvs trees is just a matter of some script-hacking, but it
On 17 Oct, Marc Lehmann wrote:
> Just as we do now.. no changes are necessary.
> Just that we change how the plug-ins are stored (cvs) does not
> necessarily change the way they are distributed.
> And a few extra messages in gimp-std-plug-ins for plug-ins we do not
> ship because they are uns
>
> Of course, a simple gimptool wrapper plus some archiving database (the
> registry!) might suffice.
>
It doesn't seem as if Gimp development has the critical mass (read:
sheer number of module developers) that Perl has. I think an
expansion/tweaking of the registry would suffice for now, but
On Tue, 19 Oct 1999 02:29:52 +0200, Marc Lehmann <[EMAIL PROTECTED]> said:
>>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
>I volunteer, if I am allowed to use perl ;)
I have no problem with using perl. People who d
On Tue, Oct 19, 1999 at 02:29:52AM +0200, Marc Lehmann <[EMAIL PROTECTED]> wrote:
>
> BnP comes to mind, which was created to do this.. there are already BnP
> scripts that download all of gimp (including any third party libraries),
> build and install it...
Of course, a simple gimptool wrapper
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.
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
> > > 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-plu
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
On Sun, Oct 17, 1999 at 01:35:17PM +0200, David Monniaux <[EMAIL PROTECTED]> wrote:
> > 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?
On Sat, 16 Oct 1999, Marc Lehmann wrote:
> I remember some thoughts about a seperate plug-in cvs server where
> most or all plug-ins reside. plug-in authors would easily get access.
> plug-ins that don't compile or don't survive beta tests just wouldn't be
> distributed (or the plug-in cvs would
On Sat, Oct 16, 1999 at 02:21:29AM -0500, Kelly Lynn Martin
<[EMAIL PROTECTED]> wrote:
> >Hi everyone, can anyone add Kevin Turner's plugins Adaptive Contrast
> >Enhancement and AntiAlias and also the kaleidoscope plugin to GIMP
> >cvs.
>
> NO! There are already too many plugins in the main CVS
On Thu, 14 Oct 1999 01:23:47 -0700, [EMAIL PROTECTED] said:
>Hi everyone, can anyone add Kevin Turner's plugins Adaptive Contrast
>Enhancement and AntiAlias and also the kaleidoscope plugin to GIMP
>cvs.
NO! There are already too many plugins in the main CVS package as it
is. Adding more is ju
77 matches
Mail list logo
