Plugins at Sourceforge

2000-02-05 Thread Garry R. Osgood

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
comments/suggestions...)

Maybe there ought to be a line in PLUGIN_MAINTAINERS indicating
where "authoritative source" resides?

Be good, be well

Garry Osgood



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



Plugins at Sourceforge

2000-01-28 Thread Garry R. Osgood

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
comments/suggestions...)

Maybe there ought to be a line in PLUGIN_MAINTAINERS indicating
where "authoritative source" resides?

Be good, be well

Garry Osgood




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