Re: plugins

2001-01-15 Thread Sven Neumann

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 a little. Does this mean that you people are working
on this ??


Salut, Sven




Re: Plugins - what they can and cannot do.

2000-08-31 Thread pixel fairy

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 is why i never bothered to
make this plug in)

so what we really need is something for alternate forms of displaying the
image, such as offset or hieghtfield (already working on that one, now
that i fixed the silly clipping problem but polling and having an update
button is how im doing it) or mapped to abritrary shapes...

at the least a way for a plug in to know when an image changes...

On Fri, 1 Sep 2000, david rohde wrote:

 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, then allow the user to
 draw on this and then read back from the canvas. (and possibly destroy
 it).
 
 Non editible sections of the image could be protected by being put in a seperate 
layer.  The user
 could change layers by using a menu on the plugin.
 
 My main concern is that there is no way (as far as I know) to prevent the user using 
the layer menu,
 to bypass all of this.
 
 Is what I am saying making sense?
 Has anyone else encountered this problem?
 Thanks
 David
 




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: Plugins at Sourceforge

2000-02-05 Thread Glyph Lefkowitz


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 a logical pause in
 development, such as the release of GIMP 1.2, to begin making these
 not-insubstantial changes in source management.

Hear hear.  Let's get Gimp 1.2 out the door please, before we start
mucking with everything's structure?  Keep in mind there are lots of users
waiting for a `stable' 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 the product will speak for itself.
- Hajime Karatsu



Re: Plugins at Sourceforge

2000-02-05 Thread Robert L Krawitz

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

Furthermore, look at it from the standpoint of someone trying to
package a Linux distribution (especially vis a vis esoteric file
formats and other things that depend upon external software).  If our
jpeg plugin is part of the core (as an example, I don't want to debate
jpeg per se), then installing the gimp requires installing jpeg.  If
we start forcing 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 close to the release, as many people have pointed out, to
change something fundamental even if it means an improvement.  It
seems to me that right now everyone except people working on advanced
development should focus on the release.

(And yes, however good Print 3.1 becomes, and even if 3.2 is ready
before Gimp 1.2 is, Gimp 1.2 will contain Print 3.0.  At some point
down the road we might want to put Print 3.2 into a Gimp 1.2 refresh
or point release, but that's another matter.)

-- 
Robert Krawitz [EMAIL PROTECTED]  http://www.tiac.net/users/rlk/

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail [EMAIL PROTECTED]
Project lead for The Gimp Print --  http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton



Re: Plugins at Sourceforge

2000-02-05 Thread Dean Johnson

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?  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 totally agree! Ideally Gimp should have a connection to some plug-in
registry so that needed esoteric (or not so esoteric) plug-ins could
be downloaded and installed without restarting gimp. Have the simple
plugin's with the distro and then have a series of "power packs" that
roughly align with usage domains (i.e. "import powerpack","export powerpack",
fine art powerpack", "prepress powerpack", etc).

-Dean Johnson
 Tool Hooligan
 Cluster Admin Tools  Jessie Project
 Silicon Graphics Inc.Eagan,MN  (651) 683-5880

 
  "I am Dyslexic of Borg, Your Ass will be Laminated"-- unknown
 



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: Plugins at Sourceforge

2000-02-01 Thread Daniel . Egger

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 problems but
 while I coding some source I stumbled over a problem with gettext which
 took me nearly a whole to identify.
 I would really like someone to give me a helping hand on this to reduce 
 the time and of course I would need someone to wake up Ulrich
 Drepper because I really need his answer :)) 

-- 

Servus,
   Daniel



Re: Plugins at Sourceforge

2000-01-31 Thread Daniel . Egger

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 menues 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,
   Daniel



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: Plugins at Sourceforge

2000-01-29 Thread Marc Lehmann

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

Whatever, we need a good tool to install other plug-ins later, both
for the admin and the single-user case (like CPAN), since the "most
interesting plug-ins" (for some user) will not be delivered with the gimp
anyway.

This will be done, no doubt, after 1.2, and the better it works, the less
plug-ins do we have to deliver with the core distribution. We just have
to train distribution people to deliver the full plug-ins archive on
their cd's (yes, some people still have no internet!), and maybe we could
provide a working binary kit.

After reading that article about innovative free software and
non-innovative gui design, I begin to think that gimp is more prone to be
end-user software than, say, gcc ;)

(OTOH, I think the gimp GUI is quite innovative: being innovative in GUI
design usually lowers the usability index a lot).

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: Plugins at Sourceforge

2000-01-29 Thread Michael J. Hammel

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 it for a multi-user system if many of your users are
using it on a single user box.  It's a reasonable argument, but there isn't
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 otherwise.

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

There are some menus that need adjusting to reduce the number of entries.
One thing I noticed today is that there are still menus that don't fit well
on my 800x600 laptop.  Configurable menus is probably the only good long
term solution to this sort of problem, however.

Similarly, the Palette options for the Indexed Color Conversion dialog
doesn't fit in an 800x600 display using the default fonts.  There are so
many palettes provided in the distribution that a scrolled list is now a
better display option here.
-- 
Michael J. Hammel   |
The Graphics Muse   |  Women should put pictures of missing husbands 
[EMAIL PROTECTED]  |  on beer cans.
http://www.graphics-muse.com 



Re: Plugins at Sourceforge

2000-01-29 Thread Andrew Kieschnick


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, you could also say there is not much
 sense in tailoring it for a multi-user system if many of your users are
 using it on a single user box.  It's a reasonable argument, but there isn't
 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 otherwise.

Why yes, admins (like me) generally don't like things that are packaged
for single users. I suppose I don't care much about whatever packaging
changes are made, as long as I can still install the gimp (and plug-ins, 
and data, and whatever else) in some system-wide location, and as long as
users can still put extra bits and pieces in their .gimp directory. 

Being an admin lets me see a variety of interesting things, such as the
guy who ran gimp for the first time, and chose [Ignore] in the gimp
installation dialog, and then told me that gimp didn't work right. Why is
ignore an option? It doesn't seem to provide anything other than a quick
way to make the gimp not work; unless it has some sort of use, it should
probably be taken out.


later,
Andrew Kieschnick

















Re: Plugins at Sourceforge

2000-01-29 Thread Marc Lehmann

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 outside the screen.
So if the menu is too full, it still should be shown someway (e.g. using
wrapping like motif, just a bit better maybe).

But that's a gtk+ issue, and I use gtk+-1.2, so maybe that problem is nil
already.

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: Plugins at Sourceforge

2000-01-28 Thread 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
development, such as the release of GIMP 1.2, to begin making these
not-insubstantial changes in source management.

Zach
-- 
Zachary Beane   [EMAIL PROTECTED]
PGP mail welcome.   http://www.xach.com/pgpkey.txt



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: Plugins at Sourceforge

2000-01-28 Thread Glyph Lefkowitz


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 a logical pause in
 development, such as the release of GIMP 1.2, to begin making these
 not-insubstantial changes in source management.

Hear hear.  Let's get Gimp 1.2 out the door please, before we start
mucking with everything's structure?  Keep in mind there are lots of users
waiting for a `stable' 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 the product will speak for itself.
- Hajime Karatsu




Re: Plugins at Sourceforge

2000-01-28 Thread Marc Lehmann

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 "distribute it"
and "leave it out" very easy.

I imagine that, before some future release, we can just edit a simple
configuration file that specifies which plug-ins are part of the
distribution and which aren't.

That way removing a plug-in from gimp-2.0 would be a matter of commenting
out a line somewhere.

 necessarily be included with the core package.  Throwing in the kitchen
 sink is what's starting to bloat some Linux distros.

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.

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.

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: Plugins at Sourceforge

2000-01-28 Thread Marc Lehmann

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... we are _about_ to do something, yes.. ;)

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



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: 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 Marc Lehmann

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 system, so
there is not much sense in tailoring the number of installed plug-ins to the
needs of, say, the admin.

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

 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 the plug-ins run in a different process-space from the gimp, but
the gimp needs to know translations, and gettetx does not support complex
applications like these.

 GTK supports internationalization, right?

Looking at the current state of gimp, I'd say GTK does not really
_support_ i18n :(

 Anyway, I could be way off here.

No, you aren't ;) What you said is what _should_ be the case, however,
existing packages like gtk+ and gettext do not support the gimp model of
distributed programs with shared menus.

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: Plugins at Sourceforge (fwd)

2000-01-28 Thread Michael J. Hammel

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
 development, such as the release of GIMP 1.2, to begin making these
 not-insubstantial changes in source management.

Make that two cries.  Ditto the reasoning.
-- 
Michael J. Hammel   The Graphics Muse 
[EMAIL PROTECTED]  http://www.graphics-muse.com
--
   Try again.  Fail again.  Fail better.  --  Thomas Beckett



Re: Plugins at Sourceforge

2000-01-28 Thread Michael J. Hammel

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 plug-ins
 currently in the distribution.

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.

Just a thought.
-- 
Michael J. Hammel   The Graphics Muse 
[EMAIL PROTECTED]  http://www.graphics-muse.com
--
   Try again.  Fail again.  Fail better.  --  Thomas Beckett



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: Plugins at Sourceforge

2000-01-28 Thread Robert L Krawitz

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

   Agreed, with a modification:  a review of plug-ins should be done so that a
   set of very useful ones could be left with the core.  This would permit a
   useful, small distribution for *nix distributors to include without having
   to concern themselves about the added extras on sourceforge.  It would also
   allow the core developers to concentrate on architectural issues and let
   another group of plug-in developers grow (over time) to handle the extras.

I agree.  I think that the right question is whether a typical end
user would consider something to be core functionality vs. an addon.
It doesn't really matter how it's implemented; if an end user expects
it as a fundamental part of the application, it's core functionality.

That doesn't mean that the development of the core plugins has to be
centralized; in our case (presuming that printing is considered core
functionality) I don't see any harm in our working on our development
series, and releasing stable code to the Gimp core.  That's
essentially what we're doing right now; I intend 3.0.5 as the version
to get into 1.2, unless we have bugs that are deemed high enough
priority, but 3.1 is under active development.

The more interesting question from our standpoint is what happens when
Gimp 1.3 gets underway.  My intent is to release versions off the 3.1
development tree (or whatever the latest version that at least passes
the paper bag test) into the Gimp development, and then sync up our
latest stable release when Gimp 1.4 or 2.0 gets close to release.  And
yes, I agree with Michael also that 2002 is not a reasonable target
for the next stable release of the Gimp.

-- 
Robert Krawitz [EMAIL PROTECTED]  http://www.tiac.net/users/rlk/

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail [EMAIL PROTECTED]

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton



Re: Plugins

1999-11-13 Thread Marc Lehmann

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 share a pipe, so there should be a way to set a new
context.  Otherwise the problem I want this context stuff for is still not
solved, namely multiple clients connecting to the gimp.

And how does the application change between setting it's own context vs.
setting the gui context? I cannot see how this can be done without an
explicit PDB interface for this.

 But as I said, I'm not 100% sure if this asumptions are true... are they?

most plug-ins do not share a pipe. but many plug-ins (and most script-fu
scripts) would need a way to set either context.

 ...also true, but I'm not yet sure (see above) how to do it and if it can
 be done without breaking too much...  you're more a plug-in expert than
 I am, any idea where to do this context switching??

In the core, we have to find out _who_ is calling an internal pdb function
(or an external plug-in), and use the appropriate context during the
execution.

Every plug-in should get a copy-on-write-like context, and the option
to modify the parent context (or the gui context, but the latter is not
important at this point, as it is clearly a new feature).

You also need a way to copy/set the context, for clients sharing a pipe.

The default for 1.2 could be to modify the parent context anyway (but
I think that only a small minority of scripts require changes to
colours/brushes etc. to be backpropagated, so these could probably be
fixed)

 Yep, this sounds better ;-) But do we really need pdb context functions
 for 1.2 if internal context switching (depending on the plug-ins' file
 descriptors) is possible?

No (if!). But even if not we could not just decide not to fix the
(non-fatal for normal usage) bug.

It is still easy to confuse the gimp by calling normal plug-ins, even with
the context stuff.

 Maybe just a stripped down context interface (allowing e.g.
 the client to say if it wants a private context or not)

How about always having a provate context? Which plug-ins require that
their changes to the context are global? Most only set colours etc. for
their internal use, and backpropagating thes evalues is usually NOT
wanted, but unavoidable.

 uh, I guess this mail has too much "if"s...

If we could get some pdb functionality, we could even fix the big
annoyancies for script-users. And little annoyances for ui-users (ui users
are already aware that hell breaks loose when they try to call more than
one plug-in at a time).

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: Plugins

1999-11-11 Thread Daniel . Egger

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 to an address 
 not owned by the process... In C this is very easily because we sometimes 
 even calculate with pointers...

 Well, if you care that I won´t repeat the same error again it would be
 nice if you explained the bug...

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

  I don't think so. Half-translations can be really confusing and
  annoying for a user.

 Ok, then let's vote on this. "I vote that this is less confusing..."

 Do so, but at a public place, please...

  Push me, please... 

 PUSH!

 Not hard enough, but this may change VERY soon

 "ls" is ls(1) and "vz" is the shortcut for "verzeichnis".

 Ouch

  mixed language environments are the rule today, not the exception.

  That doesn't make them any better
 
 I think it's the only way to go. Look at how M$ handles translation
 (by looking at i18n'ed visual basic for example ;)

 ROTFL. Did you have a look how M$ does internationalisation?
 Have you ever seen a catalog for any Microsoft program? 
 No? Maybe it's their special art of doing Cut'n'Paste... :))

 Well, I have an opinion about half-trabslation that is just as good as
 any opinion from an average user. The gimp is not the only i18n'ed
 project, and I didn't speak english all the time in the past...

 Well, for distributors internationalisation is a very big concern
 because they address firms (which don't care about it very much) on
 the one hand but on the other hand also users who want a stable
 OS with many free programs and they DO care about. 

-- 

Servus,
   Daniel



Re: Plugins

1999-11-11 Thread Daniel . Egger

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 I guess I'll have to sleep until
 the release of Gimp 1.2 ... In this area we have too much changes to allow
 me to start coding now for Gimp 1.3...

 A way around would be to increase the version number to something
 like 1.1.95 to show that we are on the right way and get a big bug
 fixing push :))

-- 

Servus,
   Daniel



Re: Plugins

1999-11-11 Thread Marc Lehmann

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.

  Ok, then let's vote on this. "I vote that this is less confusing..."
  Do so, but at a public place, please...

I just did this, didn't I??

  because they address firms (which don't care about it very much) on
  the one hand but on the other hand also users who want a stable
  OS with many free programs and they DO care about. 

But this is still no argument on why everything must be translated...

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: Plugins

1999-11-09 Thread Uwe Koloska

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
english and are satisfied (so I am searching for ways to make my system
better).

I think of it pragmatically:  If there are no two (or more) menus with the same
name (but in different languages) it is not really bad.  It is not nice though!
Think of it as a little gift just around the corner:  "The whole gimp is in
english.  I understand it but I would prefer german.  Oh, here in File are all
entries translated -- very good."

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 right thing todo
after 1.2!

Just my 0.2 Euro
Uwe Koloska

-- 
mailto:[EMAIL PROTECTED]
http://rcswww.urz.tu-dresden.de/~koloska/
----
right now the web page is in german only
but this will change as time goes by ;-)



Re: Plugins

1999-11-09 Thread Michael Natterer

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 because playing around with the PDB interface in
  freeze mode looks dangerous to me...
 
 I'm sorry... do you really say that you won't implement the context stuff
 fully for 1.2?
 
 I had always thought that the work would be finished before 1.2

I'm not really sure what you mean. The internal stuff is now done only
by the context and finished. There are still some (uncritical) things to
be done, but that's bugfixing.

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 clients run in their
own context (which could be done internally without changing the interface)

I considered bringing the context to the pdb as a feature for 1.4 (also
because I was away from my machine for months when the gimp was frozen :( )

  So please let me know if you find the semantics of any PDB
  brush/color/pattern/gradient function changed and I'll restore the old
  semantics.
 
 I don't expect them to be changed yet. I would have appreciated this
 very much, this would probably result in much less work on my side (no
 backward-compatibility crap).
 
 If you are about to break the pdb interface we should do it now, not
 later.  Doing it later is just awkward, resulting in more work from many
 others (update it to 1.2, and then to 1.3 again. Doing the major work once
 would be much better).

Currently I don't plan to break the pdb interface because now the whole
stuff is in a sane state. It would be a major api change that will need
lots of debugging and I'm not sure if there's enough time until the new
release in god-knows-how-many-months ;-)

However, putting additional stuff to the context (like the error message
as you proposed) wouldn't be too much work.

Please let me know what your plans are.

bye,
--Mitch



Re: Plugins

1999-11-09 Thread Marc Lehmann

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 right thing todo
 after 1.2!

The problem is not fixable by mere developer effort. It also has to work
(somewhat) with plug-ins "we" have no control over.

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.

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: Plugins

1999-11-08 Thread Marc Lehmann

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 system but I think there
 are many systems out there with similar problems.

Strange that I don't encounter this problem (that sever), maybe the version
we used for the booth at the Systems '99 had a much better german
translation?

In any case, this problem is a totally seperate issue (as I talked about with
Daniel). A solution (workaround, fix...) would be to do it like perl, i.e.
translate by component unless there is a better translation. E.g.

Toolbox/Xtns/Animation/Seth Spin
= Toolbox/Xtn/Animation/Seth's Dreher
(translation available)

Toolbox/File/Selection/Add Selection
= Toolbox/Datei/Auswahl/Add Selection
(only a partila translation for File/Selection available)

This would solve your problem for the vast majority of untranslated (E.g.
third-party) plug-ins.

 Well, what I understand about half-translated plug-ins is, that if the binding
 for the inclusion in menus and so on is fully translated and the rest isn't
 that isn't bad, but if some menu entries are and others not is very bad.

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")?

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: Plugins

1999-11-08 Thread Marc Lehmann

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

  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.

But since its purely for my own pleasure you don't have to explain... (I
am serious, btw!)

  Me included! Maybe I shouldn´t even reply here.. ;-
 
  Maybe :)

Well, if you care that I won´t repeat the same error again it would be
nice if you explained the bug...

  I don't think so. Half-translations can be really confusing and
  annoying for a user.

Ok, then let's vote on this. "I vote that this is less confusing..."

  Maybe we should just push the translators a bit for the release
  (unless code changes are necessary)..
 
  Push me, please... 

PUSH!

  Half-translated plug-ins are definitely no reason to forget it!! I
  mean, do you want to translate "ls" to "vz" with LANG=de?
 
  I don't understand your intention here... what should "ls" and "vz" be?

"ls" is ls(1) and "vz" is the shortcut for "verzeichnis".

  mixed language environments are the rule today, not the exception.
 
  That doesn't make them any better

I think it's the only way to go. Look at how M$ handles translation (by
looking at i18n'ed visual basic for example ;)

  I don`t mind it either..
  I know, but you aren't supposed to be the average user, are you?

Well, I have an opinion about half-trabslation that is just as good as any
opinion from an average user. The gimp is not the only i18n'ed project, and I
didn't speak english all the time in the past...

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: Plugins

1999-11-08 Thread Marc Lehmann

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 interface in
 freeze mode looks dangerous to me...

I'm sorry... do you really say that you won't implement the context stuff
fully for 1.2?

I had always thought that the work would be finished before 1.2

 So please let me know if you find the semantics of any PDB
 brush/color/pattern/gradient function changed and I'll restore the old
 semantics.

I don't expect them to be changed yet. I would have appreciated this
very much, this would probably result in much less work on my side (no
backward-compatibility crap).

If you are about to break the pdb interface we should do it now, not
later.  Doing it later is just awkward, resulting in more work from many
others (update it to 1.2, and then to 1.3 again. Doing the major work once
would be much better).

  BTW: I appreciated both new features a lot!
 
 :-)

But AFAICS, there is only one new feature...

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: Plugins

1999-11-07 Thread Daniel . Egger

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 is surely better than not translated at all, so
 this is IMHO no reason to switch it of totally.

 I don't think so. Half-translations can be really confusing and
 annoying for a user.

 Maybe we should just push the translators a bit for the release
 (unless code changes are necessary)..

 Push me, please... 

 Half-translated plug-ins are definitely no reason to forget it!! I
 mean, do you want to translate "ls" to "vz" with LANG=de?

 I don't understand your intention here... what should "ls" and "vz" be?

 mixed language environments are the rule today, not the exception.

 That doesn't make them any better

 I don`t mind it either..

 I know, but you aren't supposed to be the average user, are you?

-- 

Servus,
   Daniel



Re: Plugins

1999-11-07 Thread Daniel . Egger

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 function to be
 called from outside. IMHO waiting for context signals and
 self-updating is much cleaner and less dangerous than the old paradigm
 and making the ui always sync with the internal state _is_ a bugfix.

 Many changes can be expressed to be bugfixes, but somewhere we have to
 stop introducing new features and bugs...

-- 

Servus,
   Daniel



Re: Plugins

1999-11-03 Thread Michael Natterer

[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 pointed
out, we announced that there are checkins to come and nobody objected.

When starting to add the posibility to store brush/pattern/... in the
context, I even put the question to the ChangeLog. The actual big
checkin where I changed all brush/pattern/... access functions was
9 days later and I didn't get any mail in the meantime.

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 function to be called from outside.
IMHO waiting for context signals and self-updating is much cleaner
and less dangerous than the old paradigm and making the ui always sync
with the internal state _is_ a bugfix.

bye,
--Mitch



Re: Plugins

1999-11-03 Thread Michael Natterer

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 cuase other changes as well... So I'd really
 say: either we feature freeze or we forget 1.2

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 interface in
freeze mode looks dangerous to me...
So please let me know if you find the semantics of any PDB
brush/color/pattern/gradient function changed and I'll restore the old
semantics.

 BTW: I appreciated both new features a lot!

:-)

ciao,
--Mitch



Re: Plugins

1999-11-03 Thread Uwe Koloska

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 than not translated at all, so this is
IMHO no reason to switch it of totally.


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 system but I think there
are many systems out there with similar problems.

Well, what I understand about half-translated plug-ins is, that if the binding
for the inclusion in menus and so on is fully translated and the rest isn't
that isn't bad, but if some menu entries are and others not is very bad.

  Fix it or forget it and fixing it needs some more hours to be put

Half-translated plug-ins are definitely no reason to forget it!! I mean, do
you want to translate "ls" to "vz" with LANG=de? mixed language environments
are the rule today, not the exception.


see above.

Yours
Uwe Koloska

-- 
mailto:[EMAIL PROTECTED]
http://rcswww.urz.tu-dresden.de/~koloska/
----
right now the web page is in german only
but this will change as time goes by ;-)



Re: Plugins

1999-11-03 Thread Daniel . Egger

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 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 function to be
 called from outside. IMHO waiting for context signals and
 self-updating is much cleaner and less dangerous than the old paradigm
 and making the ui always sync with the internal state _is_ a bugfix.

 I just said that my ideas wouldn't really introduce new features but
 just be a kind of cleanup

-- 

Servus,
   Daniel



Re: Plugins

1999-11-02 Thread Daniel . Egger

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 disable
 the languages that don´t work.

 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
 bad hacks which "localize" Plug-ins... most developers unfortunately don't 
 have quite a clue of what's going on in this area

 And I can't think of something more bad than halfdone things... we even
 have Plug-ins which are half-translated... nice feature, right?

 Fix it or forget it and fixing it needs some more hours to be put
 in

 Yes ;- But these ideas were mostly aimed at 1.3, no?

 I didn't mean our discussion but the talks between my person and
 a few people who really use GIMP for earning some money and they'd
 really enjoy a great translation of GIMP into German and possibly would 
 be really grateful for some work here... hint

 Or do we plan to revamp the registry, the i18n system c before 1.2?
 no..

 I really don't know what WE want... I want a bug free GIMP for release 
 and that's definitely some days away, even more if we want to keep
 i18n for plug-ins...

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

Servus,
   Daniel



Re: Plugins

1999-10-30 Thread Marc Lehmann

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 disable i18n for plug-ins
  which on the other hand is a bad solution because localisation is a

I´m not sure LANG=de works extraordinarily good for me... no extra
menus or other problems anymore, so I think we should only disable the
languages that don´t work.

  On the GIMP booth at the Systems we have had some really nice discussions
  about this, also with firms which use GIMP for web publishing. Just

Yes ;- But these ideas were mostly aimed at 1.3, no?

Or do we plan to revamp the registry, the i18n system c before 1.2? no..

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: Plugins

1999-10-29 Thread Daniel . Egger

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

 Should we leave the plug-ins as they are know or bugfix them i18n-wise?
 I do have a proposal on my Palm which would provide an idea for the
 bugfixing way... Otherwise I would suggest du disable i18n for plug-ins
 which on the other hand is a bad solution because localisation is a
 "MUST BE" (tm) for any real work with GIMP outside English spoken
 countries 
 On the GIMP booth at the Systems we have had some really nice discussions
 about this, also with firms which use GIMP for web publishing. Just
 tell me if you want to know more about this

-- 

Servus,
   Daniel



Re: Plugins

1999-10-23 Thread Marc Lehmann

 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, ...) 
   gimp-plugins-render-fractal (fractal-explorer, cml_explorer, )
   gimp-plugins-fileformats(fits, sunras, ...)
   gimp-plugins-perl
 (you get the point)

This is just like the cpan bundle system, btw. I suggest we _really_
should look at a comparable database like cpan before starting our own
hacks.

 registry, mirror it and include a nice tool that allows users to download and 
 install plug-ins when the need arises. Of course this would have to be 
 possible from within a running gimp and since I'm not sure if this would work 
 at all, this is possibly only a solution for 2.0.

That would require re-scanning the plug-ins, which is a viable thing, but
also sounds like a new feature (i.e. a 2.0 feature).

But if we drop that restriction, i.e. by requiring a restart and using a
seperate tool (i.e. super-gimptool), the work to implement this shouldn't
be that large. For example we could copy the cpan logic of downloading and
unpacking the plug-ins portably.

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: Plugins

1999-10-21 Thread Daniel . Egger

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 unstable don't mind.

 Hearing that I hope you a great idea how to achieve that, too?
 i.e. How do you want integrate messages from a seperate plugin tree into
 the catalog template?

-- 

Servus,
   Daniel



Re: Plugins

1999-10-21 Thread Daniel . Egger

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 does not
 affect the final tarball.

 Hm, we would have to hack a script which dynamicly adds all the source
 files to gettexts path...
 But: This script has to run either on the server on a regularly base or
 all the catalog authors have to get every possible plugin and put the source
 into the right directory otherwise every try to update the .po
 files would end up in blown away translations

-- 

Servus,
   Daniel



Re: Plugins

1999-10-21 Thread Sven Neumann

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. Even a redesign can't solve the fact 
that it is really difficult to find the plug-in you need and most users will 
only need a small subset of the included plugins. On the other hand there 
quite a few nice plug-ins that are definitely worth to be included (if we go 
along with our current philosophy to include each and every plug-in that 
could come in handy). Antialias is one of those candidates just to bring up 
an example.

One strength of Gimp definitely is that it comes with a huge amount of 
filters and file-formats by default. But with the amount of plug-ins growing 
constantly, we should IMHO discuss if we can continue like that.

I have for myself included a whole bunch of plug-ins to CVS in the last 
months. This was done with the intention to have them tested by a wider 
audience. It was never my intention to definitely have them all included in 
the final 1.2 distribution.  Now, what can we do about this? There are a few 
solutions that I can imagine and I'm sure you can imagine more...

(1) Include only a few core plug-ins and package others into groups that the 
user can install at will and that will stay in one menu place as a group. 
This doesn't mean that no core plug-ins are part of the same menu, but by 
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, ...) 
gimp-plugins-render-fractal (fractal-explorer, cml_explorer, )
gimp-plugins-fileformats(fits, sunras, ...)
gimp-plugins-perl
(you get the point)
For the hardcore user create a package that contains them all.

(2) Stay with the same basic plug-ins as in (1), rewrite the plug-in 
registry, mirror it and include a nice tool that allows users to download and 
install plug-ins when the need arises. Of course this would have to be 
possible from within a running gimp and since I'm not sure if this would work 
at all, this is possibly only a solution for 2.0.

(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-unstable now and move all plugins that seem to be stable 
and usable up into the main distribution. Then start the menu discussion all 
over (we had one before 1.0 was released) and find a better way to put all 
those plug-ins into suitable menu positions.


Salut, Sven





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



Re: Plugins

1999-10-18 Thread Marc Lehmann

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 look at me to write it, though

I volunteer, if I am allowed to use perl ;)

However, this is an interesting idea indeed. all we needed would be to
ensure some rules on how to create CGAN-able (comprehensive gimp archival
network) plug-ins, i.e. plug-ins that can be installed with no (or with
little) user interaction.

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

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: Plugins

1999-10-18 Thread tomfool


   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 shipped with Gimp
 
 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 unstable don't mind.

The i18n issue isn't where the plug-ins are shipped.  The issue for
plug-ins that are not part of the gimp-std-plugins distribution is the
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 people from the programmers, can look to find
translations that need doing.  Without this, the translation effort
cannot be extended to submitted plug-ins in a general way.

-tom

---
tomss at ids.net - 401-861-2831



Re: Plugins

1999-10-18 Thread Marc Lehmann

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 people from the programmers, can look to find
 translations that need doing.  Without this, the translation effort
 cannot be extended to submitted plug-ins in a general way.

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 does not affect the final tarball.

Except that we might have a better link with the plug-in maintainers and
gimp..

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |