Re: [Gimp-developer] GetMinGWBat.bat Failure
On 12/11/05, Chris Share [EMAIL PROTECTED] wrote: Hi, I'm trying to setup my Windows build environment. I've tried using the GetMinGWBat.bat file however there's a problem with one of the files: wget cannot be found. I've had a look at the .bat file and I think the problem is that it searches for the file at sunsite.dk however this site has moved. The .bat file contains the following: echo getwget.tmp open sunsite.dk echogetwget.tmp binary echogetwget.tmp get /pub/projects/wget/windows/wget-complete-stable.zip echogetwget.tmp close echogetwget.tmp quit Any idea what I should change this to to make it work. Hi, This site works perfectly fine for me. In any case, you can manually download ftp://sunsite.dk/pub/projects/wget/windows/wget-complete-stable.zip and save it in the same folder, and then get rid of the lines that access FTP and hope it works. However, the MOTD explicitly states that there is a Max Load Limit of 30 (whatever that means) so If this limit is exceeded downloads will be disallowed.. You should try again later, or try installing MinGW manually (just make sure you get everything specified in the .bat file so your thing doesn't break). The other possiblity is that sunsite.dk may be blocked for you from upstream. (Read: proxy server, firewall, filtering squid proxy, etc.) If that's the case, then I don't know how you'd circumvent that (or if it's even a good idea). -- ~Mike - Just the crazy copy cat. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] the expanding gimp web
On 11/4/05, Carol Spears [EMAIL PROTECTED] wrote: On Fri, Nov 04, 2005 at 09:28:05PM +0100, Sven Neumann wrote: Carol Spears [EMAIL PROTECTED] writes: there are a few new gimp.org web sites lately. i have been playing with the software available from planet.org and the results have been almost instant. Very nice. I am not sure how useful it is to have different aggregators for developers and users but we will see. What I am missing is a note on the individual sites explaining what feeds they are collecting and perhaps links to the other aggregators? i considered what sort of collections of blogs i would find useful. i also considered what could happen if only a small fraction of the gimp users added their blog to the feed. the developers would be lost. if there was only one feed, the news would get lost as well. i agree that some explanation would help, i got a little confused myself by the gimp object scheme this week while making them. after a short break in working with them, i will see what i can do about adding a little more information. Quite nice, the clean interface makes it easy on the eyes, and it looks like it'll break down nicely if someone's using a console-based browser (e.g. Lynx). Since it's already set up like that, I don't know if you want to change it, but maybe a unified header + description at the top, followed by a selection for Layers | Pixels | Paths would be interesting... http://blogs.gimp.org/layers, http://blogs.gimp.org/pixels, and http://blogs.gimp.org/paths URIs would make sense (although that's less creative, i suppose, than your current offerings). If you did do something like that, http://blogs.gimp.org would maybe also have the same main header as on the above three sites, and then split the three aggregated feeds into individual columns with mini-headers... maybe similar to the column layout at http://www.google.com/ig (except not so interactive and messy...)... each column would be headed b the individual Layers, Pixels and Paths blogs headings respectively. Hopefully the suggestion sounds clear... and maybe it's something worth considering, but take it with a grain of salt. I won't be offended if you don't like it. -- ~Mike - Just my two cents - No man is an island, and no man is unable. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] the expanding gimp web
On 11/5/05, Carol Spears [EMAIL PROTECTED] wrote: On Sat, Nov 05, 2005 at 04:33:08PM +, michael chang wrote: On 11/4/05, Carol Spears [EMAIL PROTECTED] wrote: i considered what sort of collections of blogs i would find useful. i also considered what could happen if only a small fraction of the gimp users added their blog to the feed. the developers would be lost. if there was only one feed, the news would get lost as well. i agree that some explanation would help, i got a little confused myself by the gimp object scheme this week while making them. after a short break in working with them, i will see what i can do about adding a little more information. Quite nice, the clean interface makes it easy on the eyes, and it looks like it'll break down nicely if someone's using a console-based browser (e.g. Lynx). thank you. the very first thing they did when i showed my first gimp web site on the irc was to try it in lynx. this is a fact for anyone trying to design a gimp web site. Since it's already set up like that, I don't know if you want to change it, but maybe a unified header + description at the top, followed by a selection for Layers | Pixels | Paths would be interesting... http://blogs.gimp.org/layers, http://blogs.gimp.org/pixels, and http://blogs.gimp.org/paths URIs would make sense (although that's less creative, i suppose, than your current offerings). If you did do something like that, http://blogs.gimp.org would maybe also have the same main header as on the above three sites, and then split the three aggregated feeds into individual columns with mini-headers... maybe similar to the column layout at http://www.google.com/ig (except not so interactive and messy...)... each column would be headed b the individual Layers, Pixels and Paths blogs headings respectively. one of my irc friends (i always forget that he is one of the people who actually does the work running the gnome computers -- that kind of friend, they are great to make and a rare human who is a friend more than a superhuman ruler of an actual internet domain) does not like the word blog. he said that he doesn't mind the idea of it but would prefer that people call them web journals or web logs. the planet software suggests the word planet. it is implied that the planets show developer web logs. i almost missed this implication and called the user aggregation a planet. there are a bunch of planets already. blogs.gimp.org -- what if the gimp computers started to have more than just me on the computer with a blog? *shrugs* To me, blog doesn't sound right either -- it is a sort of made-up word anyway. But the idea of a quasi-unified interface was just that, an idea. The concept of a whatever.gimp.org/section seemed to make sense to me since the content ... source-type is the same? I have no clue now... Planet would sound nice, except, yes, it is way too common, and I don't think it sounds GIMPy enough (if that's a word). two thoughts about putting the feeds all on one page. 1) is that useful? and 2) gimp is making new images for two of them everyday. they are random in content (somewhat) and also size. a unified look more than what there is now is not more important than how cool those random images are, in my opinion. Hm. Very true, since I guess the whole purpose of the layout is to not detract from the actual content in and of itself. [Well, at least I didn't suggest DHTML sliding menus or panels or something. ;)] i think a short text explaining whose web logs should be enough. Well, it was just an idea -- whatever works, I say. In any case, good luck. -- ~Mike - Just my two cents - No man is an island, and no man is unable. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 16bit channels, doh
On 10/31/05, Brannon King [EMAIL PROTECTED] wrote: So I was told to see the GEGL info. That website (gegl.org) drastically needs a FAQ. Perhaps someone can answer these questions for me: 1. Is GEGL made to replace a certain core piece of GIMP or is it made to reroute data somehow? 2. Why is it not part of the GIMP core currently? 3. Is it activelly being worked on? Is its mailing list still used? 4. It appears to just be an API. Why would using this be better than changing the current GIMP core to support 16bit channels directly? Or are we planning to do just that and just use the GEGL API data structures and constructs? 5. How close is the GEGL code to usable? 6. Will it even work with the current GIMP codebase? If memory serves me right, 8-bit support is pretty mostly hard-coded (or something akin to that) in the current GIMP base, unfortunately. Past talk of adding 16-bit support has sounded as though it requires a major revamping of even core underlying systems that comprise GIMP (sounds like a re-write, almost, even). GEGL (Generic Graphical Library) apparently has something to do with the new-fangled underlying framework for such a project. But I have no idea on the subject, I'm just trying to recall what others have said on this list from memory. 7. Has anyone worked on a merge plan for combining GEGL work with the current GIMP codebase? I believe it's planned for some future release somewhere, but has been continually put off due to a lack of manpower. Or something of that sort. That said, I'm myself wondering whether a 16-bit capable gimp requires a fork, and if so, how much support that fork would get. Should you go forward with this (and I hope you do, as many have been asking for this), then I do wish you good luck, and hope that it comes out quite well. Because I haven't been following development long enough (I'm afraid), someone else probably has a lot of details to add that I may have missed. -- ~Mike C - Just my two cents - No man is an island, and no man is unable. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] PDB access to tools
On 10/27/05, Jon Niehof [EMAIL PROTECTED] wrote: Haven't found anything recent in the archives regarding this--is it possible to access the toolbox in some way via scheme scripts? I want to batch-crop a bunch of images--i.e. write a script that'll load an image, display it, pull up the crop tool, and wait for the user to approve the crop. Then, once the crop is done, save the image, close the window, go to the next one. IIRC, The tools simply provide a gui interface to simplified pdb functions that can be called directly in scripts, such as gimp_image_crop. Also, IIRC, there isn't really a good way of prompting the user for confirmation with that kind of instance in script functions. In addition, loading multiple images looks like either you're using GLOB or having them hard-coded (*shivers in ugliness*). Finally, it is worth noting that there is an autocrop option in one of the image menus (and PDB has plug_in_autocrop and plug_in_autocrop_layer). In my experinece, unless you're processing, say, 500+ images, it looks like it'd be more work to get a script to simply open, show, and close those images, let alone do anything with them, especially in Scheme/Script-fu, than to do it by hand. (Once it *is* done, however, it is nice to have, I'm sure.) One tool that may be of help if you do proceed with this - in GIMP, there is a Procedure browser in the Xtns menu in 2.2.8 and 2.3.4 (probably in various others; has this moved yet in CVS?), sometimes you can search for the action you want to do (e.g. crop) and you'll get a list of script-fu/pdb procedures, which parameter lists. (Avoid ones marked deprecated!) Note that, IIRC, script-fu seperates words with the - (dash) not the _ (underscore) last I checked, although the PDB shows it the other way around. Please note that there may be errors in my answer, if so, someone else may be able to correct them. Take my response with caution. -- ~Mike - Just my two cents - No man is an island, and no man is unable. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP 2.3.5 cvs compile fails
On 10/23/05, Timo Gerke [EMAIL PROTECTED] wrote: michael chang schrieb: On 10/22/05, Timo Gerke [EMAIL PROTECTED] wrote: Hi all, I just checked out cvs gimp 2.3.5. As I tried to compile it, it complained that gimp-print isn't installed. So far this is right but I know that gutenprint (yes, the developement files too) is installed on my system. So configure has stopped running. I guess that gutenprint is not yet supported by gimp. I'd like to print in gimp. Very Untrue! Gutenprint is very much supported by GIMP. Is gutenprint palnned to be supported in the next time? Did you install the gutenprint development libraries/packages? Or did you install it from scratch (a.k.a from sources)? If neither, then GIMP won't find gutenprint's sources (which it needs to link with in order to make the print plugin). I'm wondering gutenprint development (version 5.0-rc1, debian package) are insatlled on my system. I just installed libgnomeprint/libgnomeprintui 2.10.3 developement files. They are detected by configure. That's not the same as gutenprint or gimp-print... Try installing libgutenprint-dev and libgutenprintui2-dev packages (and their dependencies) and then try again. aptitude install libgutenprint-dev libgutenprintui2-dev as root should do the trick. If you're in a rush, you can also disable the print plugin. (But you won't be able to print). Do note you'll also need the python development libraries unless you explicitly disable python support. I also installed python development files. May be 2.3 is too old? I doubt it - either way, python has nothing to do with printing (last I checked). -- ~Mike - Just my two cents - No man is an island, and no man is unable. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP 2.3.5 cvs compile fails
On 10/22/05, Timo Gerke [EMAIL PROTECTED] wrote: Hi all, I just checked out cvs gimp 2.3.5. As I tried to compile it, it complained that gimp-print isn't installed. So far this is right but I know that gutenprint (yes, the developement files too) is installed on my system. So configure has stopped running. I guess that gutenprint is not yet supported by gimp. I'd like to print in gimp. Very Untrue! Gutenprint is very much supported by GIMP. Is gutenprint palnned to be supported in the next time? Did you install the gutenprint development libraries/packages? Or did you install it from scratch (a.k.a from sources)? If neither, then GIMP won't find gutenprint's sources (which it needs to link with in order to make the print plugin). If you're in a rush, you can also disable the print plugin. (But you won't be able to print). Do note you'll also need the python development libraries unless you explicitly disable python support. -- ~Mike - Just my two cents - No man is an island, and no man is unable. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] ScriptFu upgrading
On 10/11/05, Helmut Jarausch [EMAIL PROTECTED] wrote: Hi, I've noticed that some ScriptFu scripts run just fine under 2.2.x but produce error messages under 2.3.5 (CVS) Is there a summary of API changes, possibly with hints for upgrading? A) I have not heard this, but if it's anywhere, it probably is in the changelog. This is a hunch (meaning, not verified), but I'd presume deprecated functions (stuff from the 1.x era) may have been removed, at the very least. B) Some people use Tiny-Fu instead of Script-Fu in 2.3.5 or so - in this case, see the Tiny-Fu page for some recommendations. IIRC, Tiny-Fu hasn't, however, officially replaced Script-Fu. An actual developer probably would have a better and/or more specific answer. -- ~Mike - Just my two cents - No man is an island, and no man is unable. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP 2.3.4
On 10/4/05, Lance Dockins [EMAIL PROTECTED] wrote: this is so interesting. Win32 has succeeded in making linux expensive. you are asking that the Win32 environment not work the way it was designed to work -- at least i think this is what you are saying. i am very impressed that it was able to make free software expensive, this is a simply amazing accomplishment! Carol, Where in my e-mail did your read that *Linux *was going to cost me money? Read that sentence again. Or, better yet, I'll quote it. I should also clarify that I have considered switching to Linux to make this easier, *but I just don't have the time, money, and hardware to do so without destroying the Win32 environment I'm required to use in the professional world.* Did I say that the money, time, and hardware I was going to invest was going to be invested in buying Linux or did I just say that I would have to invest money, time, and hardware into a Linux setup? Here's a few things that cost money that fit perfectly into that sentence. * Time * A spare hard drive * A reliable partition manager (instead of a drive) * Perhaps an alternate computer entirely * Potential other hardware for those components that Linux drivers don't function well on. Before I sign off on this, let me quote the second half of that sentence again. **But I just don't have the time, money, and hardware to do so *without destroying the Win32 environment I'm required to use in the professional world.* So that pretty much eliminates installing over top of my current OS. Nonsense. Debian's installer can resize ALL Win32 partitions (NTFS + FAT) and make room for itself nondestructively. -- ~Mike - Just my two cents - No man is an island, and no man is unable. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP 2.3.4
On 10/4/05, Tor Lillqvist [EMAIL PROTECTED] wrote: lode leroy writes: The thing is that for compiling gimp from cvs, you need quite some expertise in the autotools, libtool, aclocal, pkg-config etc to fix those not-100%-working-together- distributed binaries... Would it be feasible to create a big zip-file that contains everything for gimp for download? It would be possible, but wouldn't such a zipfile just create open up the possibility for even more confusion when there would then be yet another distribution of these libs? (A long time ago I *did* distribute self-built jpeg, tiff, zlib and whatnot, but stopped doing that as there were other distributions, too, that were just as good, or even more directly from the source, like zlib.) Since you've found these better sources, I know it'd be a pain, but could you include links to them somewhere? That way, we can use the same DLLs built that you do. (I'm presuming you don't already; if you do, my apologies.) -- ~Mike - Just my two cents - No man is an island, and no man is unable. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Survey of usability in open source software development
On 10/3/05, Bill Kendrick [EMAIL PROTECTED] wrote: On Mon, Oct 03, 2005 at 09:01:46PM +0200, [EMAIL PROTECTED] wrote: On Monday, October 3, 2005, 9:59:40, Simon Ormholt Schrøder wrote: Right now we are conducting an electronic survey to get an overview of current usability effort within the open source community. We encourage you to participate at http://www.sieker.dk/survey/survey.php?sid=28 http://www.sieker.dk/survey/survey.php?sid=28 (the survey takes approx. 15-20 minuttes) I tried to participate in the survey, but it won't let me past the 1st page of questions (Country, City, Age, Occupation) - when I click Next Page, the page just reloads (with my answers inserted). It worked fine for me. I filled out the survey from my Tux Paint leadership role. :^) Perhaps reloading the same page is its way of saying you haven't filled out the required fields...? I used Mozilla on WinXP (ugh) with JavaScript (ugh) enabled, in case it matters. I haven't filled out the survey (I don't consider myself a GIMP developer yet per-se, as I haven't actually contributed code to the GIMP or even done major testing), but I can go back and forth on the first few pages... Mozilla Firefox 1.0.6 on Debian Linux Unstable, both with Javascript Enabled and Disabled. -- ~Mike - Just my two cents - No man is an island, and no man is unable. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Designing a Better Font Selection Widget for use in Open Source Software
On 9/27/05, Edward H. Trager [EMAIL PROTECTED] wrote: ... regarding a proposal for an improved font selection drop-down widget that would be ideal for use in professional-quality Open Source word processing, desktop publishing, and graphic design programs http://eyegene.ophthy.med.umich.edu/unicode/fontdialog/ As a user, this sounds like a very awesome proposal, and if implemented, would revolutionize font GUIs for users. I don't know whether it could cause a problem with Usability (e.g. Text to Speech systems) though... Just a note (and yes, I'm nit-picking), but there is no such thing as 'a Chinese pangram'. Chinese uses individual characters for every word (AFAIK), so you'll just have to choose some sample text that is representative of the language, or make some up. IIRC, Japanese has an alphabet, though, and Chinese has a sort of 'proununciation' alphabet (but that's seperate). -- ~Mike - Just my two cents - No man is an island, and no man is unable. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP 2.3.4
On 9/25/05, Michael Schumacher [EMAIL PROTECTED] wrote: michael chang wrote: On 9/23/05, Michael Schumacher [EMAIL PROTECTED] wrote: michael chang wrote: The problem is that when the timeout dies, then should be a new version; if there isn't one, it's kinda silly to have to re-install the same version to extend the timeout. Reinstalling the same version wouldn't help, I'm talking about a hard timeout there - created when the release tarball is made, for example, and set to e.g. 60 or 90 days into the future. What I mean is lets say the software times out after 70 days the RC/beta is made. That means that there has to be a new RC/beta after 70 days, or otherwise no one can use it post those 70 days. If there isn't, then someone might just rebuild the current RC for another 70 days, which is pointless. E.g. if there was a 2.3.5 today, and it expires in 60 days. So that means 2.3.6 has to be released within 60 days. How do we know 2.3.6 will be ready in 60 days? If you want to force yourself on such a release cycle, by all means, but last I checked, GIMP doesn't used fixed release cycles. I could be wrong though; I'm not a GIMP developer. I mean, it's not like fixed release cycles are all that bad of a thing. Then again, you might want to give yourself some leeway (e.g. trying to release a version of GIMP 15 days before the last RC/beta expired or something; that way delays can be absorbed into the 15 days that remain from the last RC/beta/devel release). In that case, determining a timeout would be hard... Not really. Running development releases is only useful up to a certain time anyway - once current CVS has advanced considerably, there is not much to be gained from using an outdated one. Also, this should encourage people to keep the latest stable release installed - after all, this one will not time out. Well, that's very true. I believe the 2.2.8 version of gimp is really a 2.2.7+cvssomething on Debian - and those are offical packages. And finally, if anyone insists on using a development release longer than the timeout lets him, he can alwyys use the source and disable the timeout at compile time - and we can assume that if someone pops up with an outdated release he know what he's doing. True. -- ~Mike - Just my two cents - No man is an island, and no man is unable. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP 2.3.4
On 9/23/05, Michael Schumacher [EMAIL PROTECTED] wrote: michael chang wrote: Solution: Linux/POSIX emulation layer. Cygwin is usually used. MinGW/MSYS is also workable, IIRC. I've never compiled GIMP on either, though. For GIMP, I'd say that MinGW is preferred - not that there shouldn't any I prefer MinGW myself, but I believe that if the guy knows how to compile on Linux, it might be more familliar to him to emulate Linux/POSIX on Windows with Cygwin than figure out MSYS/MinGW. But then again, I found it easier to get used to MSYS/MinGW than Cygwin, so... *shrugs* Of course, at the end of the day, I think it'd be nicest if they made an installer for the Windows binaries for the development releases, but I'm quite sure that's probably more work than it's worth. Problem: how to keep each of the places distributing GIMP (some net magazines, other random websites, users) from mistaking it as a new stable release. How about not releasing it on the standard page (e.g. hiding it in the developer website somewhere)? I like the timeout idea too, personally -- POV-Ray (www.povray.org) has monthly timeouts for its various beta versions (and they have a new beta RC every month). The problem is that when the timeout dies, then should be a new version; if there isn't one, it's kinda silly to have to re-install the same version to extend the timeout. In that case, determining a timeout would be hard... -- ~Mike - Just my two cents - No man is an island, and no man is unable. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP 2.3.4
On 9/23/05, Lance Dockins [EMAIL PROTECTED] wrote: Actually... I was trying to figure out what the best way to do that would be... mostly because I run GIMP in a Win32 environment, so compiling GIMP isn't quite as straightforward as it is in Linux. If I Solution: Linux/POSIX emulation layer. Cygwin is usually used. MinGW/MSYS is also workable, IIRC. I've never compiled GIMP on either, though. could figure out how to compile from CVS on Win32, I definitely would. Of course, I'm just going on the info I found at wiki.gimp.org that said that compiling from CVS required additional software. Then again, maybe Cygwin or MinGW/MSYS, as I said. You'll also need the development codes for various graphics libraries, e.g. libpng-dev. These are provided in sepearte packages (e.g. select in the Cygwin Installer) or available by compiling the libraries from source. I'm just overcomplicating this. Is it as simple as downloading the source from CVS and compiling it? And for that matter, if that's the Almost. case, is there an easy way to download the source from CVS? Thanks in The cvs tool. ;) advance for any feedback you can offer. Sven Neumann wrote: Hi, Lance Dockins [EMAIL PROTECTED] writes: I've been testing GIMP 2.3.3 and I noticed that some of the changes of late have indicated we're nearing a 2.3.4 release. Does anyone know what timeframe we're looking at for the 2.3.4 release? Whenever I get around to do it, which will hopefully be this weekend. But, seriously, why don't you just use CVS? Of course, at the end of the day, I think it'd be nicest if they made an installer for the Windows binaries for the development releases, but I'm quite sure that's probably more work than it's worth. One of these days, I know I'll get around to compiling GIMP from CVS myself. Just need to clear out some working space first. -- ~Mike - Just my two cents - No man is an island, and no man is unable. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: R: [Gimp-developer] Error compiling gimp 2.3.3 with mingw on winxp
On 9/15/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi, thanks for your help, I commented out the #include_next thing in d:/mingw/include/unistd.h (don't know if it is the right way ...) and it compiled fine with: ./configure --disable-print --disable-python --prefix=/d/gimp233 Now, do you know how to make it print in windows? You have to be able to compile the files that are compiled when ./configure is run with --enable-print. I believe Gutenprint may help; but I'm not sure (not even close). Also is python scripting supported on windows? AFAIK, It's doable, although it will be easier (afaik, meaning that it might be in the binaries) in the final 2.4 release -- try checking the archives (a success with gimp 2.3.3 + win + python is there somewhere). -- ~Mike - Just my two cents - No man is an island, and no man is unable. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Fwd: Some suggestions for the plug-in registry]
On 8/26/05, Nathan Summers [EMAIL PROTECTED] wrote: On 8/26/05, Sven Neumann [EMAIL PROTECTED] wrote: Hi, michael chang [EMAIL PROTECTED] writes: 1. Make it possible to indicate that a plug-in requires GIMP 2.2 2.3, and 2.4 options would be nice here too, I suppose. And also, change the list of links of types to a drop down box, maybe? (Dunno.) 2.3 is a development version with no API guarantees whatsoever. The API is constantly changing and noone should be developing any plug-ins for it. If you have such a closed Gimp Club attitude, why make developer releases at all? After all, all the members of the Gimp Club have cvs accounts. One of the most important reasons that we have preview releases is so that when 2.4 is released, third-party plugins are already available for it. It's abundantly obvious that 2.3 is a developer edition, with all that entails, and both users and plugin developers are aware of the fact that things can break, but that doesn't mean that it's counterproductive to track development and to test the new features. Would you prefer that serious problems in newly added plug-in apis not be discovered until after they are frozen? Oh pah, stop arguing, I wasn't intending to get you guys angry. Geez. It was a suggestion. If you don't like it, that's perfectly fine -- but adding them now would prevent us having to go and bug Mr. Web Developer again when 2.4 is released. (If he has to add all plugins manually at the moment, then there isn't much point, but if it's semi-automated or automated, adding them now but placing some sort of consensus not to put things there works too.) If it helps, why not have a (2.3/beta) or (current open beta) section, and then wipe it when 2.4 is released? Obviously, if you don't like it, that's fine... Since 2.3 cvs contains a plugin that was originally maintained separately, and GIMP was developed against gtk 1.3 long before API freeze, it's obvious that you already know this, which makes me ask the question: why did you say this in the first place? Seriously, it served no other purpose than discouraging people from testing the 2.3 series. GIMP isn't exactly overwhelmed with volunteers. We should be doing everything we can to encourage more people to try out 2.3, and more people to be testing its new features. Yes, that even includes those features that have to be accessed programmatically. Anyone who is capible of developing a plugin against 2.3 is capible of fixing any breakage if we change a non-frozen API. And 2.4 shouldn't be added before the 2.4 release. That's a matter of taste. After all, if 2.4 is backwards compatible with 2.0 plugins, there are a ton of plugins that are already 2.4 compatible. What's not a matter of taste is that plug-ins shouldn't be marked as 2.4 compatible if they use non-frozen APIs. After the API is frozen is a different matter. I presume that this statement is made assuming 2.4 doesn't become 3.0... -- ~Mike - Just my two cents - No man is an island, and no man is unable. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Fwd: Some suggestions for the plug-in registry]
On 8/27/05, Sven Neumann [EMAIL PROTECTED] wrote: Hi, I am not going to respond on your mail in detail, mainly for lack of time. Lots of good points being made and taken. However I would like Time is always an important issue, and a lack of it may cause curtness. It'd be nice if everyone always took this into consideration, but sometimes we forget from time to time. Reminders are sometimes necessary, and this one was well placed. to state that I am not at all unwilling to mentor new developers. I That is very reassuring, yes. also think that our (and that includes mine) attitude towards new ideas and requests for changes has become a lot better over the last years. You are right that we are lacking active developers but we Indeed. gained quite a few new ones recently and I am not sure if they receive GIMP development as bad as you put it. Quite a few people are rather enthusiastic about it and I would love to have more time to help them get into it. Hopefully, so would everyone else... ^_^ -- ~Mike - Just my two cents - No man is an island, and no man is unable. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Using GIMP for Paper Prototyping the Colors Menu
On 8/27/05, Akkana Peck [EMAIL PROTECTED] wrote: card-sorting app to help with distributed paper prototyping. But it occurred to me (based on an offhand comment I read on slashdot, of all places) that GIMP itself could be a pretty good paper prototyping system. After all, you can have lots of text layers and As a side note, this is actually a very good way of using the GIMP -- I used it myself when trying to solve a puzzle I was given by a teacher. Quite handy! It might help if you bind the text layers to a coloured layer, (either white, or white with an outline, or something), so they're easier to see. [Especially if trying to create a layout that fills multiple conditions.] -- ~Mike - Just my two cents - No man is an island, and no man is unable. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Using GIMP for Paper Prototyping the Colors Menu
On 8/27/05, michael chang [EMAIL PROTECTED] wrote: It might help if you bind the text layers to a coloured layer, (either white, or white with an outline, or something), so they're easier to see. [Especially if trying to create a layout that fills multiple conditions.] Sorry, said this before looking at the script. Very nice! [I don't believe it would be sane to say maybe considering optionally having coloured backgrounds/background outlines per layer (to catagorize items, maybe), nor to allow for all the pieces to be stuck in a pile in the corner -- but then again I believe I'm a very insane person. Although that's what I meant, on reconsideration, that would be too much work and looping IMO for such a simple script.] -- ~Mike - Just my two cents - No man is an island, and no man is unable. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Fwd: Some suggestions for the plug-in registry]
On 8/26/05, Michael Schumacher [EMAIL PROTECTED] wrote: As promised on IRC, my suggestions for the registry. Originally sent to the maintainer of the registry. Sounds awesome. 1. Make it possible to indicate that a plug-in requires GIMP 2.2 2.3, and 2.4 options would be nice here too, I suppose. And also, change the list of links of types to a drop down box, maybe? (Dunno.) 2. Compress the recent changes list 3. Make the recent changes available as a RSS feed Very useful, then I can add the RSS feed to my browser. ^^ 4. Add a way to indicate the availability of binaries for a specific platform Something similar to the way tucows.com does their listings would be a good idea. Eg: = [Plugin name] . [Win] [Linux RPM] [Linux Deb] [Mac OS X] [Source] [Plugin catagories] [User based rating (maybe, maybe not)] [Language/format] [Requirements (optional/if specified)] [Plugin description summary]... [more info link to full description] = This could be unified, as well (e.g. anywhere plugins are listed this format would go there). -- ~Mike - Just my two cents - No man is an island, and no man is unable. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] authors.xml, volunteer needed
On 8/26/05, Sven Neumann [EMAIL PROTECTED] wrote: Hi, Sven Neumann [EMAIL PROTECTED] writes: http://cvs.gnome.org/viewcvs/gimp/authors.xml?view=markup I am now looking for a volunteer to go over authors.xml and check what roles apply to the people listed there. Perhaps also check that noone important is missing (last time we did that was before the 2.2 release). No coding skills required, you don't even need to know anything but the mere basics about XML. Some knowledge of the GIMP history will definitely help though... No response whatsoever. So there isn't even interest in helping with the simple tasks any longer? This is becoming somewhat frustrating... I wasn't sure if I should attempt the task or not, and was kinda hoping someone else would take the task (because I'm fiddling with some other things in POV-Ray and Perl, among other things). But I believe I could attempt this, if you can point me generally at the document sources I might want to look up, and what special instructions I'd need for submitting the finished product. -- ~Mike - Just my two cents - No man is an island, and no man is unable. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] authors.xml, volunteer needed
On 8/26/05, Simon Budig [EMAIL PROTECTED] wrote: Sven Neumann ([EMAIL PROTECTED]) wrote: Sven Neumann [EMAIL PROTECTED] writes: http://cvs.gnome.org/viewcvs/gimp/authors.xml?view=markup I am now looking for a volunteer to go over authors.xml and check what roles apply to the people listed there. Perhaps also check that noone important is missing (last time we did that was before the 2.2 No response whatsoever. So there isn't even interest in helping with the simple tasks any longer? This is becoming somewhat frustrating... I am pretty sure that it is *not* simple and that there are very few people being able to do that. And no, I don't think I could do this. I believe that compared to coding C++, this is supposed to be considered simple - the generic, old, mundane task of compiling a list of names. ^^ I believe that in the olden days this used to be the sort of job an entry level worker would do in a corporation. There are too many names in that file I've never heard of and I have no interest at all go digging through ancient maillogs or changelogs just to figure out if someone was a contributor or doc-writer or whatever. What about a collaborative effort? E.g. someone goes and checks through these things, and then someone can double check. Or the list can be split in half, and then if there's ones we're unsure about we send them to the other person (and vice versa). -- ~Mike - Just my two cents - No man is an island, and no man is unable. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] script fu and image file support?
On 8/23/05, woc [EMAIL PROTECTED] wrote: I do not want to write a .c plugin, because portability is more important to me than speed. Gimp itself is written in some variant of C, isn't it? The only portability issue here is that you'd need to compile it on all target OS's. No big deal -- that's how GIMP is made anyways. Use MinGW for Windows, and Linux uses the GCC and related tools. Easy enough. Script-Fu only has the advantage of not requiring compilation before execution, but it doesn't handle Raw IO or pixel-based image creation IIRC (for good reason, too, proally). Perl probably has similar limitations, to a certain extent. Perl handles text best -- binary data, it's best at simply passing... I believe the term is ad verbatim or something. Try copying a C image format plugin that already exists, maybe (e.g. xbm)? -- ~Mike - Just my two cents - No man is an island, and no man is unable. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] script fu and image file support?
On 8/24/05, woc [EMAIL PROTECTED] wrote: On 8/24/05, Manish Singh [EMAIL PROTECTED] wrote: Yeah, and you contradicted this statement when you said that C wasn't portable enough for you. There are differing definitions of what portability means. C is definitely less portable than I'd like. I presume you mean this in the sense that you'd want to write it and distribute it as-is for your users in this cases? If you want, you can always cross compile for Windows on a Linux system, and develop on Linux. (Not sure about vice-versa.) Mac OS X, IIRC, comes with a compiler; Linux might, if you specify it, but various people use deb binaries or rpms. *sighs* If Windows compatability isn't a issue immediately (future problem) then, of course, Python would be the way to go for your circumstance. From what I gather, many people seem to use the Python bindings. I really do appreciate you helping me get oriented. That is quite useful -- I'm sure you've saved me days or weeks of searching the docs for how to make script fu work when basically I would have been wrong to try that route. At least that got straightened out. -- ~Mike - Just my two cents - No man is an island, and no man is unable. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New to list--curious about progress of 'Resources'
On 8/16/05, Carol Spears [EMAIL PROTECTED] wrote: On Tue, Aug 16, 2005 at 11:05:59PM +0200, Sven Neumann wrote: I've been watching the (Gimp)web site for some time. Is there some realistic date when we can expect to see the 'Resources' section updated?? Since there is absolutely no progress whatsoever with the GIMP website, this isn't likely to happen ever. Perhaps you want to help us to get the website back to live? the gimp developers seem to be plagued by low self esteem. one good way to get people involved is to perhaps offer something that builds confidence and displays good faith in an individuals ability to take on a project like that like a publisher. Where is the GIMP Website located (in terms of making changes)? If someone wants to help e.g. do one page, but not take over the whole project, how would s/he go about propagating the changes to the GIMP website (if approved)? -- ~Mike - Just my two cents - No man is an island, and no man is unable. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New to list--curious about progress of 'Resources'
On 8/17/05, Carol Spears [EMAIL PROTECTED] wrote: On Wed, Aug 17, 2005 at 03:58:34PM +0200, Michael Schumacher wrote: On as side not, it is strongly recommended to take Carol's rumbling with a (huge) grain of salt - she like to overexaggerate and to play with other people, although she will disagree on the latter :) sure. don't let me do all the telling. you wanted to work with the wiki. can you tell how that progressed? I it rather amusing you two both said the same thing -- although Michael managed to say it in one message, whereas Carol used two. ^^ I suppose it could have been worse... And no, I'm not backed by any corporation -- I don't even have a job at the moment (this is all hobby work and speculation; I'm a high-school student). -- ~Mike - Just my two cents - No man is an island, and no man is unable. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp_image_delete and adding text layers
On 8/17/05, Jared Whiting [EMAIL PROTECTED] wrote: increase, but the cgi I'm using in production does a lot more than this and can be generating a few thousand images in one day. Are any of these concurrently, and if so how many; could this make a difference? -- ~Mike - Just my two cents - No man is an island, and no man is unable. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New to list--curious about progress of 'Resources'
On 8/16/05, Leon Brooks [EMAIL PROTECTED] wrote: On Tuesday 16 August 2005 07:04, michael chang wrote: *sighs* PHP4, though, requires parsing *EVERY* page as it goes out of the server. No, just the PHP pages. I run mixed sites, and it's quite efficient as an Apache module, no significant performance penalty for a HTML page parsed through it (ie, no PHP code in it, just named .php or .phtml or whatever so that it gets feed to PHP). Altight, PHP4, requires parsing *EVERY* PHP4 page as it goes out of the server. If the entire site is PHP4, or PHP4 generated, though... *shrugs* I know SSI is similar to PHP4, IIRC, although it's less complicated, built in to the server, etc. Dunno how it differs in load, but it's about the same, last I checks. I've tried PHP4 before, but I personally like perl better. I'm sorry, what's a CMS? Content Management System (slight variations on the acronym, but the idea is common): a way for dumb or busy users to easily manage website content. A wiki is a kind of CMS. Zope or Plone are common and more typical examples. Thanks. -- ~Mike - Just my two cents - No man is an island, and no man is unable. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp_image_delete and adding text layers
On 8/15/05, Jared Whiting [EMAIL PROTECTED] wrote: machine because in the process of creating images the GIMP keeps holding on to more and more memory. As an example, I can run the following $img-gimp_image_undo_enable; gimp_image_delete($img); Gimp::end; the GIMP instance grabs on to more memory and holds on to it permanently. Deleting the image and disabling undo do not result in the GIMP releasing memory for the new layer it created. I would prefer not What about putting $img = undef; at the end -- does this change anything? Also, in the Perl Docs, perlfaq3: = How can I free an array or hash so my program shrinks? (contributed by Michael Carman) You usually can't. Memory allocated to lexicals (i.e. my() variables) cannot be reclaimed or reused even if they go out of scope. It is reserved in case the variables come back into scope. Memory allocated to global variables can be reused (within your program) by using undef()ing and/or delete(). On most operating systems, memory allocated to a program can never be returned to the system. That's why long-running programs sometimes re- exec themselves. Some operating systems (notably, systems that use mmap(2) for allocating large chunks of memory) can reclaim memory that is no longer used, but on such systems, perl must be configured and compiled to use the OS's malloc, not perl's. In general, memory allocation and de-allocation isn't something you can or should be worrying about much in Perl. See also ``How can I make my Perl program take less memory?'' = How can I make my Perl program take less memory? When it comes to time-space tradeoffs, Perl nearly always prefers to throw memory at a problem. Scalars in Perl use more memory than strings in C, arrays take more than that, ... [I suggest you read the entirety of this question in the actual FAQ, it might be helpful.] = Hope this helps. -- ~Mike - Just my two cents - No man is an island, and no man is unable. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New to list--curious about progress of 'Resources'
On 8/16/05, Leon Brooks [EMAIL PROTECTED] wrote: On Tuesday 16 August 2005 22:35, michael chang wrote: Altight, PHP4, requires parsing *EVERY* PHP4 page as it goes out of the server. As does mod_perl every .pl page, no? Indeed it does (I do even worse; I usually call the perl executable from CGI, on my system at least, when testing); but I usually go to the trouble of writing my pages and scripts so that static pages are generated from CGI scripts wherever possible. For example, http://starglassstudios.netfirms.com/mirrors.html was dynamically generated by a CGI script, but the only bits being called as CGIs are the OK status buttions (-- these scripts reside on my PC at the moment, so aren't available 24/7 though). The whole page used to be CGI generated on the fly, and I still have that version, but I like this one better. When, and if, I get around to trying to write a resource-a-day script in perl, I'd use this technique, unless instructed otherwise. Although, at the moment, I believe I'll let Carol keep her script maintained -- I'd rather not have the pressure on me, just in case I never get around to writing the script. If I finish it, I'll letchall know. -- ~Mike - Just my two cents - No man is an island, and no man is unable. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New to list--curious about progress of 'Resources'
On 8/15/05, Leon Brooks [EMAIL PROTECTED] wrote: On Tuesday 16 August 2005 04:10, Carol Spears wrote: I am curious what you must do before you can see the upload page? Register and log in. do you know what it is written in? The project is linked from the lower left of each gallery page: http://gallery.sf.net/ It lists PHP4 as a requirement, so that's probably what it's written in. *sighs* PHP4, though, requires parsing *EVERY* page as it goes out of the server. Not exactly efficient -- it could put a toll on the server. *sighs* it is interesting that you start with a very plain page and then click through to a stylized page. I think this is the recommended design in one of the HTML design books I read... The plain page is essentially a lightweight splash, the rest is the real gallery. The gallery is designed to be embeddable in several CMSes. I'm sorry, what's a CMS? -- ~Mike - Just my two cents - No man is an island, and no man is unable. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP print dialog issues
On 8/15/05, Brian Thomason [EMAIL PROTECTED] wrote: I am packaging up gimp 2.2.8 for Linspire and have noticed some strange When the print dialog is open, the orientation is set to Auto, which is good, but none of the default position indentions are set. (Left, Right, left Border, etc...) For the common user, he will just hit print when presented with the dialog, and this will simply fail as it is. Which printing system does Linspire use? (e.g. CUPS, BSD, etc.) Does it make one of it's own to make it similar to Windows? -- ~Mike - Just my two cents - No man is an island, and no man is unable. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP print dialog issues
On 8/15/05, Brian Thomason [EMAIL PROTECTED] wrote: michael chang wrote: On 8/15/05, Brian Thomason [EMAIL PROTECTED] wrote: I am packaging up gimp 2.2.8 for Linspire and have noticed some strange When the print dialog is open, the orientation is set to Auto, which is good, but none of the default position indentions are set. (Left, Right, left Border, etc...) For the common user, he will just hit print when presented with the dialog, and this will simply fail as it is. Which printing system does Linspire use? (e.g. CUPS, BSD, etc.) Does it make one of it's own to make it similar to Windows? We use CUPS. (No modifications, other than cosmetics) With or without BSD daemons? -- ~Mike - Just my two cents - No man is an island, and no man is unable. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP print dialog issues
On 8/15/05, Brian Thomason [EMAIL PROTECTED] wrote: michael chang wrote: On 8/15/05, Brian Thomason [EMAIL PROTECTED] wrote: I am packaging up gimp 2.2.8 for Linspire and have noticed some strange Right, left Border, etc...) For the common user, he will just hit print when presented with the dialog, and this will simply fail as it is. At odd times, if the user doesn't flatten the image before printing, it will only print the current layer. And he'll wonder why half his image is gone. [I can't remember what version of GIMP/GIMP-Print this is in.] Some who are prompted for auto-flattening-export think it will perminantly flatten their image, and look for a work around. Are you packing gutenprint/gimpprint also? -- ~Mike - Just my two cents - No man is an island, and no man is unable. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP print dialog issues
On 8/15/05, Robert L Krawitz [EMAIL PROTECTED] wrote: That shouldn't have any effect here. Gimp-Print doesn't really care what the underlying spooling system is. How does it contact the spooling system? Or does it use specific methods for each printing system? -- ~Mike - Just my two cents - No man is an island, and no man is unable. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] AGEIA PhysX chip physX SDK(NovodeX v2.2 SDK) AGEIA PhysX chip physX SDK
On 8/6/05, Gottfried Zojer [EMAIL PROTECTED] wrote: But is anybody aware if there is somebody working on a project to bring Gimp to run with the AGEIA PhysX chip ( is there any documentation about how to use the NovodeX v2.2 SDK in combination with a Gimp plugin Thanks for any feedback The GIMP performs 2D image manipulation, not 3D physics manipulation. None of the features in the PhysX chip apply to what GIMP does, so it's highly unlikely that any of the filters or plugins use this chip. He is probably referring to the 3D effects that can be done via plug-ins. If you wish to speed up the performance of The GIMP, get a faster CPU, and more, faster memory. A faster hard disk (maybe small, high-speed SCSI disk) [or a partition of such a disk, used when the disk is not being used for other activities] used exculsively for The GIMP may or may not also improve performance. None of these statements are guaranteed to be true, and are merely speculation. Take with a grain of salt. -- ~Mike - Just my two cents - No man is an island, and no man is unable. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Fwd: [Gimp-developer] Question about the plug-in system.
[My apologies, I forgot to CC to the list. ^^] On 8/4/05, Joao S. O. Bueno Calligaris [EMAIL PROTECTED] wrote: On Thursday 04 August 2005 18:43, Axel Philipsenburg wrote: What I'd like to do is to write a plug-in that would make the Gimp a nice tool for 3D artists by showing a 3D object in a seperate window with the currently selected Gimp image as UV mapped texture. The 3D object would be loaded from a Wavefront OBJ file with all UV mapping coordinates and been displayed by using OpenGL. The only thing that gives me worries about this, is if the Gimp plug-in system would allow a seperate window to be constantly displayed and updated whenever a tool operation is finished so that the artist can practically see each brush stroke (or other tool usage) instantly on the 3D object once the tool has been used. Offically it is not possible. That is: there is no way for the GIMP to call back your plug-in whenever an action is performed. Either way, the idea of redoing this every time an action is finished sounds very scary. What happens when I don't want to use it, or if I run a script-fu or something? I'd rather be able to preset the settings, and then just click an Update Preview function. This _IS_ a preview type thing, isn't it? Otherwise it would be kind of weird... However nothing but the extreme deselegance of it can stop your plug-in of pooling the GIMP for image data every few seconds. I believe you mean polling. And while this doesn't sound impossible, would GIMP allow for a Plugin to open a window, poll, and still let the user continue working? If memory serves me right, every other plugin I know of, GIMP hands total control over to the plugin, and freezes (if you will) while the plugin is running. So if the window stays open, will I even be able to make a change in the meantime? If you can't get an autoupdating one working, at least one that doesn't auto-update would be nice. [Especially if you're willing to maintain it through the versions. *ahem*] Just a thought, how are you going to set the camera angle though? -- ~Mike - Just my two cents - No man is an island, and no man is unable. -- ~Mike - Just my two cents - No man is an island, and no man is unable. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp as UV mapping tool.
On 8/5/05, Axel Philipsenburg [EMAIL PROTECTED] wrote: Michael mentioned that Gimp Plug-Ins might not be able to allow further manipulation to the image while running because they hog the dialog focus. I guess I should have mentioned I wasn't 100% sure with this. However, I will note, on my 2.4 GHz Intel Celeron, it has been nearly impossible for me to multitask when running a plugin (they're too CPU intensive) -- and OpenGL wouldn't be feisable for me either because I don't have a high-end graphics card. That said, most people who would use this kind of plugin, I'd assume, wouldn't use this kind of low-end system anyways (if I want to wrap an image around an object, I'll use POV-Ray and raytrace it anyways; so there is no such thing as a real-time preview to me regardless of rendering method, and I know how to use POV-Ray). If that's truely the case, then the plug-in approach on this tool seems doomed anyway. There is not much sense if you need to call the plug-in from a menu everytime you changed the texture somewhat. I don't see why I can't float the plug-in's menu and keep clicking the button though. I still wonder how you're gonna export the data to OpenGL, and what happens if something goes wrong. How will you handle OpenGL's settings, etc... so maybe moving this elsewhere is an idea. What about as a seperate utility? [e.g. Use a filename with e.g. a png or xcf file and load, then open a window with a preview, setting OpenGL settings and the image's filename in it -- when I want an update, I'll save my image in GIMP, and click a button in the app which will update the preview.] Good luck with your project, should you continue to persue it. -- ~Mike - Just my two cents - No man is an island, and no man is unable. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Script-Fu Script Progress
Hi, I've been experimenting with writing Script-Fu scripts in Gimp 2.2.27 on Debian Linux. The particular script I'm working on is based on a script that rotoscopes a selection on single frame, except that it has been modified to use glob to find a list of files, and select-by-color to select the area to rotoscope, as well as to go into the Xtns menu as opposed to the Image-Script-Fu menu. [I also remember reading about the menu reorganization in CVS, and when that version comes out and I upgrade, I will try and update the script as necessary.] Anyways, when running the script, it takes a while, and I notice that at the bottom of the Script-Fu dialogue for that script (and many others) there is a Script Progress indicator that lists the current command being executed and the percentage display for any plugins that run. What I'm wondering is if there is any function that allows me to display a percentage back to the user using that percentage bar when it's not in use by a plugin, because the script does take a while to run. I'm aware of the gimp-message output functions, but I find these aren't feisable when simply reporting the percentage complete to the user (me). In particular, I simply wish to report which frame is complete, for example if I'm rotoscoping using the glob image???.png and the glob returns 180 files, and I work on all of them and I'm keeping count, I want to be able to report I'm done e.g. file 20 of 180 as a percentage on the bar and/or through a status line [preferably either the former or both as opposed to just the latter]. I would greatly appreciate any feedback, including a reference to any documentation. -- ~Mike - Just my two cents - No man is an island, and no man is unable. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp-cvs on msys/mingw
On 7/5/05, Tor Lillqvist [EMAIL PROTECTED] wrote: lode leroy writes: ftruncate is not present in my version of mingw, so I changed it to make it compile. Why don't you upgrade to a more recent version then? (Or have they dropped their inline ftruncate() implementation in unistd.h from bleeding-edge versions?) MinGW/MSYS comes in about 20 or so different packages, which can be confusing to install. Did you install everything binary from MSYS/MinGW? If not, then we might have to go figure out which MinGW/MSYS components are prequesites to installing The GIMP. -- ~Mike ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Layer locking proposal
On 6/27/05, Sven Neumann [EMAIL PROTECTED] wrote: Hi, Simon Budig [EMAIL PROTECTED] writes: A way to overcome this is to have e.g. two lines per layer. A sample mockup is available at http://www.home.unix-ag.org/simon/files/layer-dialog-many-properties.png This might work from a user's point of view but I am afraid that it will be a nightmare to implement. There's absolutely no support from GTK+ for this kind of UI. Probably even for good reasons. So you can't do something like a two boxes with columns, in a box, and then have a list of those boxes? Something like the way Java Swing does GUIs? [I'm sorry, but I have no idea how GTK+ works, so it's just my two cents.] I don't suppose this would be something to ask the GTK-Development team about how to implement, would it? [Similar to how we're discussing how to implement this here.] -- ~Mike ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp-cvs on msys/mingw
On 6/28/05, Manish Singh [EMAIL PROTECTED] wrote:
Changing stuff outside of gimp should be considered last resort.
which is still not perfect: I modified python.m4 to replace \es by /es:
[am_cv_python_pythondir=`$PYTHON -c from distutils import sysconfig;
print
sysconfig.get_python_lib(0,0,prefix='$PYTHON_PREFIX').replace('\\','/')
2/dev/
null ||
Why is this needed at all? gimp doesn't use $pythondir anywhere.
-Yosh
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
I don't know, but maybe this has something to do with python-fu or
whatever it is [scripting in The GIMP with Python, as opposed to e.g.
Perl or Script-Fu]. IIRC, some info about Python-Fu building on Win32
just came through the gimp-devel list, so... *shrugs*
--
~Mike
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
