Re: [Gimp-user] Re: [Gimp-developer] New to list--curious about progress of 'Resources'
On Sun, Aug 14, 2005 at 10:55:29PM -0400, michael chang wrote: On 8/14/05, Carol Spears [EMAIL PROTECTED] wrote: On Sun, Aug 14, 2005 at 07:37:20PM -0400, michael chang wrote: 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... in a less than a half an hour i will see if cron puts my new efforts online. 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. cron might work tonight though, just not with gimp. 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 directory. How about multiple directories? well, a look at the script you can see it involves a multitude of multiple directories. 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. i would first need to understand that before i could even consider it. 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. this is not a reimplementation. it should build on something that worked fine. the software that is. gamers.org left it broken in gnomecvs and it magically became fixed just in time for the last contest needing a reliable server. then it worked for the gnome splash contest. thank you for comparing it to Apache2, though. probably it is more like gimp2 to gimp2.2 though. 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... no, do you think it would work better? i have an ongoing theory about the destruction that has befallen my life; occasionally, everything makes sense if i blame it all on daring to ask perl questions via the irc on #gimp. i have seen python scripts used in the cgi-bin. 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. tomorrows task will be to make the script only write a link to the different r-o-d if its page has been modified since its creation. here is a version of the script that has more information than the web page it makes uses: http://carol.gimp.org/gimp2/resources/grod.py 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. i do not know about that. a lot depends on whether my script sends all that crap to my web site or not before anything can be said about python and its learning curve. it does need to be cleaned up to read the ChangeLog less hacky. this is not unlike how i read the ChangeLog, however: http://carol.gimp.org/writing/listsoflists/cgo-Y3K.html 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
Re: [Gimp-user] tutorial/screenshots
Hi all, For those of you who have installed the imagemagick package, try: import -window root root.`date +%Y%m%d%H%M%S`.png for the whole screen. Bind it to a key with your favourite window manager or the xbindkeys utility. Kind regards, Stephan. ___ Gimp-user mailing list Gimp-user@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] Re: [Gimp-developer] New to list--curious about progress of 'Resources'
On Mon, Aug 15, 2005 at 07:03:00PM -0400, michael chang wrote: On 8/15/05, Carol Spears [EMAIL PROTECTED] wrote: 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. i would first need to understand that before i could even consider it. Monday - Friday: Show resource of the day. Saturday, Sunday: Show resources of the past week, in use Better? no, not really. sorry. 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. this is not a reimplementation. it should build on something that I was referring to me, reimplementing your script... i am so very confused now. you will be reimplementing my script in perl to use on your website? worked fine. the software that is. gamers.org left it broken in gnomecvs and it magically became fixed just in time for the last contest Magically? Figures. well, not magically. i asked the system admin for wgo if we could get the contest going easily or not. he looked at it and made it work easily. something like this. it was nice to drag that software quickly out of the old project and have it work so well. one of the coolest things about it was that it deomonstrated how the gimp-user group was able to learn to deal with a primative upload system and from each other. it is a nice group that you do not have to completely idiot proof a web apparatus for. so a couple of doses of stuff that looks like magic but really isn't. needing a reliable server. then it worked for the gnome splash contest. 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... no, do you think it would work better? Perl, IIRC, has been used for dynamic page creation for ages, and contains modules to dynamically create pages on-the-fly, and handle various other CGI tasks. (Among other things, it can also reformat text, and take a binary file and pass it to a user in a browser.) well, there you go. the system admin for my web server is one of the people i think are punishing me for too long for making the mistake of asking a perl question on #gimp from. perhaps this is the reason i see python in the cgi-bin as well. i have an ongoing theory about the destruction that has befallen my life; occasionally, everything makes sense if i blame it all on daring to ask perl questions via the irc on #gimp. Oh ho ho. Have you read the documentation that comes packaged with Perl? If you use linux, install the perl-doc package (or whatever) and read the results in perldoc perldoc and perldoc perl. If you use Windows, get the ActiveState installer, and open up the documentation viewer, by default, at C:\perl\html\index.html. [I personally read this version in Firefox in Linux when working with my computer...] yes, my question to you is have you read those perl docs? i recently spent sometime poking around in the gimp perl scripts. perl seems to allow some tricks that you really have to work at to get python to do. maybe this is just a condition of gimp perl stuff. i read some of those perl docs. did you read them and find them useful? i have seen python scripts used in the cgi-bin. True. But, then again, I've always worked with free web hosts to date (icky) and the ones that support scripting use Perl. PHP is too user-friendly (so they will make people pay for it), and I don't see Python *that* often on these sites. i spent about a week working with a php script. it seemed to take a year to get rid of the smell of chauvinism from my life encounters after this. i think they are related. the question is, pay for access to this? 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. tomorrows task will be to make the script only write a link to the different r-o-d if its page has been modified since its creation. Hum. well, this apparatus is now almost installed. i have now succeeded in making at the very least a little documentation project for myself. this blog could actually be used to make me go through my thousands of digicam pictures, one image a day. notify me when i have finished cleaning one directory. how nice. are you taking notes on this for your sourceforge
