Re: [Gimp-developer] Bug week like thing for GIMP?

2001-11-25 Thread Branko Collin

On 24 Oct 2001, at 22:18, Sven Neumann wrote:
 Rebecca J. Walter [EMAIL PROTECTED] writes:
 
   *) I am not necessarily advocating that we do a bug week -- as the
   Mozilla press review points out, a large number of people who
   would normally not thought of themselves as 'developer material'
   apparently can be involved with the Mozilla bug week because the
   UI of the browser is coded in relatively 'easy' languages such as
   XML and JavaScript.
  
  Something more like the Evolution bug days would be better for GIMP
  I think.  But I think it would be better to wait until 1.3 is
  useable. Then perhaps we should do some bug day like things to get
  it ready for release as 1.4
 
 could you explain us what the Evolution bug days are?
 
 As you said, that kind of bug-hunting doesn't make much sense in the
 development branch at the moment, but then there's still the stable
 branch and a few people are having a hard time trying to adminstrate
 the bug-reports for that. We want to get 1.2.3 out pretty soon now and
 I think we can need any helping hands. So, if you are eager to do Gimp
 bug days (or whatever you want to call it), there's a lot to do for
 you.

Let me repeat that I was not talking about bugs (and their 
destruction), but about community involvment. Mozilla translates 
community involvement to for instance Bug Week, but it could of 
course be anything. People had high expectations of The New Netscape 
years and years ago, and if all that is between these people and a 
release 1.0 are bugs, then a bug week makes sense. It may help people 
feel they're involved with Mozilla again. 

However, GIMP is not Mozilla and I was not trying to copy Bug Week 
from Mozilla, but rather was trying to see if more community 
involvement would be good for the GIMP (I think it may be) and how 
such community involvement could be given shape.

From what I understand, talk along these or other lines has taken 
place on the IRC channel #gimp and Rebecca and Carol have come up 
with the idea of letting users create a GIMP tarot card set. Perhaps 
they could talk some more about that idea. 

Are there any other such ideas that have been floating around?

-- 
branko collin
[EMAIL PROTECTED]
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer



[Gimp-developer] Re: Bug week like thing for GIMP?

2001-11-25 Thread Guillermo S. Romero / Familia Romero

[EMAIL PROTECTED] (2001-11-25 at 1551.38 +0100):
 Are there any other such ideas that have been floating around?

Intro (or task oriented) tutorials maybe, instead of the typical web
page you create an publish, waiting feedback. IOW do a live class so
people can ask questions, and then the final web page covers problems
users had when trying the planed steps.

GSR
 
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer



[Gimp-developer] Re: Bug week like thing for GIMP?

2001-11-25 Thread Carol Spears

Branko, you trouble-maker ...

[EMAIL PROTECTED] (2001-11-25 at 1551.38 +0100):

/me edits out the innocent ...

 
 Let me repeat that I was not talking about bugs (and their 
 destruction), but about community involvment. Mozilla translates 
 community involvement to for instance Bug Week, but it could of 
 course be anything. People had high expectations of The New Netscape 
 years and years ago, and if all that is between these people and a 
 release 1.0 are bugs, then a bug week makes sense. It may help people 
 feel they're involved with Mozilla again. 
 
 However, GIMP is not Mozilla and I was not trying to copy Bug Week 
 from Mozilla, but rather was trying to see if more community 
 involvement would be good for the GIMP (I think it may be) and how 
 such community involvement could be given shape.
 
What about a Wilberean Fest?

 From what I understand, talk along these or other lines has taken 
 place on the IRC channel #gimp and Rebecca and Carol have come up 
 with the idea of letting users create a GIMP tarot card set. Perhaps 
 they could talk some more about that idea. 
 
If we were to have a Wilberean Fest, I would like to spend about one
solid hour of this time pummeling Branko about the head and shoulders.

That being said, I will put together the very little we have done with
this and send it through on and email entitled The Wilberean Deck so
those who are not interested will know to avoid it.

Personally, I don't have much time to consult the tarot, (I don't check
the stock market either) but i cannot help but love the imagery.  There 
is only one gpl'ed tarot deck that I know of, it would be nice to have a 
second one and Wilber just might be dynamic enough to fill a 72 card 
deck with images and symbols.

 Are there any other such ideas that have been floating around?
 
There is enough talent in the dusty halls of GIMP development for a
brass band ...


 -- 
 branko collin
 [EMAIL PROTECTED]

carol

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer



[Gimp-developer] (Fwd) Bug week like thing for GIMP?

2001-11-25 Thread Branko Collin


--- Forwarded message follows ---
Date sent:  Sun, 25 Nov 2001 13:27:08 -0500
From:   Ed Halley [EMAIL PROTECTED]
To: Branko Collin [EMAIL PROTECTED]
Subject:Re: [Gimp-developer] Bug week like thing for GIMP?

On Sun, 25 Nov 2001 15:51:38 +0100, Branko Collin 
[EMAIL PROTECTED]
wrote: 

 Let me repeat that I was not talking about bugs (and their 
 destruction), but about community involvment. 
 
 Are there any other such ideas that have been floating around?

 (It appears that the mailing list server isn't accepting my
 emails to the group.  Not sure why.  If this is the appropriate
 kind of idea list, please forward to the developer list.)

I will give my input on community involvement and the GIMP project,
but first I want to give the disclaimer.  These are my opinions, and 
I
don't expect everyone to agree or align with my opinions.  I speak
candidly, not out of disrespect for those people who I criticize, but
out of the utmost respect that says I must speak candidly so that the
project can grow and improve.  Thanks.

1.  For community involvement, the main GIMP website really must be
brought
up to date.  Most of the GIMP script links are stale or broken. 
Any whiff of dead project will turn off many people who would
otherwise get involved and help GIMP grow.

2.  A much bigger gallery of GIMP work should be on the website,
hopefully
with brief notes on each work that explain how various effects
were achieved.  Showing how complex compositions are structured 
in
layers, or how various source materials were filtered and 
combined
is a big part of how to get going with a complex tool like the
GIMP.  Call for artists to submit their own image projects,
they'll love to get the exposure.

3.  A page on the GIMP site should be dedicated to the topic of How
to
transition from Photoshop to the GIMP successfully.  The
community would be a lot larger if more people realized that 'you
get what you pay for' is a false statement; get professional
artists interested in GIMP and the development potential would
skyrocket.  Once professionals depend on GIMP, then we may even
see some corporate funding for making GIMP do all the things that
need to be done:  CMYK, serious halftoning, and easy font work
come to mind, but that's just the tip of the iceberg.

4.  In that same vein, establish and *support* a Users' Questions
page.
Ideally, there should be a link to it in the GIMP help menu
itself. Users who don't know how to get certain effects or who are
getting problems with scripted effects.  Some of this turns into a
FAQ and some turns into various HOW-TO documents as they become
established.  The whole web development area can be done by people
who are not developing the central GIMP code.

This is just my opinion, but from what I've seen, many GNOME
developers unfortunately don't seem to value users and their problems,
basically stating if you can't code it, why should we?  As a new
developer who is very experienced in other systems, but not
experienced in GNOME or GIMP structures, I found it very hard going to
get into the GIMP hacking scene. One reason was the difficult
compile environment (especially since GIMP relies so much on recent
revisions of GNOME libraries that are not yet in mainstream Linux
distros like Red Hat).  Another reason was the sink or swim attitude
that some developers showed in the IRC channel.  I can grok not being
accepted with open arms; not everyone goes there to support new
developers.  This goes far beyond being ignored; people have even been
scolded and told that 'criticizing GIMP is inappropriate' in that
channel! Getting *some* people interested in helping out some new
developers (with architectural and documentation and at least) will be
very important to the continued growth of the project.

The intersecting group which is both developer and artistic is very
small; the group who would *like* GIMP to succeed is much much larger
and could ultimately be the union of all OSS developers and all
OSS-supporting artists.  Shunning artists' input is not how to make a
strong and diverse community, and ignoring the experience of artists
with other tools like Photoshop is not going to make a strong and
intuitive user interface for newcomers to discover and enjoy.

Lastly, the mentality of we don't care if you use it, we develop GIMP
for us is the keystone of exclusivity and elitism, and I have
definitely run into that with GIMP moreso than with many other OSS
projects.  If you don't care about new users, how can you possibly
care about the project at all? Making a tool useful for a few people
is interesting, but making a tool that is useful for the widest
possible userbase is far more rewarding.  The days of GIMP being
useful for its developers alone are over.  Like it or not, the GIMP is
in the position of being in a monopoly 

[Gimp-developer] memory leak?

2001-11-25 Thread Kelly Martin

Maybe I'm just losing it, but it looks very much to me like
gimp_image_construct_layers in app/core/gimpimage.c leaks the
reverse_list.  

-- 
 I love catnip mice.
   It's why I chew their heads off.
 They're good for breakfast.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer



[Gimp-developer] CVS compile problems in: plug-ins/perl, ec

2001-11-25 Thread David Ford

First, this plug-ins/perl dir seems to be overflowing with niglets.

cvs checkout
CFLAGS=... CPPFLAGS=... autogen.sh --with-mp=yes --enable-perl 
[--disable-nls]

Next I try a few things.

'make maintainer-clean' || 'make distclean' || 'make clean'  (all 
results similar; follows)
...
Making maintainer-clean in perl
make[2]: Entering directory `/usr/local/src/cvs/gimp/plug-ins/perl'
make[2]: *** No rule to make target `maintainer-clean'.  Stop.

(fresh checkout and run autogen with/without --disable-nls)

$ make
Making all in plug-ins/perl/po
make[2]: Entering directory `/usr/local/src/cvs/gimp/plug-ins/perl/po'
make[2]: *** No rule to make target `all'.  Stop.

$ cd plug-ins/perl/po
$ perl Makefile.PL
Portable message objects... skipped
Writing Makefile for i18n
$ cd -
$ make
Making all in plug-ins/perl/po
make[2]: Entering directory `/usr/local/src/cvs/gimp/plug-ins/perl/po'
make[2]: Leaving directory `/usr/local/src/cvs/gimp/plug-ins/perl/po'
...

Making all in perl
make[3]: Entering directory `/usr/local/src/cvs/gimp/plug-ins/perl'
make[3]: *** No rule to make target `all'.  Stop.

$ cd plug-ins/perl
$ perl Makefile.PL
creating cache ./config.cache
checking for gimp... no
checking for gimptool... no
checking for GIMP - version = 1.0.4... no
*** The gimptool script installed by GIMP could not be found
*** If GIMP was installed in PREFIX, make sure PREFIX/bin is in
*** your path, or set the GIMPTOOL environment variable to the
*** full path to gimptool.
configure: warning: ** unable to find gimp
./configure: no: command not found
./configure: no: command not found
./configure: test: -lt: unary operator expected
checking for glib-config... /usr/local/bin/glib-config
checking for GLIB - version = 1.2.0... no
*** Could not run GLIB test program, checking why...
*** The test program failed to compile or link. See the file config.log 
for the
*** exact error that occured. This usually means GLIB was incorrectly 
installed
*** or that you have moved GLIB since it was installed. In the latter 
case, you
*** may want to edit the glib-config script: /usr/local/bin/glib-config
configure: error: ** unable to find glib

Correct me if I'm wrong, but why is glib-1.2 being requested when 
everything else is based on 2.0?  Further, why is this trying to use a 
pre-existing installation of gimp?  I don't have an install of gimp on 
this machine so I surely won't have either gimp .h files nor gimptool.

After compiling and installing glib-1.2:

$ perl Makefile.PL
loading cache ./config.cache
checking for gimp... no
checking for gimptool... (cached) no
checking for GIMP - version = 1.0.4... no
*** The gimptool script installed by GIMP could not be found
*** If GIMP was installed in PREFIX, make sure PREFIX/bin is in
*** your path, or set the GIMPTOOL environment variable to the
*** full path to gimptool.
configure: warning: ** unable to find gimp
./configure: no: command not found
./configure: no: command not found
./configure: test: -lt: unary operator expected
checking for glib-config... (cached) /usr/local/bin/glib-config
checking for GLIB - version = 1.2.0... yes
checking how to run the C preprocessor... (cached) gcc -E
checking for libgimp/gimpmodule.h... (cached) no
checking for libintl.h... (cached) yes
checking for unistd.h... (cached) yes
checking for vsnprintf... (cached) yes
checking for intelligent life... not found
checking for _exit... (cached) yes
creating ./config.status
creating config.pl
creating config.h
config.h is unchanged
now invoking perl to complete the configuration...
+ exec /usr/local/bin/perl Makefile.PL --writemakefile PREFIX=/usr

FATAL: unable to deduce plugindir from gimptool script

So..I copy and symlink the as-yet-uninstalled gimptool-1.3, rm 
config.cache, and run perl Makefile.PL again.

It successfully builds the Makefile now but it still doesn't have the 
expected pre-installed header files.

So I start off on a journey of flag waving..

$ LDFLAGS=-L../../libgimp/.libs/ -L../../libgimpwidgets/.libs 
-L../../libgimpcolor/.libs/ -L../../libgimpmath/.libs/ 
-L../../libgimpbase/.libs/ CFLAGS=$CFLAGS -I../.. -I(insert cflags for 
glib) perl Makefile.PL

(replaced with /usr/src/cvs/gimp for autogen.sh)

Now we're getting nowhere again.

David


___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer