On 8/14/05, Carol Spears <[EMAIL PROTECTED]> wrote:
> On Sun, Aug 14, 2005 at 07:37:20PM -0400, michael chang wrote:
> > On 8/14/05, Carol Spears <[EMAIL PROTECTED]> wrote:
> > > On Sun, Aug 14, 2005 at 08:27:54AM -0400, michael chang wrote:
> > What birthday exactly is this running for, anyways?
> birthdays. with school starting and stuff, i was also trying to think
> of something for gimp that would be fun. this is sounding to be a lot
> more fun that another splash contest.
o_O Well, in a way, I suppose...
> i think that the web page generated by the script i am sharing later in
> this email is much much worse!
If I get a chance, I'll maybe take a look at it...
> well, i was mostly scripting. not that the script is any prettier...
> the images were made by another resource script i wrote, this one a
> plugin for gimp http://carol.gimp.org/resources/python/resources.py
> it would be trivial to change that script to make different shapes of
> images. and also trivial to use parts of that to make gimp make these
> pages and images at the same time. better because new patterns and
> other resources can be added and you know the image will exist. not
> better because i am uncertain if i am able to run gimp in a way that
> cron can use.
So don't use cron.
> > And yet you understand this planning has to be flexible for the
> > addition of new patterns. Surely there is a way to devise an
> well, no i do not understand that the planning has to be flexible to
> include new patterns. i think it would be better to aim for having
> improved collections for gimp-2.4. both the application and the web
> my script shuffles the list of available resources. it can just as
> easily not shuffle them. it reads the available patterns from the
> system files, so the resources which are in my ~/.gimp-2.3/ are never
> seen. it can just as easily read different resources from a different
How about multiple directories?
> changelogs make themselves :)
> see them? one day. and that is how this page is written to work.
> contribute examples of using a resource? a five day week seems fair for
> this. two days off inbetween "projects" for lack of a better name.
Sounds fair. Would it be ideal to have last week's contributions
shown on the weekends (or two any other days of the week)? E.g. Week
1, Day one, results recieved on day 6, shown on week 2.
> > > wanted to start making vegetable brushes to feed it.
> > What about fruit brushes?
> it doesnt sound as funny when you say it.
> > > in the end, collecting good resources and examples should be the goal
> > > more than something competitive. the apparatus for collecting images
> > > and information is already available. if we can figure out something
> > > that will work without getting too boring or disruptive the software
> > > should already be there to be implemented.
Well, people have reimplemented stuff before (e.g. Apache 2, and other
2 projects) -- sometimes you learn lots of things after doing things
the first time around that you can re apply. Or sometimes it's nice
to take a different look at things.
> > One last note, what language is the R-o-D page generator written in?
> > And how big is your resource collection (e.g. size)? Maybe I could
> > take a look at either the former or the latter, and see what I can
> > suggest.
> python. i am at best a high school level scripter. python keeps it
Have you tried perl? It seems readily available for web usage (IIRC
most CGI scripts are written in either Perl or C++), and handles text
rather well, as well as a couple of other things...
> from not looking bad. also, i am not using my personal collection of
> resources. just the ones that come with gimp so far. this is a scheme
> to get new resources to the gimps web site and to the gimp itself. not
> a scheme, a python trick.
> the web authors of the first generation of the gimps web site had a
> tarball of something like 40,000 gradients you could get and install if
> you wanted. i want to avoid this. i have personally collected brushes
Sounds like a good idea. A tarball is definately a bad idea, but that
said, we still want to make things available when people want them.
Static serving is good for this.
> gradients. every freaking gradient is beautiful. black-->white is
> goregeous if you look at it enough. just because it is pretty and it
> filled the sky in for this one photograph so well doesn't ever mean it
> will have a purpose again.
> gimp needs more animated brushes.
Both absolutely true.
> here is a version of the script that has more information than the web
> page it makes uses:
> my version here is already making index pages that list all of the
> resources it reads. if i can match that with a template of the same
> name, i think it is easy to work with the contest stuff at wgo to put
> something together.
I'll take a look at this some time. Later, I might end up dealing
with Python to mess around with it ( - does Python have a steep
learning curve? ) or trying to rewrite it in Perl/CGI with a couple of
things added in.
> it doesn't need to go on sourceforge to work on www.gimp.org
> it does need to be cleaned up to read the ChangeLog less hacky.
Perl, IIRC, is designed to handle text, so you could try using python
to fetch a processed chunk from a perl script on a web site...
That said, Perl, I'm very sure, is not good for everything. It's just
what I know (in addition to POV-Ray SDL, and Game Maker Language
(www.gamemaker.nl); and a basic comprehnsion of Java and C++; of which
only Perl and POV-Ray I use commonly). I might end up learning Python
if I get the time. I'll look at your script later.
It's a pity the ideas we have aren't ready now -- It'd be nice to have
your "back-to-school" competition on the last two weeks of August, as
opposed to the first two weeks of September. It'd be easier for me
try and scribble something out, at the very list.
- Just my two cents
- No man is an island, and no man is unable.
Gimp-user mailing list