Re: [Gimp-developer] Building GIMP plugins on Windows using msdev compiler/linker ...
On Sun, Oct 26, 2008 at 11:12:02AM -0400, [EMAIL PROTECTED] wrote: Cygwin as a tools environment on win32 is fine. The mozilla project uses a similar setup and it works nicely. Tor mentions a couple of others. Please don't spread misinformation. Mozilla switched to MSYS from cygwin for Firefox 3.x years ago, because cygwin sucked. The issue is not the tools, but the compiler/linker. When building on win32, you want to identify this is the case and pick up a 'standard' compiler - usually msdev, so that you build against the standard runtime, select appropriate compile/linker flags and don't end up with Cygwin dependencies. Whether moving your entire build system to a cross platform build solution is easy or not, remains to be seen. It is certainly possible - evidence - the mozilla build system. As said before, Mozilla doesn't use cygwin anymore. And the rest of the build system is considered a horrible pile of unwieldly crap, but would take several man-months to redo, so nothing gets done about it. Regarding volunteering. No, thanks. No-one enjoys this work. It is tedious and dull. Way too busy, anyway. Sorry. Then you admit it's not as easy as you claim. So far all your criticisms are invalidated because you don't have your facts straight. -Yosh ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Testing
Testing list posting -Yosh ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Add PF_OPTION...
On Mon, Mar 17, 2008 at 07:19:13AM -0500, jbaker wrote: Was wondering if it would be OK if I added an enhancement request on bugzilla for a PF_OPTION control in gimp-python that is the equivalent of SF_OPTION... ? Seems reasonable to me. Request with patch to implement it is even better (though not required). :) -Yosh ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GSOC 2008 mentors list deadline
On Mon, Mar 10, 2008 at 10:21:52AM -0300, Joao S. O. Bueno wrote: We have no offcial mentors yet, but for Pippin for GEGL, Udi for UFRaw, Yosh and me (I am not even sure if Yosh would pick it), for gimp-python. Yeah, I'm cool with mentoring. -Yosh ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] scripting problems
On Mon, Feb 18, 2008 at 01:27:36PM -0800, Al Niessner wrote: Dang! I tried pdb.gimp-quit() like in script-fu and it, of course, did not work. I then browsed http://developer.gimp.org/api/2.0/index.html looking for a quit or some type of control over gimp and did not see anything. Not sure why you expected pdb.gimp-quit() to work, - isn't a valid character in symbol names in python. That gets parsed as: pdb.gimp - quit() Or subtract the result of calling the function 'quit' from the value of 'pdb.gimp' As Sven said, pdb.gimp_quit(0) works, as well as pdb[gimp-quit](0) Personally, pdb.gimp_quit(0) makes just as much sense as gimp.exit() as long as it noted somewhere. I've just added gimp.exit() to SVN. It takes an optional boolean for force, and defaults to False. -Yosh ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] python api leak
On Thu, Aug 16, 2007 at 08:25:17PM +1000, Campbell Barton wrote:
was looking at the gimps python API, svn - gimp-pdb.c:311
GimpParam *
pygimp_param_from_tuple(PyObject *args, const GimpParamDef *ptype, int
nparams)
{
PyObject *tuple, *item, *r, *g, *b, *x, *y, *w, *h;
GimpParam *ret;
int i, j, len;
gint32 *i32a; gint16 *i16a; guint8 *i8a; gdouble *fa; gchar **sa;
if (nparams == 0)
tuple = PyTuple_New(0);
else if (!PyTuple_Check(args) nparams == 1)
tuple = Py_BuildValue((O), args);
else {
Py_INCREF(args);
tuple = args;
}
if (!PyTuple_Check(tuple)) {
PyErr_SetString(PyExc_TypeError, wrong type of parameter);
return NULL;
}
if (PyTuple_Size(tuple) != nparams) {
PyErr_SetString(PyExc_TypeError, wrong number of parameters);
return NULL;
}
--- snip
Notice that tuple is always created, but error values dont free, I think
both return NULL;'s need a Py_DECREF(tuple); before them.
Thanks for noticing, you are indeed correct. This is now fixed in SVN.
Next time, filing a bug in bugzilla with a patch for these obvious sorts
of things would be much preferred.
-Yosh
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] about carol
On Thu, Jun 21, 2007 at 05:29:15PM +, Daniel Pisano wrote: Hence my motivation to speak out in this thread. And I have no more to say about this matter, since all that I could do, I have done. I haven't read all the postings in this thread yet, as this week is busy for me, but I have to say that your posting about this is extremely hypocritical, as *your* tendency to blather on ridiculously, especially on IRC, as driven people from the project as well. Perhaps you should seek help for your mental illness yourself before talking about others. I'll comment on the rest of this thread later, since the other postings aren't by disturbed hypocrites and merit constructive responses. -Yosh ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Rudeness on gimp devel and bugzilla - was:?Re: Tools
On Fri, Mar 23, 2007 at 09:42:03AM +0200, Shlomi Fish wrote: Well, you're somewhat right. But other projects do not seem to have a problem finding developers. Inkscape has them. Subversion has many of them. While the hackerdom level of the open source people has decreased somewhat, we still have many potential B.Sc./B.A/B.E. graduates who contribute to FOSS who can program in C on Unix. Or there are many enthusiastic high school or undergraduate students who learn a free Unix clone on their own, and can do enough programming. So not all are bad. Many projects are propsepering because they can find many developers. Granted, a lot of them are easier to program for than the GIMP, but most of them are also demanding. As brought up earlier, claiming other projects have significantly more developers is simply untrue. Please stop spreading FUD. It would be helpful if you read prior parts of the thread before replying. -Yosh ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Rudeness on gimp devel and bugzilla
On Wed, Mar 21, 2007 at 08:00:42AM +0100, Martin Nordholts wrote: Though, Inkscape I think seems to have succeeded better than both GIMP and Krita (attatching new and prettier script version) Yeah, but not by much. The point being, pretty much all free software projects could use more contributors, and I don't think perceived rudeness is the primary cause of this. The Linux kernel folks are far ruder than anything that's happened on this list, but the number of contributors is in the thousands. -Yosh ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gfig
On Wed, Mar 07, 2007 at 03:35:03AM +0100, Claus Cyrny wrote: Hi Sven, Sven Neumann wrote: [ ... ] I don't think however that the gfig plug-in has anything to do with this. It does insofar, as it binds unnecessary develop- er resources. I have been using the Gimp now for several years, but I'm beginning to ask myself where the priorities for the developers are. Wouldn't, say, 16-/32-bit be more important than a small vector graphics program that is so difficult to handle? Of course there's no direct connection between 'gfig' and the text tool; it's just a matter on how to spend developer resources. You assumption that significant developer resources go into maintaining gfig is simply false. That's why everyone else is confused. -Yosh ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [GIMP] Suggestion to simplify user interaction
On Fri, Oct 20, 2006 at 02:24:48AM +0200, Omar wrote: Omar a ?crit : Alexandre Prokoudine a ?crit : On 10/20/06, gg wrote: On Thu, 19 Oct 2006 17:35:19 +0200, Sven Neumann wrote: all other toolkits that have tear-off menus 'still interested to know what all the other toolkits are. Qt OpenMotif :) And it's not just unix stuff, Microsoft Office has had them for a while too. IIRC they do have a tooltip for the -- bit. -Yosh ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Are @gimp.org aliases needed at all?
On Wed, Sep 27, 2006 at 08:36:09PM +0200, Sven Neumann wrote: Hi, On Wed, 2006-09-27 at 13:07 +0200, Dave Neary wrote: So another idea is to persuade Shawn to move everything gimp.org to another server (perhaps somewhere in gnome.org/RedHat's colo to take advantage of their sysadmin team?), update the DNS records and move on with our lives with new sysadmins. Come on, nobody wants this. Before we can even ask Yosh for revoking someone's email address, we need to agree on rules about the use of the gimp.org aliases. That's what I would like us to talk about now. Everything else seems very counterproductive to me. I think policing it at all is silly. Back in the day, we even gave out @gimp.org aliases as contest prizes, and monitoring that usage is impractical. I don't get where the expectation that postings from gimp.org addresses should be considered as anything but the individual expression of the author. Expecting a volunteer organization to have a rigid public face is ridiculous. One really should evaluate emails on the actual *content*, and not what the From address says. There are several active contributors who do not use gimp.org addresses, assuming their comments should have less weight is rather rude. Can we please stop cluttering the development mailing list with this now? -Yosh ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: requesting a change in the defaults
On Fri, Sep 22, 2006 at 11:03:48AM +0200, Alex Fernandez wrote: i cannot give any kind of logical reason for it and probably you should do the right thing and trash this suggestion of mine. Yes, it is the usual email pollution. You're guilty of the same. Looking at the archives, you speak up far more often to criticize others than to contribute constructively. Heed your own words and stop being a hypocrite. -Yosh ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] How to install gimp-cvs entirely to my $HOME (Linux)
On Sun, Apr 16, 2006 at 08:10:54PM +0200, Zephyr wrote: Hello, I wanted to compile My Very Own GIMP From CVS (TM) and play with the code, explore it etc. As it should be just my playground, I don't want to install it system-wide and possibly endanger my stable GIMP 2.2.10 installed from RPM. So I made directory (my $HOME is /home/zephyr): /home/zephyr/Projects/gimp-cvs where I made CVS checkout. In this directory I created another one : MY-USR-LOCAL and ran ./autogen.sh --prefix=/home/zephyr/Projects/gimp-cvs/MY-USR-LOCAL make make install The configuration and compilation went hapilly, but make install eventually failed: Making install in libgimpconfig make[1]: Entering directory `/home/zephyr/Projects/gimp-cvs/libgimpconfig' make[2]: Entering directory `/home/zephyr/Projects/gimp-cvs/libgimpconfig' test -z /home/zephyr/Projects/gimp-cvs/MY-USR-LOCAL/lib || mkdir -p -- /home/zephyr/Projects/gimp-cvs/MY-USR-LOCAL/lib /bin/sh ../libtool --mode=install /usr/bin/install -c 'libgimpconfig-2.0.la' '/home/zephyr/Projects/gimp-cvs/MY-USR-LOCAL/lib/libgimpconfig-2.0.la' libtool: install: error: cannot install `libgimpconfig-2.0.la' to a directory not ending in /usr/local/lib make[2]: *** [install-libLTLIBRARIES] Error 1 make[2]: Leaving directory `/home/zephyr/Projects/gimp-cvs/libgimpconfig' make[1]: *** [install-am] Error 2 make[1]: Leaving directory `/home/zephyr/Projects/gimp-cvs/libgimpconfig' make: *** [install-recursive] Error 1 The relevant error extracted from this is: libtool: install: error: cannot install `libgimpconfig-2.0.la' to a directory not ending in /usr/local/lib Sounds like you first built without specifying a --prefix. You need to run make clean and then rebuild. -Yosh ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp-Python with no ui? (external script)
On Sat, Apr 01, 2006 at 02:58:12PM +0200, Ministeyr wrote: Manish Singh wrote: By the way, I thought the batch mode only understood scheme, so it would make the whole thing even more complicated. One line of scheme to call your python script won't increase the complexity appreciably. The problem is that if i have huge lists and complex python objects in my external scripts, and i want to access them in the gimp's python-fu script, i have to pass them through scheme, and thus it means converting back and forth. I will try to adapt with pickle if it works. You could serialize them to a temporary file, or choose from a number of IPC methods python ships with. No need to pass stuff like that over the command line. How were you planning on doing it via your original though of having having a gimp_noui anyway? The issues are more or less the same. -Yosh ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp-Python with no ui? (external script)
On Thu, Mar 30, 2006 at 07:59:08PM +0200, Ministeyr wrote: Just write a pygimp script normally, and call it via gimp's batch mode. -Yosh I would prefer another solution, since I have some processing to do in the external script and possibly a bunch of data to transfer back and forth, so it would make the script quite complex to have to use the batch interpreter. Why would it? By the way, I thought the batch mode only understood scheme, so it would make the whole thing even more complicated. One line of scheme to call your python script won't increase the complexity appreciably. I hope there is a simpler solution possible. Well, it's kind of hacky yes, but it's not *complex*. If you want something better, why don't you contribute it? -Yosh ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] python plugin dos not receives changes to FLOATARRAY parameters done by libgimp functions.
On Wed, Mar 15, 2006 at 01:43:12AM +0100, Kleistereimer wrote: how to use gimp_path_get_points from a python plugin? here some samplecode: def somefunc(image): floatarray = [] for i in range(100): floatarray.append(0.0) closed = 0 count = 0 gimp.pdb.gimp_path_get_points(image, path1, 1, closed, count, floatarray) return floatarray floatarray should be modified by 'gimp_path_get_points' but it's not. how to get this values transfered to the python plugin? No, that's now how things work. This is how you do it: def somefunc(image): path_type, path_closed, num_path_point_details, points_pairs = \ pdb.gimp_path_get_points(image, path1) return points_pairs Return values are returned as return values, which is the python way to do things. It's not like the C API. If you browse the PDB within the python console, when you select a procedure at hit Apply, it will paste a sample of how to call it in to the console entry box. -Yosh ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Photoshop PSD 6 format Spec / Gimp XCF format Spec
On Thu, Mar 02, 2006 at 03:30:03PM +, John Cupitt wrote: Of course, OpenDocument document structure (ZIP archive with multiply files inside) could be followed. Yes, this sounds much more sensible. As a concept, yes. Actually using ZIP is a stupid decision, and I wonder what the rationale for using it was. -Yosh ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Photoshop PSD 6 format Spec / Gimp XCF format Spec
On Thu, Mar 02, 2006 at 08:36:41PM +, Alan Horkan wrote: On Thu, 2 Mar 2006, Manish Singh wrote: On Thu, Mar 02, 2006 at 03:30:03PM +, John Cupitt wrote: Of course, OpenDocument document structure (ZIP archive with multiply files inside) could be followed. Yes, this sounds much more sensible. As a concept, yes. Actually using ZIP is a stupid decision, It is a decision with some trade-offs. I'm surprised you would dimiss it as stupid without knowing more about what problems they were trying to solve, obviously the smallest compression wasn't their only priority. Why do you assume I'm calling it stupid because of compression issues? One thing Zip has that other archive formats don't seem to have is an internal filesystem, and some files inside the zip can be more compressed than others making it a good container format. An index or manifest can be left uncompressed, whereas other files within the archive can be more heavily compressed if desired. One big failure is that the manifest is at the *end* of the file, which makes recovering data from partial files a lot harder. and I wonder what the rationale for using it was. There are more detailed explainations available (I read one very long and detailed report on it when it was first added to OpenOffice) but if you can find the list of requirements they had it should become clear. And this is what I asked about. Thanks for the handwave instead of an actual answer. No need to say unpleasant things about OpenDocument. No need to post emails that don't answer the question I asked about, and instead waste my time with baseless speculation. -Yosh ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Re: [Gimp-user] Problems compiling GIMP
On Sat, Feb 11, 2006 at 03:42:56PM +0100, Axel Wernicke wrote: Am 11.02.2006 um 15:14 schrieb Scott: I am sure I will eventually fix GIMP or come up with a work around, at which point I will forward the info on for your consumption. so, may be we should kick this issue to GIMP-dev and ask for help. May be even a bug should filed for this? Hopefully somebody can bring some light into this. As I told you on IRC, engage the libtool people about it. Unless you feel like donating a decent OS X 10.4 machine to a developer, this isn't going to be fixed by just sitting around and whining for it to happen. You want it fixed, and you're the one who has access to the platform for testing and investigation, so you have to do some legwork. -Yosh ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: color balance (preserve luminosity) bug
On Thu, Dec 22, 2005 at 10:45:56AM +1100, miriam clinton (iriXx) wrote: Alexandre Prokoudine wrote: On 12/21/05, miriam clinton (iriXx) wrote: example images of too much cleaveage for a mailing list kthx. there are women on this list too This is just photogtaphy, not even nu. Nothing too much, really That does not mean that it is pleasant to have to look at. If you want to get your kicks out of pornography, kindly keep it to your bedroom. Consider the other participants on this list - I know I am not the only woman here. I could give you several other reasons why 'not even nu' photography is damaging to both men and women in society and to a woman's self-image. But this is not the place for an essay on anorexia nervosa and the moral decay of society. Oh please. The images in question are so not pornography. You could see people dressed like that in G rated Disney films. This is a mailing list about GIMP development. GIMP is about all sorts of images. Prudish lectures about images have nothing to do with GIMP development. If that's all you can contribute, you don't really belong on this list. As far as I'm concerned, even images with nudity are fine here, so long as there's some artistic merit. Giving URLs to images instead of attaching them is preferred however. This is the final word on this subject. I don't want to see any more posts from you, Miriam, regarding this. -Yosh ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP 2.3.4
On Wed, Sep 28, 2005 at 07:56:12AM -0500, Lance Dockins wrote: Sven Neumann wrote: And if you ask, please describe your problems in detail. I have left my crystal ball at home today so I really can't figure out what some missing key libraries at the end of the build are. I was asking more generic questions because I was looking for more generic answers. I just wanted to know if missing DLL's was a normal scenario in Win32 environments. Since you clearly know that it's not, you've jumped ahead of me to asking which DLL's were missing. Since I don't know (I didn't write them all down) I'll have to tell you next time I compile. Instead, I offered all the information I had. As far as your crystal ball comment, I'd say that was a bit uncalled for. You could have just as easily asked for more information without being biting and sarcastic. You, Sven, of all people should know that flipant biting sarcasm is a great way to discourage people from taking up GIMP or otherwise contributing to it. What if someone considering the possibility of contributing to GIMP read that post? They probably would think twice at that point for fear of being publicly humiliated for asking a question. Don't get me wrong, I greatly respect your contributions to GIMP and I'm sure it's frustrating answering all of these types of questions. In fact, I know so. My greatest strength is customer service, sales, and otherwise dealing with people so I know how difficult it can be. Let me just put it this way. The ONLY reason people are using or contributing to GIMP is because they have problems. Specifically, they have a need for an image design program that's both powerful and inexpensive and GIMP meets that need. I'm having COMPILE problems WITH GIMP. There's really no difference. People use software, ask questions, etc because they have problems. How you handle those problems WILL determine the success of the project - particularly if you have such an influential position with the project. Do you think an open source project is better served by having primary developers handhold everyone that comes along through basic problem solving skills, or using that time to implement new features or fix bugs? Keeping track of what you did is a rather basic step when diagnosing problems with software. There is a certain comptency level assumed when you try to build GIMP. You didn't live up to it, so don't whine about the resultant response (which really wasn't that bad, although terse). It's also pretty rude to make blanket statements about the motivations of contributors. You don't speak for everyone. -Yosh ___ 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 Wed, Aug 24, 2005 at 12:58:35PM -0400, woc wrote: On 8/24/05, michael chang [EMAIL PROTECTED] wrote: 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. So it takes a second or two to convert an image using perl. Longer if it's a format varient where pixels adjacent visually aren't stored adjacent to each other, or some of those format variants. This costs what, a few minutes out of a day? Anyone using this image format is going to have to spend considerably longer than that just to load it into the environment which uses these images. Speed is not one of my priorities. Simplicity is. You can use Perl or Python to write a file format plugin. Script-fu is a nonstarter, there's no way to register a load/save handler from a script (though there could be in the future). Script-fu sucks for this for other reasons, as others have told you already. You can actually do things with reasonable efficiency in both Perl and Python, since you get the pixel region abstraction just as you do in C. There's a save plugin example that comes with both the Perl and Python bindings. -Yosh ___ 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 Wed, Aug 24, 2005 at 01:49:50PM -0400, woc wrote: On 8/24/05, Manish Singh [EMAIL PROTECTED] wrote: You can use Perl or Python to write a file format plugin. Script-fu is a nonstarter, there's no way to register a load/save handler from a script (though there could be in the future). Script-fu sucks for this for other reasons, as others have told you already. You can actually do things with reasonable efficiency in both Perl and Python, since you get the pixel region abstraction just as you do in C. There's a save plugin example that comes with both the Perl and Python bindings. Hmm... in my opinion C is more portable than perl or python, in the context of the gimp. If the standard gimp distribution contained those bindings, I'd probably think differently. Well, the python bindings are disted with GIMP, though not on Windows. This will change with GIMP 2.4 though. If you care about Windows, you should've said so from the beginning. ;) You're basically stuck with C for 2.2, script-fu won't cut it. -Yosh ___ 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 Wed, Aug 24, 2005 at 02:34:28PM -0400, woc wrote: On 8/24/05, Manish Singh [EMAIL PROTECTED] wrote: Well, the python bindings are disted with GIMP, though not on Windows. This will change with GIMP 2.4 though. If you care about Windows, you should've said so from the beginning. ;) You're basically stuck with C for 2.2, script-fu won't cut it. ... and I was almost sure I mentioned that portability is a priority for me. I apologize for failng to ennumerate the current and potential future platforms I might hope to let people use. /wry 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. Oh well, looks like C it is, with all the non-portability that implies. I was hoping for more generic abstractions. You could patch script-fu to do what you want, or you could deploy pygimp or gimp-perl to your users, since they are running a custom app anyway... It's up to you how much you want to constrain yourself. -Yosh ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp swap file
On Wed, Jul 20, 2005 at 09:20:29PM -0400, Andrei Simion wrote: Hi, Sven Neumann wrote: Hi, Andrei Simion [EMAIL PROTECTED] writes: You are deleting the images, aren't you? No, in all tutorials I read they return the image to be saved at the end of the main method in the script. So you are creating images and you never delete them. And it surprises you that you are using up the available memory?? The situation is like this: I return the image at the end of the script. I tried to save the image, you can see this from the example I sent, but that method call doesn't work, I got an error. Could you please let me know what is wrong with the gimp_file_save call (it is currently commented out)? If I return the image, I cannot delete it prior to returning and this is why I try to save it from inside the script. Please have a look in the code I sent you and let me know what is wrong. You have to convert the image to indexed mode before saving it as gif. Next time, send the script as an attachment instead of inline, so the mailer doesn't mangle it. -Yosh ___ 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 Wed, Jun 29, 2005 at 09:02:54AM +0200, lode leroy wrote:
the autodetection of python on MSYS is not too good:
the \es need to be replaced with /es, so I added this to
Where did it screw up? You sure you are using a CVS snapshot with all
the relevant changes? The ChangeLog should have:
MSYS (especially sh.exe) needs / instead of \ in the paths.
Printing paths from python (in pythondev.m4 and
/usr/share/aclocal-1.9/python.m4)
Yes, and the configure script should take care of this. This is why I
asked for confirmation that you have all the stuff needed for this to
work (which you did not answer).
C:\Python24\lib\site-packages\site-customize.py
Changing stuff outside of gimp should be considered last resort.
I do not see an alternative: /usr/share/aclocal-1.9/python.m4 is not part
of gimp,
but is used via aclocal...
Except the stuff you changed isn't used in the build...
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.
this particular test is used to detect the LDFLAGS to link pygimp against
libpython
But $pythondir isn't used in LDFLAGS. $PYLINK_LIBS is used, and the
backslash to forward slash transformation is performed on this.
If you're having to make changes to these files, it sounds like you're
not using current enough sources.
-Yosh
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Debian Sid issue] Failed to compile the CVS
On Sat, Jun 25, 2005 at 12:30:02PM +, Jean-Luc Coulon (f5ibh) wrote: Some symbols (including save_d) are missing in the latest update of aalib Yes, the debian maintainer made a bogus change: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=315606 Downgrade aalib for now. -Yosh ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [EMAIL PROTECTED]: Re: [Gimp-developer] FAQ
On Sun, Jun 19, 2005 at 08:48:33AM +0800, Leon Brooks wrote: On Sunday 19 June 2005 01:46, [EMAIL PROTECTED] wrote: I need to compile the list of things that bother me about the GTK+ file chooser and submit it to bugzilla someday. I know I'm not the only one being bothered with it's design. Agree. But I'm not sure that changing the existing GTK dialog as such would be as useful as offering user-configurable alternatives, which is why I spoke of a zero overhead shim. Using such and compiling GIMP would by default result in binaries identical to the current ones, but you could use it to (at compile time) invoke alternatives in some places, one of which could concievably be a (no longer quite zero overhead, you'd have to at least bounce each call through a table) run-time choice of default GTK, alternate GTK or Qt-through-wrapper. You're basing your idea on an assumption that is wrong. GIMP doesn't simply call a set of functions to display open and save dialogs. It derives a new object type from GtkFileChooseDialog and implements extended functionality that way. So a wrapper for the Qt dialog would have to implement a full GObject type, and wrap most of GtkWidget's functionality, which is not a small task. It's certainly possible, but it'd be a maintainence nightmare. -Yosh ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Google Summer of Code - urgent
On Mon, Jun 13, 2005 at 10:31:37AM +0200, Dave Neary wrote: mentor someone on the shapes tool, we need a mentor for the plug-in system. There is a related resource distribution project for gDesklets in the bounties already - some coordination might be possible. I can do that. Anyone doing that will need to talk to be about the server side of things anyway. -Yosh ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Proposing projects for the Summer of Code
On Fri, Jun 03, 2005 at 09:18:21AM +0200, Dave Neary wrote: Hi Jay, Jay Cox a ?crit : On Thu, 2005-06-02 at 18:41 +0200, Dave Neary wrote: - Work on a framework to make plug-in settings saveable across sessions (this might be done now, is it?) Persistent parasites can easily be used for this. Parasites are not the ideal solution and I'm not sure how many plugins use them. Parasites are not an ideal solution for this. You would idieally want a GimpPluginSettings object which you can then save/load with gimp_plugin_settings_save|load(). The storage should be a file, or part of the existing gimprc file (given RML's talk on many small files, this might be better). Persistent parasites have a problem - either they're per session or per (image|drawable). If they're per session, then the next time you start up all your plug-ins have reverted to their defaults. If they're per image, then you have to change your defaults for each application. There are also persistent parasites that can be attached to the app. This is how the png plugin stores its default settings currently. They are backed by gimpdir/parasiterc. The main point to bear in mind is that this should be trivial for a plug-in author. The most convenient way would be to handle it transparently, but I can't think of a way that doesn't involve larger infastructure changes. The hard part is a simple API that handles portable data serialization. -Yosh ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Proposing projects for the Summer of Code
On Fri, Jun 03, 2005 at 10:17:55AM +0200, Dave Neary wrote: Hi, Manish Singh a ?crit : There are also persistent parasites that can be attached to the app. This is how the png plugin stores its default settings currently. They are backed by gimpdir/parasiterc. Jay pointed this out too. Thanks for the info. The main point to bear in mind is that this should be trivial for a plug-in author. The most convenient way would be to handle it transparently, but I can't think of a way that doesn't involve larger infastructure changes. It's a 3 month project, infrastructure changes are possible :) Well, my thinking was a GimpPlugIn class, which a plugin derives from. The class implements the basic GUI itself, and UI elements are tied directly to PDB arguments. This sort of API shakeup is probably something that should happen along with GEGL integration, and would require a fair amount of discussion to nail the details down. So I dunno if that sort of job falls in the scope of the Google thing. The hard part is a simple API that handles portable data serialization. We have that, don't we? At least, that was my understanding of the gimprc objects. IIRC, gimpconfig needs an object that implements the GimpConfig interface, so it's not exactly *simple*. -Yosh ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp swap file increase
On Tue, Apr 19, 2005 at 06:11:26PM -0400, Andrei Simion wrote: Hi, Sven Neumann wrote: GIMP 1.2 is not any longer supported (for quite a while already). Your best bet is to update to GIMP 2.2. That will also give you the benefit that you don't any longer need to run an X server with it. The problem is that 2.2 doen't work with Red Hat and we cannot change the OS. We can upgrade the GIMP to the version 2.0. Is it OK? Is 2.0 enough advanced to get rid of the problem with the swap file? 2.2 works with Red Hat just fine. So I don't know what the issue is. Just use 2.2. -Yosh ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp swap file increase
On Tue, Apr 19, 2005 at 06:35:42PM -0400, Andrei Simion wrote: Manish Singh wrote: On Tue, Apr 19, 2005 at 06:11:26PM -0400, Andrei Simion wrote: Hi, Sven Neumann wrote: GIMP 1.2 is not any longer supported (for quite a while already). Your best bet is to update to GIMP 2.2. That will also give you the benefit that you don't any longer need to run an X server with it. The problem is that 2.2 doen't work with Red Hat and we cannot change the OS. We can upgrade the GIMP to the version 2.0. Is it OK? Is 2.0 enough advanced to get rid of the problem with the swap file? 2.2 works with Red Hat just fine. So I don't know what the issue is. Just use 2.2. At gimp.org they don't have downloads for 2.2. If you say it works, this is good. But why they don't say the same on the web site. If you're looking for binaries, Fedora Core 3 is listed, which would be a Red Hat. You can build from source on any Linux distro though. -Yosh ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp swap file increase
On Tue, Apr 19, 2005 at 08:57:49PM -0400, Andrei Simion wrote: Michael Schumacher wrote: Andrei Simion wrote: At gimp.org they don't have downloads for 2.2. If you say it works, this is good. But why they don't say the same on the web site. If you're looking for binaries, Fedora Core 3 is listed, which would be a Red Hat. You can build from source on any Linux distro though. It's not me the one who decides. If they haven't built and tested the 2.2 on the older versions of Red Hat, then this solution is not acceptable for us. Who are the they you are talking about? Just in case you didn't notice, there are no binaries on gimp.org, all the links point to external sites. No one from gimp.org explicitely tests GIMP on any platform, except that the developers run it on their own platforms, of course. I haven't downloaded anything from gimp.org so I didn't know the binaries come from other entities. I haven't intended to be disrespectful; if so, please accept my apologies. But let's go back to my problem. There's a swap file increase every time I run a Perl script that creates an image on the GIMP 1.2. I tried to delete the image at the end of my script, just to see if the swap file stops increasing. The result was negative. I cannot change the OS on the server (I have other services running) and everything should be tested. I have to stick on Red Hat. So build 2.2 on whatever Red Hat distro you use. There is no reason 2.2 should not work on it. The question is whether you have encountered such a problem (swap file increase). There aren't any known problems like this in 2.2. There are in 1.2, along with hundreds of other problems. -Yosh ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP fails to compile without C++ compiler?
On Sun, Feb 27, 2005 at 01:56:16AM +0100, Daniel Egger wrote: On 27.02.2005, at 01:19, Sven Neumann wrote: just curious, is it expected that configuration of a GIMP build will fail if configure cannot find a C++ compiler? That question would better be asked on the autoconf list. While you are on it, ask them why there are checks for a fortran compiler. I don't think we ask for any of those. It's a difference whether useless checks take place and are ignored or the compiler bails out on something that isn't needed at all. FWIW I haven't seen any other project using autoconf as well fail on this machine because there wasn't a C++ compiler installed so I assume that the GIMP (or maybe the GNOME stuff?) is doing something different or even wrong. You're making a bad assumption then. Any app which uses libtool 1.5 has this issue, as a trivial web search will reveal. There's really nothing we can do, short of updating to a post 1.5 libtool when the libtool maintainers actually release one. -Yosh ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Makefile fix for srcdir != objdir
On Sun, Feb 27, 2005 at 12:44:47AM +0100, Daniel Egger wrote: On 26.02.2005, at 23:44, Sven Neumann wrote: What's wrong with $(top_builddir)? Ho hum. That's a relative path as well, so instead of -I.. that would be -I$(top_builddir)/app which gets expanded to -I../../app . We could do that but I don't really see the big advantage instead of just using my originally proposed patch. We should do -I$(top_builddir)/app. This avoids needing to care about how deep the directory is, in case the directory is moved elsewhere. -Yosh ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Makefile fix for srcdir != objdir
On Sun, Feb 27, 2005 at 01:53:37AM +0100, Daniel Egger wrote: On 27.02.2005, at 01:14, Sven Neumann wrote: We would probably have to add this to all Makefile.am in the app subdirs then?! Only to those containing sources which refer to automatically generated headers, about 3 or 4. No, we should add it to all of them. In fact, it already *is* in some of them. The tarball can be built w/o these tools and we don't want it to depend on them. So it would be wrong to move these checks into configure. Our english is actually rather carefully chosen... So what do I have to do to make the sources self-contained? ./autogen.sh on one system, make dist it, and unpack and build from your disted tarball for the rest of your builds. Or just do your due diligence and be consistent about all your dependencies on the targets you build on. -Yosh ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Makefile fix for srcdir != objdir
On Sun, Feb 27, 2005 at 03:07:01AM +0100, Daniel Egger wrote: On 27.02.2005, at 02:50, Manish Singh wrote: We should do -I$(top_builddir)/app. This avoids needing to care about how deep the directory is, in case the directory is moved elsewhere. But that's still not the cure for all possible problems that may arise by moving the header (e.g. from app to libfoo). Anyway, that's better than nothing... There's no getting around updating the Makefile.am for that. With your naive solution, it *adds* a reason. -Yosh ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp-remote
On Mon, Feb 07, 2005 at 02:51:00AM +0100, Sven Neumann wrote: Hi, [EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) writes: Would you mind to explain what sort of problems that would be? If we mozilla ./file = file not acesssible (permission denied, other user, inaccessible dir) = file not accessible (different machine) = file not acesssible (different filesystem view) Assuming that a process has exactly the same view of the filesystem as any other is in general not true. Comparing hostnames helps somewhat in the first case. I see the point. But it would be trivial to take care of this, wouldn't it? The remote protocol would have to check if the instance of gimp that is already running on the current X server is a local process or not. Did I miss something obvious? I think the behavior should be as follows: By default, gimp should try to connect to a running instance, but *only* if it's on the same machine and running as the same user. gimp --remote (or if argv[0] == gimp-remote) should always attempt to connect to a running instance, and honor the args that the current gimp-remote has. And gimp --new-instance always starts a new instance. The default in absence of a command line argument should be controlled by an environment variable, for people with uncommon setups (like, differing filesystem views). That should make everyone happy. -Yosh ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CVS HEAD dependency on glib-2.6 / gtk+-2.6
On Sat, Feb 05, 2005 at 02:49:43PM -0500, Robert L Krawitz wrote: From: Sven Neumann [EMAIL PROTECTED] Date: Sat, 05 Feb 2005 18:36:29 +0100 Robert L Krawitz [EMAIL PROTECTED] writes: There could be plenty of other reasons why, of course. But it isn't FUD for people to report that they're having problems compiling and running GTK 2.6 against a particular distribution. Multiple people reporting the same thing suggests there's an issue, but doesn't pinpoint where it is. I am only asking that you show us what problems exactly you have when building gtk+, so that we can help you to solve them. Saying that there are a lot of problems doesn't help at all and is what I would consider spreading FUD. We are trying to move GIMP development along and we will need to use GTK+-2.6 to make this happen. So it should be our goal to make sure that all developers update glib and gtk+. Telling them that this update will cause problems, but not saying what problems these are, doesn't help anyone. It's been a while since I tried it (when GIMP 2.2 came out), so I don't remember for certain what happened. It may have even been something getting confused about /usr vs. /usr/local (in which case it wouldn't be a GTK problem at all), but I honestly don't remember. Fairly likely. Mixing libraries and headers in system paths often leads to trouble. There's always the option of sticking things into non-system dirs (e.g., $HOME/devel) using ./configure --prefix, and setting PATH, LD_LIBRARY_PATH, and PKG_CONFIG_PATH. On several machines I use, I stick the HEAD versions of glib, gtk+ etc., along with HEAD gimp there. Doing this makes it much harder to do whatever catastrophic screwups people do that messes up their working system. One can install the new gtk+ just for gimp and be fine. -Yosh ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: [Gimp-user] Re: [Gimp-announce] 2.2 splash screen competition
On Tue, Nov 30, 2004 at 11:11:21AM +0100, Sven Neumann wrote: Hi, David Neary [EMAIL PROTECTED] writes: If this could be done today, that would be a great solution (imho). I wouldn't wait for this to happen if I was you. The news system hasn't been resurrected for several months so I am pretty sure that the contest section has a similar unsolveable problem. We should use what's available but sorry, the mailing-lists won't work. The news was fixed last night. The contest will be worked on soon. Please take the current contest down. It should be on www.gimp.org. It seems that few people learned from the mistakes of the last contest. Once again, it is slashdotted. The framework on wgo was designed to handle that load. Wikis aren't. Why did nobody wait for any real input? (remember, there was a holiday weekend in the US that just finished). This is shameful. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.2 splash screen competition
On Tue, Nov 30, 2004 at 08:01:20PM +0100, David Neary wrote: Hi, Manish Singh wrote: The news was fixed last night. The contest will be worked on soon. In case you hadn't noticed, we're due a release next week. How soon is soon? Today. Please take the current contest down. It should be on www.gimp.org. No. It seems that few people learned from the mistakes of the last contest. Once again, it is slashdotted. The framework on wgo was designed to handle that load. Wikis aren't. It'll do, it's better than nothing. No, it won't do. Why did nobody wait for any real input? (remember, there was a holiday weekend in the US that just finished). This is shameful. I didn't know. I'm an Irishman living in France - how am I supposed to know about USA holidays? Cause they are mentioned in gimp forums, just like european holidays are (and respected). You *are* expected to know about timezones, and at least wait till Pacific Standard Time for comments. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.2 splash screen competition
On Tue, Nov 30, 2004 at 08:37:00PM +0100, David Neary wrote: Hi, Manish Singh wrote: On Tue, Nov 30, 2004 at 08:01:20PM +0100, David Neary wrote: In case you hadn't noticed, we're due a release next week. How soon is soon? Today. If you want to do the work of changing all the places that things have been said now, be my guest. Let me know, I'll blog the new location. Otherwise, the wiki will do for the week. It's not like we're going to get hundreds of entries. Sure. I'll also demphasize the current wiki bit. Why did nobody wait for any real input? (remember, there was a holiday weekend in the US that just finished). This is shameful. I didn't know. I'm an Irishman living in France - how am I supposed to know about USA holidays? Cause they are mentioned in gimp forums, just like european holidays are (and respected). Were you expecting us to wait for some comments from *you* specifically before starting something? You *are* expected to know about timezones, and at least wait till Pacific Standard Time for comments. The initial (wrong) announcement was last evening at 19h CET, 11h PST which certainly gave you enough time to comment before we had to sort something out. Carol responded to it. You asked if anyone had time. Sven replied not to wait, as the news system hasn't been resurrected for several months when it in fact had been the night before. (nobody bothers to check these things). This was all said in the wee hours of the morning here. It couldn't wait 12 hours? -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.2 splash screen competition
On Tue, Nov 30, 2004 at 09:04:04PM +0100, David Neary wrote: Hi, Manish Singh wrote: On Tue, Nov 30, 2004 at 08:37:00PM +0100, David Neary wrote: If you want to do the work of changing all the places that things have been said now, be my guest. Let me know, I'll blog the new location. Otherwise, the wiki will do for the week. It's not like we're going to get hundreds of entries. Sure. I'll also demphasize the current wiki bit. Don't forget to migrate all of the images that have already been submitted from the wiki. Yeah. Some have already been dropped on the floor though. This was all said in the wee hours of the morning here. It couldn't wait 12 hours? Given that (unfortunately) I had already made an announcement, since (unfortunately) this thing got left to the last minute and there was no time left to wait for some kind of group approval, it was important that we put something in place today. The contest is only going to run for 6 days. Waiting until tomorrow or Thursday was unacceptable. And announcement could've been made stating the rules and criteria, but the submission mechanism could've been finalized later. That's what's happening anyway... The gnome.org people dont' seem to be too happy about what's happened either. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] comparing gimp speed
On Sat, Nov 13, 2004 at 12:15:22PM +0530, Laxminarayan Kamath wrote: Manish Singh [EMAIL PROTECTED] to Daniel, Sven, gimp-developer On Fri, Nov 12, 2004 at 06:08:17PM +0100, Daniel Egger wrote: ... t's a whole bunch of contortions, and all pointless since amd64 hardware is competitively priced these days. please dont concentrate only on those who can change pcs like shirts, concentrate on us poor people too. ;) Poor people can't afford 4 GB of ram either, so the point is moot. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] comparing gimp speed
On Fri, Nov 12, 2004 at 08:11:54PM +0100, Daniel Egger wrote: On 12.11.2004, at 18:51, Manish Singh wrote: You can, but not using the typical APIs. This is pretty important for database stuff Whose use case is very different than GIMP's. And you do use the typical APIs, but the user does have to setup the shmfs on their own. And then you have to select between the shm segments yourself. shm is a special case. I'm talking about allocating highmem segments. So, what is the userspace API for this? -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp GUI
On Sun, Oct 24, 2004 at 12:12:46PM -0700, miriam clinton (iriXx) wrote: thanks Sven and Carol for your answers... I'll get back to you with more details about the GUI, as i'm working on an art project at the moment, but to answer some immediate queries: - I'm using Photoshop 7.0 - strangely enough, I find it, and all the other tools I use, highly intuitive - the essence of a tool that a graphic designer can use is its intuitiveness, rather than usability. That's you. There are others who find photoshop highly unintuitive, and GIMP much easier to use. Part of the problem is that many designers started out using photoshop, so the intuitiveness is not necessarily inherent in the application, but a mental byproduct of cultivating your nascent workflow using a specific app. This doesn't really validate photoshop's interface as good, but rather what photoshop trained designers are used to. Merely copying photoshop blindly is a bad idea, since photoshop's interface has got its own weird quirks. Nevermind the interface differences between photoshop on Mac and on Windows. So things really should be taken on a case by case basis. In some cases, photoshop may be better at some things, but in others, completely crack filled. Perhaps in this case we should use graphic designers as testers, alongside bug-testers? Do not discount the graphic designers who actually prefer gimp's interface to photoshop's. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Extending GPConfig (was: Should the checkerboard be linked to the window or to the image?)
On Thu, Sep 02, 2004 at 08:08:23PM +0200, Michael Natterer wrote:
struct _GPConfig
{
guint32 version;
guint32 tile_width;
guint32 tile_height;
gint32 shm_ID;
gdouble gamma;
gint8install_cmap;
gint8show_tool_tips;
gint32 min_colors;
gint32 gdisp_ID;
gchar *app_name;
gchar *wm_class;
gchar *display_name;
gint32 monitor_number;
};
I see two options:
- using the place gdouble gamma uses.
- using the two unused bytes after gint8 show_tool_tips.
I'd suggest we do both and change the struct to:
struct _GPConfig
{
guint32 version;
guint32 tile_width;
guint32 tile_height;
gint32 shm_ID;
gint8gimp_reserved_1;
gint8gimp_reserved_2;
gint8gimp_reserved_3;
gint8gimp_reserved_4;
gint8gimp_reserved_5;
gint8gimp_reserved_6;
gint8gimp_reserved_7;
gint8gimp_reserved_8;
gint8install_cmap;
gint8show_tool_tips;
gint8gimp_reserved_9;
gint8gimp_reserved_10;
gint32 min_colors;
gint32 gdisp_ID;
gchar *app_name;
gchar *wm_class;
gchar *display_name;
gint32 monitor_number;
};
Which should be binary compatible on all platforms.
Sounds good, and gimp_gamma should return 1.0 always (and be marked as
deprecated).
-Yosh
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp plugin and gdb?
On Fri, Jul 23, 2004 at 06:15:03PM +1200, Joseph Heled wrote: While starting each plugin as a separate process has it's advantages, gdb interaction is certainly not one of them. For example, right now I bring the plugin dialog up, then look up in the process list for it, and attach it to the gdb session. Is there an easier way? But the real problem is that by the time the plugin dialog is up lots of interesting stuff has already happened. So, how can I debug run() itself in a reasonable way? (I can think of several ugly hacks to make run() stop and wait until I attach to it, but I still hope there is something I overlooked and there is a simple solution for that). Check out the developer FAQ: http://developer.gimp.org/faq.html#id2778982 So yes, you overlooked some key things. ;) -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp 2.0.1 compilation problem.
On Mon, Jun 07, 2004 at 12:28:07PM -0300, Rodrigo Severo wrote: Hi, I'm having problems compiling Gimp 2.0.1 on my Conectiva Linux 9 machine. The error is: if gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../.. -I../../app -I/usr/local/gtk+/include/gtk-2.0 -I/usr/local/glib/include/glib-2.0 -I/usr/local/glib/lib/glib-2.0/include -I/usr/local/glib/include/glib-2.0 -I/usr/local/glib/lib/glib-2.0/include -I/usr/local/pango/include/pango-1.0 -I/usr/X11R6/include ^^ that's your problem. Your pango is built against the old fontconfig in /usr/X11R6. Hence it gets pulled in. If you built pango against your new fontconfig, you wouldn't have this problem. I think the configure script can be amended to detect this. Sigh, GIMP's configure.in: an encylopedia of how users and distro people can screw up a system. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp-2.1.0 and Python
On Sat, Jun 12, 2004 at 12:18:02PM +1000, Owen wrote: I just built 2.1.0 with --enable-python but there was no python on the menus. So I went and built 2.0.1 --enable-python and configure failed because I didn't have pygtk Installed that and rebuilt both. Python now shows in the menus. Perhaps the configure for 2.1.0 doesn't fail on missing pygtk? The configure check is exactly the same for 2.0.1 and 2.1.0. Are you building 2.1 from CVS? If so, it sounds like your pkg.m4 is broken. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Refactoring code from GPL to LGPL
On Sun, May 23, 2004 at 09:11:49PM +0200, David Neary wrote: Hi, Manish Singh wrote: snip But it's pretty clear that you never bother to do any research before posting. snip You must have some weird sort of logic goes on in your head that made you conflate these things. snip But your postings leave the impression that you do not understand it. Then again, this disjoint thinking is probably one of the reasons there hasn't been much progress on your project. Was there any reason to be this unpleasant, yosh? This thread was long finished, and you certainly didn't contribute anything meaningful to it - wouldn't it have been easier to say nothing than be an asshole? I *did* contribute something meaningful, which you seem to have conveniently snipped out: the fact that clueless Robin completely missed the point that there was plenty of refactoring done into GPL libraries, quite independent of the PDB infastructure. The reason to be so harsh is that Robin keeps on spreading his lies and misinformation about the GIMP project. He completely deserves to be called on his lack of understanding and knowledge, and his complete inexperience with real software development. Dave, ask yourself why you replied to this. The thread was long finished, and *you* certainly didn't contribute anything meaningful to it. And if you must reply to this, don't clutter the list with it further. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Refactoring code from GPL to LGPL
On Sun, May 23, 2004 at 07:19:20PM -0400, Christopher Curtis wrote: Manish Singh wrote: snipped out: the fact that clueless Robin completely missed the point that there was plenty of refactoring done into GPL libraries, quite independent of the PDB infastructure. [...] misinformation about the GIMP project. He completely deserves to be called on his lack of understanding and knowledge, and his complete inexperience with real software development. Hmm ... seeing as most decisions seem to be made on IRC, patches are only accepted if they are attached to bugs in the BTS, and evidently it's some great sin to ask a question here, what exactly IS the purpose of this mailing list? Or is Robin just special? I would imagine that if there are any archives of this mailing list that people can search that the number of flagrantly ignorant questions would go down. Of course, if the list archives convery no knowledge except 'ask not lest ye don asbestos and return none the wiser' that the archives are better off nonexistant. Robin *is* a special idiot. He is Mr. Cinepaint, which is heavily based on the film branch of gimp, from the 1.0 days. For someone who has supposedly been working with the filmgimp codebase for so long, he displays a pretty major lack of understanding of how the code works, and how free software licensing works. He has continually spread lies and misinformation about the GIMP project, in some strange attempt to promote his own project. I suspect it's trying to make a smokescreen to cover up his obvious technical inadequacies and inexperience. If a newbie had asked the same question he did, it would've been fine, and this is the appropriate forum. But Robin is not a newbie: he claims to have been working on the filmgimp code for years. On top of that, he has been badmouthing the GIMP project for years, with no basis, so I'm going to call him on his idiocy. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Refactoring code from GPL to LGPL
On Thu, May 13, 2004 at 12:44:51AM -0700, Robin Rowe wrote: Dave, It seems like you're limiting refactoring to code re-use via extraction to libraries. No, I'm using the same definition that Mat refers to: Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. - Martin Fowler on http://www.refactoring.com/ What I am saying is that moving redundant code out of application space into libraries is a significant component of refactoring. My question was why not being able to do that due to license barriers isn't a significant obstacle to long term GIMP code maintenance. Sven has answered that question. The client-server design of the PDB sidesteps the license issue by exposing functionality in app (which includes the PDB) without linking (instead using sockets). This works for GIMP because no other apps use libgimp as a system library except for GIMP plug-ins, and plug-ins all expect to talk to the GIMP app rather than run independently without it. Actually, you missed the point. There's been plenty of refactoring, and most of the 2.x app code *is* separated into libraries. But it's pretty clear that you never bother to do any research before posting. Also, moving code into a library doesn't mean the license has to be changed to LGPL. It's perfectly valid to have a GPLed library. You must have some weird sort of logic goes on in your head that made you conflate these things. It's very odd that you'd be confused about such basic architectural issues when you've been dealing with the filmgimp codebase for this long. The PDB is a pretty fundamental part of GIMP from way back, and it really hasn't changed. But your postings leave the impression that you do not understand it. Then again, this disjoint thinking is probably one of the reasons there hasn't been much progress on your project. Just leave this criticism be and do not reply. Since you've spread a ton of FUD and lies about GIMP already, do not expect any privleges here. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] PDB requirements (was: PDB named and default parameters)
On Fri, Mar 26, 2004 at 12:06:33PM +0100, Michael Natterer wrote: Manish Singh [EMAIL PROTECTED] writes: On Wed, Mar 24, 2004 at 08:58:39AM -0800, Nathan Carl Summers wrote: On Sun, 21 Mar 2004, Manish Singh wrote: On Sun, Mar 21, 2004 at 09:44:25PM +0100, David Neary wrote: What requirements would the new PDB have? There's a number of issues to be addressed, like GEGL node support, efficiency, UI generation, distributed processing, and macro recording support. Macro recording is already trivial with libpdb: you just connect to the appropriate signal of the Pdb object. Have you given any thought on how to macroize interactive paint functions? By simply passing an array of GimpCoords to the yet-to-be-generated core PDB wrappers, just as all core functions will have to be invoked via these wrappers to make marco recording possible. Well, something has to generate those coords, and something has to update the UI before painting is finished. I was asking more in terms of an API should look like. Interactive paint is more involved than say, a bucket fill, which is easily translated into to call PDB bucket fill function on button release. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] PDB requirements
On Fri, Mar 26, 2004 at 06:53:28PM +0100, Michael Natterer wrote: Manish Singh [EMAIL PROTECTED] writes: Well, something has to generate those coords, and something has to update the UI before painting is finished. I was asking more in terms of an API should look like. Interactive paint is more involved than say, a bucket fill, which is easily translated into to call PDB bucket fill function on button release. IMHO this is not a big issue, since even today PDB painting uses almost the same functions as interactive painting does. The only difference is that PDB painting flushes the stuff at the end while interactive painting flushes while painting. So everything that would have to be changed is replacing the call to gimp_paint_core_interpolate() by some_generated_pdb_paint_foo() and flush the display in between. Not a big deal i'd say. (What I want to say is that painting has been abstracted well enough to enable stroke recording without changing too much). But then you are right, maybe we need a new API because it's perhaps cleaner to just draw the stuff as we do now and to create the recorded entry on button_release() Right, it wouldn't be hard to adapt the code to do this. But we should nail down a sane API... We could simply bypass the pdb for painting, and just emit record this on button release. But maybe it'd be better to have the pdb more involved, I dunno. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: PDB named and default parameters (was Re: [Gimp-developer] The Mark Shuttleworth offer)
On Sat, Mar 27, 2004 at 03:27:04AM +0100, Marc Lehmann wrote: On Thu, Mar 25, 2004 at 07:48:59PM -0800, Manish Singh [EMAIL PROTECTED] wrote: So what would be a good way for perl to support both named and positional stuff? It simply shouldn't. It should either do positional where it is useful and named where it is useful. Or always named. Everything else (like a hashref) is just madness and should be handled by a different interface (call_procedure_hashref...). Please note that it doesn't make _any_ sense to have 100% named parameters for the majority of functions (e.g. all fucntions having an image, or layer etc. as leading arguments, as these should be handled using method syntax). No, but it's nice to be flexible and have the option of doing things with method syntax or procedural syntax. Isn't an important Perl motto TMTOWTDI? :) Perhaps the OO syntax should always expect named parameters, but non-OO syntax should offer both in some fashion, like a hashref, or some sort of marker to say named parameters start here. Most languages share this problem, so it would be interetsing how this would be solved in C for example (probably using a different interface). Python supports positional and named arguments natively, and we've talked about workable solutions in Scheme. In C it's a pain in the ass to call PDB functions at all, so no big deal to have two interfaces. But I'd like to do better in more dynamic languages. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
On Thu, Mar 25, 2004 at 06:20:14PM +0100, Sven Neumann wrote: Dave Neary [EMAIL PROTECTED] writes: - Do a 2.2 release in about three months. I think that's unrealistically short at this stage. There are people who have said that they want to do some concrete and long-standing TODO items, and 6 weeks to 2 months is not enough time to get most of those done and debugged properly. IMHO we should rather try to finish what has started already and get these new features to our users quickly. 2 months should be sufficient to get that done. Whatever cannot be achieved in this time will have to wait for the next release then (which could be by the end of the year). I think so too. We should shore up the app and get it to a decent state before we really land the major new break everything features. One example of something which would definitely miss 2.2 if we release in June is libpdb. libpdb is being developed outside of The GIMP. As soon as it is ready it shouldn't take more than a few days to add it as an optional plug-in API. You cannot replace the current system with it anyway since we don't want to break the plug-in API for 2.x. I don't think libpdb should land in 2.2, since I don't think we'll be able to nail down everything we need in a new PDB api in the timeframe, and it'd be kind of silly to land a brand new core API that'll only live for one release. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: PDB named and default parameters (was Re: [Gimp-developer] The Mark Shuttleworth offer)
On Tue, Mar 23, 2004 at 01:22:23PM +0100, Marc Lehmann wrote: On Fri, Mar 19, 2004 at 02:19:09PM -0800, Manish Singh [EMAIL PROTECTED] wrote: While on that subject, I'm wondering what a good way of representing named parameters in scheme and perl would be. Any thoughts? This is natural, and common: $obj-method (arg1 = value1, arg2 = value2, ...) this, too: $obj-method (-arg1 = value1, -arg2 = value2, ...) as well as this: $obj-method (Arg1 = value1, Arg2 = value2, ...) All of these can be supported at the same time, and the difference between them is often seen as a style difference only. However, there is no way of using the same method both with named parameters or not (unless your resort to other syntaxes like $obj-method (ARG1, value1, ARG2, value2), making ARG1 etc. global or worse). Yeah, that is unfortunate, since the interface should support both named and positional interfaces (and combining the two in one call). Especially with methods with just a single argument, forcing named parameters might not be the best thing (OTOH, you can make a difference between methods with single argument and more, but...). Right now, a few things get autodetected because gimp-perl uses strong typing for the gimp objects (as opposed to e.g. C or scheme). All in all there would be no problem at all supporting named parameters (There is even a certain amount of support for that already in gimp-perl), but it will break existing scripts and make writing scripts slightly more tedious. Well, this would go hand in hand with a plugin api redo, so scripts are gonna break anyway. Personally though, I really want named parameters. Not at all because of me being able to remember arguments better (I think it's actually worse to have to remember the parameter names), but because it allows me to easily leave off arguments that can be defaulted. Most of these arguments, however, are at the end, so even more important than named parameters would IMHO be default values for unspecified ones. I once reworked the PDB code to allow variable number of arguments but left the check in for compatibility with existing plug-ins who expect all or nothing (ignoring the number of arguments actually passed; the API did provide this already). So what would be a good way for perl to support both named and positional stuff? The only way I can think of still is to use a hashref for named parameters. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] PDB requirements (was: PDB named and default parameters)
On Wed, Mar 24, 2004 at 08:58:39AM -0800, Nathan Carl Summers wrote: On Sun, 21 Mar 2004, Manish Singh wrote: On Sun, Mar 21, 2004 at 09:44:25PM +0100, David Neary wrote: What requirements would the new PDB have? There's a number of issues to be addressed, like GEGL node support, efficiency, UI generation, distributed processing, and macro recording support. Macro recording is already trivial with libpdb: you just connect to the appropriate signal of the Pdb object. Have you given any thought on how to macroize interactive paint functions? Distributed processing will soon be supported by libpdb using the WireSocket backend; this will be done by early May. Implementing WireSocket is one of the group projects chosen by some of the students in a class I am taking, so it will be done if they want a good grade. :) Heh. Maybe local UNIX sockets are faster than pipes. Would be good to benchmark. UI generation is mostly out of the scope of libpdb. I would have to know more what is specifically meant by UI generation before I could comment on it. Generate a UI from a PDB entry. Like a generalized -fu that the scripting languages currently have. This makes an easy way of generating property panes for nodes in a graph say, made out of PDB nodes. Efficiency has yet to be addressed by libpdb, although some easy optimizations have been put in place. Serious optimization should probably wait until the feature requirements are more in place and reasonable profiling can be done. Yeah. For macro recording things should to go through the PDB in the app itself, so the within process boundary case things should be lightweight and fast. GEGL node support opens a big can of worms, and there probably is no best solution. The first big decision to make is whether plug-ins should be written as GEGL nodes objects directly, or whether there should be a shim GEGL node that translates the operations into procedural calls not unlike those in the traditional GIMP api. If we do use a translating shim, Libpdb seems like a good fit for this as well. Yes, that's undetermined. It seems like a real shame to lose GIMP's ability to run plug-ins out of process, so my vote is we rule out dynamically loading gegl nodes using GPlugIn as the only method, although we may want to be able to do it as an additional extra-fast method. CORBA seems like a flexible choice here if we decide to make plug-ins implemented directly as gegl nodes. Although my guess is it would add somewhat more overhead than a hand-rolled gimp-specific method, it has the advantage of being more flexible than anything we could do, and also it would be something maintained by an outside group instead of another burden for us. I dunno. CORBA is pretty heavyweight, there isn't an ORB out there that does things efficiently. If we do decide to have plug-ins be native GeglNodes, I recommend that we still have a PDB for scripting purposes. A node has inputs and outputs, and so do PDB functions, so there isn't much difference there. I've thought about doing a proxy GObject framework, which would allow IPC of arbitrary objects, but I haven't fleshed it out in my mind yet. One thing I've thought about would be to use the object and type system features, like every PDB function is an object, with properties for parameters. A paramspec has everything we need: type, name, descriptions, defaults, possible bounds. Maybe something like a PDB function is an object, you set properties on it, then run the execute method. Also have a print method for a textual representation. Then just instantiate and string together these objects, and run through then. Sort of like CellRenderers in GtkTreeView. This might be a complete and total abuse of the object system tho, and not scale at all. I might do a quicky implementation and see. Using paramspecs somehow is tempting though. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] PDB Named Parameters
On Sun, Mar 21, 2004 at 09:55:36PM +0200, [EMAIL PROTECTED] wrote: Great. Now, when you say it I remember Sven mentioning it in the past. But I guess that this new interface is not exported yet to any of the language bindings? Is that correct? Any plans when this API will become active? It's not actually used in any GIMP code yet, and it's not been discussed how well it fits in with GIMP's needs going forward. So there aren't really any concrete plans yet. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: PDB named and default parameters (was Re: [Gimp-developer] The Mark Shuttleworth offer)
On Sat, Mar 20, 2004 at 12:39:23AM -0600, Kevin Myers wrote: It is utterly ridiculous that simply because I voiced concerns about and would like for the ability to have gimp scripts execute properly from the command line under Windows that you accuse me of making the GIMP suck. The suggestions that I offered earlier this evening were only thrown out for consideration, and I didn't try to force those down anyone's throat. All that I asked was that GIMP developers try to give adequate consideration to the needs of Windows based gimp users rather than selecting an implementation that I was worried might have an adverse impact. FWIW, the suggestion was ill-researched. (foo image=bar) is so very very un-Scheme like, which is surprising to hear from someone who has apparently written scripts from scratch. It pays to be versed in the language you're dealing with. Some bias towards Linux and other Unix based systems is completely understandable and acceptable to everyone. We all appreciate the deficiencies of Windows and its poor record of adhering to standards (though there are *many* similar examples in the *nix world as well). We also appreciate that the Linux community is making the biggest share of contributions to the GIMP development effort. What I don't appreciate, is your apparent lack of sympathy towards users who have *no* choice but to run under Windows (for any of numerous reasons) and who simply desire to use the gimp (just as you claim to), and to help enhance it to meet *their* needs, just as you enhance it to meet your own needs under Linux. The gimp is an open source product, and is also supported and developed by Windows users, not just *nix heads. So what gives you the right to presume that only *nix developers can own and control the GIMP (as your comments seem to imply), and to ignore the needs of Windows based users and the feedback and proposals of Windows based contributors? Except there are a number of ways already to workaround the deficiencies of the windows shell. Even if --batch - is broken, you could always save a script out to a file, put it in the scripts dir, and call it from the command line. I'm not saying at all that has happened in this specific instance regarding the issues that I raised earlier this evening and the subsequent discussion. What I am saying Carol, is that some of you appear to be having a rather knee jerk reaction against someone else who is merely trying to help the GIMP better support the operating system that they are using, no different than anyone else who might happen to be using some other OS. If the approach that I suggested won't work or will cause real problems under another OS, that's fine. But what isn't fine is to say in essence we don't care about Windows users and contributors, and we're not going to listen to their input, which is basically what I got out of your reply. It's also better to research your suggestions a little, so that they don't sound completely out there, thereby reinforcing the viewpoint that Windows users are clueless. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: PDB named and default parameters (was Re: [Gimp-developer] TheMark Shuttleworth offer)
On Sun, Mar 21, 2004 at 10:01:26PM +0200, [EMAIL PROTECTED] wrote: One of the ideas that I believe Sven raised on irc, was that there should be a minimal and trivial interface to the PDB that is not based on any particular language but just consists of: gimp_foo -bar 3 -baz yellow Well, we ship a scheme engine already, so writing and including yet another syntax parser seems kind of silly. Having such an interface to the PDB has several advantages: 1. It would take care of the quoting problems from the shell. E.g. gimp -nodisplay -cmd my_logo -text foo -bg_color yellow \ -cmd save_image -img 1 -filename foo.png There's still quoting problems for strings with spaces in them, parsing arbitrary colors, etc. 2. We could easily do recording and save into this format. Recording into scheme syntax is pretty easy. 3. The format could easily be translated into script-fu, python, guile, etc. No translation needed for script-fu (and probably not guile either), and python, perl, etc. already have many implementations of lispy type syntax parsers, which is nicer than writing a whole new one. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: PDB named and default parameters (was Re: [Gimp-developer] The Mark Shuttleworth offer)
On Sun, Mar 21, 2004 at 09:44:25PM +0100, David Neary wrote: Hi, Manish Singh wrote: A PDB revamp is planned. How far along is the planning? I have heard of Rock's libpdb, which I believe he wants to finish for 2.2, but I hadn't heard any concrete plans for the often-mentioned forthcoming PDB re-write. There hasn't been any real planning, other than planning to do some planning after 2.0 is out. All I was saying is that we haven't forgot about it. What requirements would the new PDB have? Not clear yet. I don't think we should really touch the PDB for 2.2, if we want to do a short release cycle for that. There's a number of issues to be addressed, like GEGL node support, efficiency, UI generation, distributed processing, and macro recording support. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: PDB named and default parameters (was Re: [Gimp-developer] The Mark Shuttleworth offer)
On Sun, Mar 21, 2004 at 03:32:08PM -0600, Kevin Myers wrote: - Original Message - From: Manish Singh [EMAIL PROTECTED] Sent: Sunday, March 21, 2004 2:48 PM snip FWIW, the suggestion was ill-researched. (foo image=bar) is so very very un-Scheme like, which is surprising to hear from someone who has apparently written scripts from scratch. It pays to be versed in the language you're dealing with. I stand appropriately chastised. However, in my defense, I don't write script-fu every day (in fact haven't tried to write any in almost a year now, primarily due to the command line execution issues that I mentioned). Seems like Carol could have simply said that my propsal was too un-scheme-like (as Kelly did), and left it at that. I readily admitted in my opening statements *before* offering the suggestion that it might not be applicable. Would've been better to do some research before posting at all. Except there are a number of ways already to workaround the deficiencies of the windows shell. Even if --batch - is broken, you could always save a script out to a file, put it in the scripts dir, and call it from the command line. Yosh, you say that there are a number of ways to work around the Windows shell limitations, and maybe there are, but up to this point nobody proposed one that would work in my scenario. And several folks who are much more knowledgeable about the gimp and script-fu than I am participated in the previous discussion. A number of possible suggestions were made, but all failed for one reason or another. If the approach that you are suggesting now would work, then that's great, but we all simply missed it before, and I guarantee you that Sven and Tor and the other folks who were involved in those prior discussions are not ignorant. It's just that this solution is not particularly obvious or straight-forward or elegant or easy to use. Let's make sure that I'm interpreting your suggestion correctly. Is it as follows: Write a second script that calls my original script, and embed the necessary parameter values in the new script? If that is correct, then yes, I might be able to write a Windows batch file that would take my command line options and write out the necessary line(s) to the new script file, then execute the new script file. And, I appreciate your suggestion. I just wish that this had come up a year ago when I was trying to get this to work. Still, wouldn't you agree that the requirement for this level of workaround under Windows is somewhat undesirable, even given a reasonable level of Linux bias? Well, first see if gimp --batch - works. If it does, then I don't think that's too much of a big deal to do instead of command line parameters. If it doesn't, then it should be fixed. But yes, you interpreted my suggestion accurately. It's also better to research your suggestions a little, so that they don't sound completely out there, thereby reinforcing the viewpoint that Windows users are clueless. Yes, admittedly that is true whenever possible. However, sometimes when you are extremely busy with other tasks and don't have an opportunity to do the desired level of research, it is better to raise a possibly false alarm than it is to let a potential issue go by unnoticed. That seems especially true regarding Windows related issues, since most of the gimp contributors are Linux based, and might accidentally overlook something that could have an adverse effect on Windows usage. Doesn't that seem reasonable? If it's important to you, you'll do the 10 mins of research and critical thinking needed. You raised your issue about quoting problems, but then you had time to follow up with a completely out there suggestion. So the too busy argument doesn't really fly. It's not like we're planning on making any changes related to this near term, so I don't see the urgency. Finally, wouldn't you also agree that it is better to be polite when rejecting someone else's well intentioned suggestions, than to respond in the extremely arrogant and insulting manner of Carol's replies to the newsgroup? Well, you brought up windows vs. *nix, when the issue is how Scheme works. Perhaps you should've tried to understand the problem better. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: PDB named and default parameters (was Re: [Gimp-developer] The Mark Shuttleworth offer)
On Sun, Mar 21, 2004 at 05:57:04PM -0600, Kevin Myers wrote: If it's important to you, you'll do the 10 mins of research and critical thinking needed. Apparantly you could research this a whole lot faster than I can, which isn't surprising since you work with gimp development almost every day. It would probably take me more than that amount of time just to track down a valid link to the docs for the version of Scheme that the gimp actually uses, much less try to interpret it. There isn't anything gimp specific. It's straight Scheme. The issue is that you didn't even bother to *try*. Show some respect by doing attempting a little research. Even if you don't get it, that's ok, but you should try. You raised your issue about quoting problems, but then you had time to follow up with a completely out there suggestion. So the too busy argument doesn't really fly. You have *no* idea. I've been putting in 18+ hour days for months on end, trying to keep my company above water. I posted these suggestions (and this note) in the down time while I am waiting for my computer to complete other tasks. Same downtime could've been used for some research. It's not like we're planning on making any changes related to this near term, so I don't see the urgency. The only urgency is this: I try to respond to things when I see them, when the potential for an issue occurs to me and while the topic is fresh on my mind. If I try to wait until later, then two bad things happen: 1) a lot of issues would get dropped, and more importantly 2) if I bring it up later then folks would claim that it was too late to change things and say why didn't you bring up your concerns sooner when this issue was being discussed? You said it was an important issue. If it's really important, you wouldn't forget it. Also, it's clear that we're getting ready to put out a new stable release, after which there will be plenty of architecture dicussions when it'll be more relevant. Finally, wouldn't you also agree that it is better to be polite when rejecting someone else's well intentioned suggestions, than to respond in the extremely arrogant and insulting manner of Carol's replies to the newsgroup? Well, you brought up windows vs. *nix, when the issue is how Scheme works. As mentioned, my concern was the command line syntax issue. I don't know all of the Scheme syntax rules. While I was writing my script with Scheme, I found it to be a very arcane language, with very little documentation available, *especially* for the apparantly outdated or non-standard version that the gimp seems to use. So, I thought that I should leave it up to the experts to decide whether my concerns or suggestions were valid, rather than trying to reach those conclusions on my own based on using either the wrong documentation, or misinterpreting the documentation due to being a neophyte with the language, especially considering the limited time that I had available. But you twisted it into a windows vs. *nix issue, which is what Carol responded to. You really didn't have to do that. A more constructive line of thought is to perhaps enable other language bindings on the command line. Both perl and python work on windows too. Finally, *far* too much time and bandwidth has already been wasted on this discussion for all concerned. If folks could have simply explained that my suggestion wouldn't work, rather than making inflammatory statements, then all of this excessive discussion could have been avoided. I've already decided not to respond to Carol's further emails (even though I would like to defend my position) in order to keep from dragging this out further. I now have some idea of your gripes against my input, and hopefully you now have some idea of why my input was provided in the manner that it was. I doubt that anything further can be accomplished. So, how about if we just drop this now, and give all of the other folks on the list a break? Shouldn't have started with the whole unix bias thing to begin with... But yes, let's drop it. We can discuss language bindings and batch mode in the content of 2.2 and beyond. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
PDB named and default parameters (was Re: [Gimp-developer] The Mark Shuttleworth offer)
On Fri, Mar 19, 2004 at 10:50:23AM +0200, [EMAIL PROTECTED] wrote: On Fri, Mar 19, 2004 at 08:56:36AM +0100, Henrik Brix Andersen wrote: [stuff deleted] The only thing that struck me as missing was the work involved with porting the plug-ins to the new API, but Rapha?l already pointed that out in another reply to this thread. I very much hope that at least this time around, since so much is anyhow changed, the PDB will finally get the face lift and use named parameters instead of positional ones. A PDB revamp is planned. While on that subject, I'm wondering what a good way of representing named parameters in scheme and perl would be. Any thoughts? -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: PDB named and default parameters (was Re: [Gimp-developer] The Mark Shuttleworth offer)
On Sat, Mar 20, 2004 at 12:58:25AM +0100, Simon Budig wrote:
Manish Singh ([EMAIL PROTECTED]) wrote:
On Fri, Mar 19, 2004 at 10:50:23AM +0200, [EMAIL PROTECTED] wrote:
On Fri, Mar 19, 2004 at 08:56:36AM +0100, Henrik Brix Andersen wrote:
[stuff deleted]
The only thing that struck me as missing was the work involved with
porting the plug-ins to the new API, but Rapha?l already pointed that
out in another reply to this thread.
I very much hope that at least this time around, since so much is anyhow
changed, the PDB will finally get the face lift and use named parameters
instead of positional ones.
A PDB revamp is planned.
While on that subject, I'm wondering what a good way of representing
named parameters in scheme and perl would be. Any thoughts?
Hmm, isn't there a perl-way to do named parameters? I bet there is (but
I don't know about it).
After a quick search on google the following seems to be standard:
gimp_perl_foo_bar (-image = image,
-drawable = drawable,
-radius = 5.5,
-size = 300);
Yeah, I thought of that, but I'm not sure how you'd differentiate between
named usage and positional usage.
With both
gimp_perl_foo_bar($image, $drawable, 5.5, 300)
and
gimp_perl_foo_bar(-image = $image, -drawable = $drawable,
-radius = 5.5, -size = 300)
all perl hands the function is a list of values. CGI.pm tries to guess
about this, but it's easily fooled if the actual data string you give it
starts with '-'.
One way to do it would be:
gimp_perl_foo_bar({image = $image, drawable = $drawable,
radius = 5.5, size = 300})
And check if we get a hash reference as our first arg, but that seems
a bit nonobvious.
For scheme we could do something like this:
(script-fu-foo-bar '(imageimage)
'(drawable drawable)
'(radius 5.5)
'(size 300))
or (less clutter)
(script-fu-foo-bar imageimage
drawable drawable
radius 5.5
size 300)
that having said: I don't have much experience with scheme outside
script fu, so there might be a convention out there on how to do named
parameters.
Again there is the problem of differeniating between positional
and named usage.
-Yosh
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: PDB named and default parameters (was Re: [Gimp-developer] The Mark Shuttleworth offer)
On Sat, Mar 20, 2004 at 01:34:02AM +0100, Simon Budig wrote: Manish Singh ([EMAIL PROTECTED]) wrote: On Sat, Mar 20, 2004 at 12:58:25AM +0100, Simon Budig wrote: For scheme we could do something like this: (script-fu-foo-bar '(imageimage) '(drawable drawable) '(radius 5.5) '(size 300)) or (less clutter) (script-fu-foo-bar imageimage drawable drawable radius 5.5 size 300) that having said: I don't have much experience with scheme outside script fu, so there might be a convention out there on how to do named parameters. Again there is the problem of differeniating between positional and named usage. Ok, thinking some more about it: What about using symbols as parameter identifiers? (script-fu-foo-bar 'imageimage 'drawable drawable 'radius 5.5 'size 300) passing symbols to the PDB doesn't make sense, so this could be used to differentiate. That's a good idea. Unless there's some other standard way of handling this in scheme (anyone?) this sounds good to me. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Gimp.app application bundle
On Wed, Mar 17, 2004 at 05:21:04PM -0800, Carol Spears wrote: On Wed, Mar 17, 2004 at 10:26:22AM -0800, Aaron Voisine wrote: I'll add something on the wiki as soon as my Gimp.app source forge project gets accepted and I can put in a link to it. hmm, do we need to add the upload plugin to the wiki? or is not having an acceptance policy on the wiki an issue? The ftp site would be a fine place to host it. Stick it in ftp.gimp.org/incoming and drop a note to [EMAIL PROTECTED] -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] no ppd file usable with gimp2.0pre4?
On Sat, Mar 13, 2004 at 09:11:02PM -0500, Robert L Krawitz wrote: From: Sven Neumann [EMAIL PROTECTED] Date: 14 Mar 2004 02:50:09 +0100 Robert L Krawitz [EMAIL PROTECTED] writes: Fink and Darwinports are simply not options for mainline OS X users. Mac users want to literally buy a machine and turn it on. Think about what happens when you buy a lamp, you plug it into the wall and turn it on. They're amazingly close to that, with things like Airport. From a user engineering standpoint, it's a tour de force. Afak, you can build binary images from darwinport packages with a single command. If you provide such an image file to your users, it's a matter or dragging the file onto the finder and the software is installed, ready to be used. But certainly you know about this and I assume that this is the way you are offering the gimp-print software to MacOS X users. It would be easy to include glib2 as part of this gimp-print image file. That's what I meant; that would be a possibility. We would just need to make sure it didn't collide with anything else. I prefer to minimize the amount of stuff we install in the background, but that could conceivably be an option. Whether it's worthwhile is a second question. Why not just statically link to glib 2 when you make the OS X binary build? Seems that'd solve this whole issue nicely. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Last day for abstracts
On Mon, Feb 16, 2004 at 11:14:30PM +0100, David Neary wrote: Hi, Alan Horkan wrote: On Mon, 16 Feb 2004, Carol Spears wrote: it is going to be a tough act to follow robin rowe and cinepaint. I know you are funny sometimes but we all know Robin reads this list and such comments dont help anyone. Can't we all just get along? I agree with the sentiment, but AFAIK Robin hasn't read this list since yosh de-subscribed him during the Summer after yet another row over the history of FilmGIMP. Just wanted to say that I disagreed with someone abusing their power like that - after all, we're welcome on the Cinepaint lists. Just to clear things up, he wasn't de-subscribed, I turned on his moderation bit since he was posting rather off topic rants. He's the only person I'd had to do this to, which is telling. Robin has a tendency to jump to conclusions with little basis and present them as fact. This is precisely why he got in trouble in the first place. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Misnamed structure element in SFScript structure?
On Mon, Feb 09, 2004 at 08:35:04AM +0100, Marc A. Lehmann wrote: On Sun, Feb 08, 2004 at 07:35:08PM -0800, Manish Singh [EMAIL PROTECTED] wrote: currently, and go beyond that with a full gtk and gimp binding. The same should be done for python (I have plans to do this) and perl, the idea being having languages besides C that can use the entire gimp API. Hmm, at least during the 1.2 era, perl did have access to the full API (i.e. low-level pixel access, full UI transparency etc.), and right now I don't think something important has been added that is not accessible (as opposed to parts that haven't been converted to the new API). I mean, in the sense of you can write plug-ins indistinguishable from plug-ins wirtten in C, this was possible in perl for a long time already. However, very few authors have used these features, and only two perl plug-ins, both written by me, use their own Gtk-UI instead of relying on Gimp::Fu, so I guess the demand for the latter power in perl is pretty low. (I might err and there are lots out there, perl developers have this tendency of doing stuff for themselves without polishing publishing them...) Oh sure, out of all the bindings, perl comes closest by far to full coverage. But iirc it doesn't wrap libgimpcolor, libgimpmath, some of libgimpwidgets, and libgimpthumb. I'd like to see more bindings that let you do everything a C plugin does, so people have language choice when it comes to writing things, which could mean a larger pool of plugin coders. It's also nice to have a quick way of trying out new algorithms. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Misnamed structure element in SFScript structure?
On Mon, Feb 09, 2004 at 11:58:15AM +0100, Sven Neumann wrote: Hi, Manish Singh [EMAIL PROTECTED] writes: Oh sure, out of all the bindings, perl comes closest by far to full coverage. But iirc it doesn't wrap libgimpcolor, libgimpmath, some of libgimpwidgets, and libgimpthumb. We will have to make the libgimp APIs more language binding friendly then. If we made more use of GObject properties, that would probably help. Yeah, there's a bit of work to be done on the libgimp* side too. Not a whole lot though, and certainly doable for 2.2. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Misnamed structure element in SFScript structure?
On Thu, Feb 05, 2004 at 04:14:10PM +0100, Marc A. Lehmann wrote: Simons agruments, however, smell a lot of standard gimp extension language, because his goal is to have one language that is always pat of gimp, which would effectively be a standard. I don't think that's a bad idea at all, especially when we later think of macro recording and other tasks, where we _will_ need some standardized macro language that should be easy to translate into real scripts. Exactly. And scheme is pretty good for that, since it's easy to parse, which makes writing a macro-real program script easy. Running a macro shouldn't need any extra dependencies either. So SIOD is fine for this, unless there is a smaller scheme implementation out there. Use of it for anything beyond simple macro logic should be discouraged. So there is room for a Guile binding which could run stuff that is .scm currently, and go beyond that with a full gtk and gimp binding. The same should be done for python (I have plans to do this) and perl, the idea being having languages besides C that can use the entire gimp API. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [patch]Gimp plug-in template 1.3.2 won't compile
On Sat, Jan 31, 2004 at 11:46:35PM -0500, Kevin Cozens wrote: Greetings. The 1.3.2 of the sample plug-in (gimp-plugin-template) uses some features that are deprecated in the latest CVS version of the GIMP. It is also missing an argument to one function call. The attached patch allows the template plugin to compile. Thanks, but these have already been fixed in gimp-plugin-template CVS for some time already. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Re: Re: Alternative zoom algorithm
On Tue, Jan 20, 2004 at 04:13:19AM +0100, Marc A. Lehmann wrote:
On Tue, Jan 20, 2004 at 02:22:57AM +0100, Simon Budig [EMAIL PROTECTED] wrote:
other parts, and I already had enough with C guts) and is small, it
just fits in place with the old code instead of more deep changes.
True. (These break strict aliasing rules warnings however are harmless
according to Yosh.)
Just a sidenote, unless caused by a bug in the compiler, these warnings
are never harmless. They might not cause problems with current gcc,
but there is no guarentee that the code will do as expected with other
compilers or future versions of gcc, unless one uses -fno-strict-aliasing,
which can be a major performance problem in some cases.
Well, the bulk of the code in gimp that causes warnings is stuff like:
void foo (void **p);
void bar (void)
{
int *i;
foo ((void **) i);
}
While it does break the letter of the law wrt aliasing rules, are there any
assumptions that the compiler can legally make that would cause problems?
-Yosh
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Re: Re: Alternative zoom algorithm
On Tue, Jan 20, 2004 at 02:51:17PM +0100, Marc A. Lehmann wrote:
On Tue, Jan 20, 2004 at 01:24:15AM -0800, Manish Singh [EMAIL PROTECTED] wrote:
Well, the bulk of the code in gimp that causes warnings is stuff like:
void foo (void **p);
void bar (void)
{
int *i;
foo ((void **) i);
}
While it does break the letter of the law wrt aliasing rules, are there any
assumptions that the compiler can legally make that would cause problems?
Well, troubling to me would be the fact that a int is not the same as
a void *, so this very example is a bit strange and could likely cause
problems on 64-bit (or else) architectures, but that is, of course, not
the main point.
You misread. To explain further:
void set_null (void **p)
{
*p = NULL;
}
void foo (void)
{
int *i;
set_null ((void **) i);
}
Which basically sets i = NULL. I don't see how this can be a problem on a
64-bit architectures, since pointers to all types are the same size.
gimp actually only does this with external functions, like:
voidg_object_add_weak_pointer (GObject*object,
gpointer *weak_pointer_location);
or
gboolean g_module_symbol(GModule *module,
const gchar *symbol_name,
gpointer *symbol);
Perhaps the API should be fixed, I dunno.
I don't know the real case this is based on, but I'd wonder what this code
is supposed to do then. Please note that the warning will not happen when
you cast to a void *, since the pointers might alias then.
Sure, I know ways of working it around it. My preferred fix is not to
cast to a void *, but use a temporary void * and assign back, since that
adds some type safety instead of casting.
Legally, the compiler could cache the contents of i in a register before
and after the call, because foo is not allowed to change it's value. (And
I might guess that foo will not do that, but it's equally hard to see this
as a compiler as it is for a human, so the warning is IMnsO justified).
Ah, that answers my question, thanks.
It's unlikely that this will happen with gcc = 3.5, which is, IMHO,
a viable platform to tie oneself to, but there are no guarentees that
this won't happen in more complicated cases, with other (less or more
intelligent) compilers or with future gcc versions.
It's hard to judge from his example, but right now it's difficult for
me to imagine a valid use for the above that couldn't easily be written
correctly.
To repeat it: I am quite certain that the above example will simply work
for quite some time in the future, because of some gcc assumptions about
pointers that are difficult to change but make no good otimized code.
Perl does similar pointer castings and has opted the safe way by simply
using -fno-strict-aliasing to compile itself at all times, after being
bitten once.
That might be easier then going through all the code and fixing it, and
will of course silence the warning. Right now, it doesn't make much of a
difference in generated code with gcc, as it is not very good at taking
advantage of (no-) aliasing yet, but this is a hot area in gcc, since
exploiting aliasing rules allow a great deal of optimizations in typical
numerical code.
Well, one problem is that flagging every violation like this makes people
tend to ignore the warning, which means real problems which affect gcc's
alias analysis *now* are likely to be overlooked, or heavy handed solutions
like -fno-strict-aliasing put in. It'd be much nicer if this warning didn't
trigger for function parameters (except with -pedantic) until gcc was closer
to doing the alias analysis that would manifest a problem.
As it stands, right now the warning mainly confuses people. It doesn't help
that the aliasing rules aren't spelled out anywhere in the gcc docs. I was
actually skeptical that gcc might be buggy in this regard, until I dug up
the appropriate bits of the standard that say what's going on.
-Yosh
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Re: Re: Alternative zoom algorithm
On Tue, Jan 20, 2004 at 02:22:57AM +0100, Simon Budig wrote: [restricting this to gimp-devel, since this is purely technical stuff] GSR - FR ([EMAIL PROTECTED]) wrote: [EMAIL PROTECTED] (2004-01-19 at 1524.44 +0100): [technical discussion :)] I think I already explained why I prefer the set of ratios based on the idea of homogenous zooming. So the rest of this Mail focuses on the technical issues of your patch. The last patch I sent does homogenous zooming, has no more (known) floating issues (I am not gonna bet about floats, what is more, not gonna bet about Gimp either, I saw some warnings about aliasing in other parts, and I already had enough with C guts) and is small, it just fits in place with the old code instead of more deep changes. True. (These break strict aliasing rules warnings however are harmless according to Yosh.) Well, not all are harmless. Just that a lot of them are spurious, but some of them do signify real problems. It's a mess. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: gimpmisc cvs fixes.
On Tue, Jan 13, 2004 at 10:41:46AM +0100, David Odin wrote: Hi, as you may know, the files libgimp/gimpmisc.[ch] have been split into libgimp/gimppixelfetcher.[ch] and libgimp/gimpregioniterator.[ch]. Can you do the necessary changes to keep cvs history for these files? This is something like copying gimpmisc.c,v and gimpmisc.h,v directly on the CVS server. Done. In the future, it's smoother to take care of this before you commit the new files. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Dithering
On Wed, Jan 07, 2004 at 09:43:09PM +0100, Sven Neumann wrote: Hi, David G??mez [EMAIL PROTECTED] writes: I've scanned some jpeg images with a 24bit depth. Some of them are old photographies in blackwhite that show 'bands' when are displayed on a 16 bit depth display. After digging in the menus i noticed that the image could be transformed to a indexed pallete, with a Floyd-Steinberg dithering, but that did not solve nothing, the maximum number of colors cannot be set to more that 256 :-/. Is there another way to dither an image in gimp? Programs like gqview, an image viewer, use the dither algorithms bundled with gdx_pixbuf in gtk2, and they work perfectly with the same images. Why cannot the gimp do the same quality dithering if it's using the same library? The GIMP display canvas uses the dithering routines from GdkRGB which is probably what you are refering to. Of course this does only affect the display, not the image data. I am not sure but I think I remember a plug-in that could apply dithering to RGB images w/o converting to Indexed colors. Actually, gqview defaults to GDK_RGB_DITHER_NORMAL whereas gimp uses GDK_RGB_DITHER_MAX always, which should theoretically do a better job. Maybe you could put up a sample image somewhere so we can see what exactly the problem is? -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP on Mac OS X
On Sat, Jan 03, 2004 at 09:20:56PM +0100, Hans Breuer wrote: Am 27.12.2003 um 09:39 schrieb Manish Singh: I just checked in an POSIX shm tile transport implementation. I'd like someone on OS X to test it, since I'm not 100% sure how POSIX compliant OS X is, but I'm reasonably sure it works. The C code appears to work, but the configure check does not : configure:15715: checking for shm_open in -lrt configure:15746: gcc -o conftest -g -O2 -Wall conftest.c -lrt 5 ld: can't locate file for: -lrt apparently shm_open() is available by libc.dylib - it compiles without any extra lib (checked by simply replacing -lrt with -lc, real fixing configure is definitely out of my scope ;) Figures. POSIX requires shm_open() to be in librt, hence my questioning of OS X's POSIX compliance was not unfounded. ;) I'll check in a fixed configure script shortly. Please test it out. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-web] Re: [Gimp-developer] Status of the New Site
On Tue, Dec 30, 2003 at 11:58:33PM +0100, Branko Collin wrote: On 30 Dec 2003, at 21:47, Rapha?l Quinet wrote: On Tue, 30 Dec 2003 17:18:11 +0100, Branko Collin [EMAIL PROTECTED] wrote: On 30 Dec 2003, at 9:48, Rapha?l Quinet wrote: I think that the goal was to move to a better machine (better CPU and more memory). But for the details, you should probably ask Yosh. I think the goal was to have a new website. If you want to move to a better machine, you don't make a new website. I suppose that Yosh thought that it was the right time to replace the old machine, which shows some signs of weakness from time to time. Anyway, I am just reporting what I read. Don't shoot the messenger. ;-) I am not shooting the messenger, but I also cannot help but notice that you have write access to the current webserver. Yosh reads at least one of these mailing lists, and has done so for the past three months. Barring a disaster, he has had enough time to tell us why things are taking so long. I vote we don't wait for a new server to come along, because flying pigs might bump into it, being disoriented from hell freezing over, and then we would need another new server. Please keep in mind that this is a volunteer effort. Yosh may have had many good reasons to stay silent, but he did not mention it, and his inactivity and silence should not be a reason to halt the work of an entire group of dedicated developers. The reason is simple. There is not enough disk on the old server to host the new site. I'm surprised nobody has taken the time to address some of the issues that were punted for later (lack of a good Basics tutorial comes to mind). Also, with 2.0 coming out somewhat soon, porting things to 2.0 would be a good idea. None of these things require the site to be moved over first. It is not as if people dislike the new site; the only thing that remains is replacing the old site with it. There are voices of dissent. Also the news stuff is still broken since the move away from SSI (which was a bad decision imo, SSI has a negligible server load and apache is really not that hard to set up) -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP on Mac OS X
On Fri, Dec 26, 2003 at 06:59:57PM +0100, Sven Neumann wrote: Porting GTK2 to Quartz could bring some improvements but it isn't a prerequisite for a good user experience of The GIMP on Mac OS X. The one thing that is a lot more important at the moment is to fix bug #102058: http://bugzilla.gnome.org/show_bug.cgi?id=102058 The fact that our shared memory implementation doesn't work on Mac OS X makes our plug-ins run unreasonably slow. This will hurt the user experience a lot more than widgets being drawn by an X11 server which is available, working, supported and fast. So if you think about helping to push GIMP-1.3/2.0 on Mac OS X, you should consider to help us to implement shared memory using mmap or using POSIX shm. I just checked in an POSIX shm tile transport implementation. I'd like someone on OS X to test it, since I'm not 100% sure how POSIX compliant OS X is, but I'm reasonably sure it works. It was rather trivial to do, I'm surprised no OS X user took the initiative to fix this long ago. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gegl-developer] Re: [Gimp-developer] GEGL in GIMP
On Tue, Dec 23, 2003 at 09:35:09AM +0100, Dave Neary wrote: Manish Singh wrote: On Mon, Dec 22, 2003 at 06:15:17PM +0100, David Neary wrote: The point is that as it is, gegl is not a standalone project. But it *is* a standalone project. That's been the intent from the beginning. I don't see how incubation helps it in any way. There are people who have indicated wanting to use it for other projects besides GIMP already. OK - fair enough. It's a standalone project. But we're going to use it, and need it, and from what I recall, calvin was looking for more GIMP input into what it should do. How do you propose we get that kind of communication happenning? Not sure. Something to think about more post-2.0. GTK+ was distributed as part of GIMP until people found out that hey, this is a useful general purpose toolkit. We already know that with GEGL. There weren't any notable positive benefits with keeping GTK+ as part of the GIMP tree. Except that until people noticed that it was a useful general purpose toolkit, it kept getting worked on, with a particular application in mind... I think that being part of the GIMP was enormously beneficial to gtk+. The beneficial part was having GIMP use GTK+. Period. Having it part of the actual source tree didn't really contribute to that benefit much at all, since it would've gotten worked on regardless. In fact, it was a minor hindrance, since GIMP specific stuff like GtkGamma got stuck in the general purpose library, and now the GTK+ folk have to maintain it when it doesn't actually belong. There isn't any point. The problem with dependencies most people have is not downloading and installing tarballs, but rather the mess that is Freetype library incompatibilites and by extension any of the things that directly depend on it. GEGL doesn't depend on any external library GIMP doesn't already need. I'm afraid I didn't follow the logic of this... how is this a counter-argument to having gegl and gimp downloads in the same directory? Note, I'm no longer advocating shipping gegl as part of the GIMP sources - although I see no reason not to do that personally, I can see that most people are against it and don't consider it the thing to do (that said, only 3 people have replied with a preference). You didn't propose having gegl and gimp downloads in the same directory till today. So I don't follow the logic. ;) I don't really mind symlinking the gegl sources into the gimp ftp dir, but that's a fairly minor thing. Most people follow webpage links rather than poking through an ftp site these days, and the download webpage should of course link to gegl. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gegl-developer] Re: [Gimp-developer] GEGL in GIMP
On Tue, Dec 23, 2003 at 09:27:17AM +0100, Dave Neary wrote: Hi, Sven Neumann wrote: What is wrong about depending on GEGL and have people download and compile it separately? GTK+ used to live in the GIMP source tree for historical reasons only. I strongly doubt anyone would have wanted to move it into the GIMP source tree if it was started as a separate project. Why would you want to do this with GEGL now? What's wrong with having gegl sources to download with the latest release on the FTP server, the same way we used to have libaa, libmpg, libpng and all the other stuff we needed? Up until 1.2.x, we used to have gtk+ and glib sources with gimp sources. What was wrong with that? Actually, as far as I can recall, the gtk+ and gimp sources were not in the same directory since before 1.0.0. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gegl-developer] Re: [Gimp-developer] GEGL in GIMP
On Mon, Dec 22, 2003 at 06:15:17PM +0100, David Neary wrote: Not at all. GTK+ lived in the GIMP source tree until it was capable of being a standalone project. Afterwards, its main developers were gimp developers. Unfortunately, several of them followed the path which GTK+ has become to go on to be core GNOME developers and no longer work on the GIMP. The point is that as it is, gegl is not a standalone project. It doesn't seem to me like it is mature enough that if the GIMP went under (say a few more people quit), gegl would not go on to be a standalone graphics library in the way that gtk+ went on to be a standalone toolkit. During the incubation of the project, it needs attention from us in the same way as gtk+ got attention pre-1.0. But it *is* a standalone project. That's been the intent from the beginning. I don't see how incubation helps it in any way. There are people who have indicated wanting to use it for other projects besides GIMP already. GTK+ was distributed as part of GIMP until people found out that hey, this is a useful general purpose toolkit. We already know that with GEGL. There weren't any notable positive benefits with keeping GTK+ as part of the GIMP tree. GEGL is a separate project and it is IMO very important that it doesn't become too GIMP-centric. Having it included in the GIMP tarball will make it appear as part of The GIMP which it isn't supposed to be. What you suggest basically has only disadvantages. Let alone the fact that it will be a nightmare to maintain. I'm not suggesting maintenance. I'm suggesting including milestone releases of gegl in our sources. Or storing them with our release tarballs. Either is good. Basically, releasing them together. Early. Before we use the functionality. So that they get built, and people are aware that gegl is real software, not a mission statement from 3 years ago. I'd like to see this done hand-in-hand with a configure check for gegl, so that we actually do get people downloading and building it. There isn't any point. The problem with dependencies most people have is not downloading and installing tarballs, but rather the mess that is Freetype library incompatibilites and by extension any of the things that directly depend on it. GEGL doesn't depend on any external library GIMP doesn't already need. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Displaying image using GTK
On Sun, Dec 14, 2003 at 05:13:30PM +, Tor Lillqvist wrote: Roger Leigh writes: They both have to implement fork() using Windows calls though, which can never be efficient. (Just rambling here:) I wonder, could the typical fork() immeditaly followed by exec() (in the child process) be somehow detected by Cygwin/MSYS, avoiding the need for emulating the full fork() semantics in this typical case? That's what vfork() is for, though maybe bash can't use it because of subshells, etc. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Here Be Bounties
On Sun, Dec 14, 2003 at 05:41:59PM -0200, Joao S. O. Bueno wrote: Since it talks specifically about GIMP python, which me, by chance, was trying for the very first time in gimp 1.3 (no kidding --- I've been on gimp 1.2 with my python fu stuff so far), it is interesting to mention that as of now gimpImage neither gimp.pdb.gimp_image_new seens to be working. Therefore it is currently impossible to create a new gimp image from python. I am posting it here instead of bugzilla just to check if I am missing something obvious. What exactly are you seeing? It works fine here. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Here Be Bounties
On Sun, Dec 14, 2003 at 09:24:54PM -0200, Joao S. O. Bueno wrote: On Sunday 14 December 2003 18:36, Manish Singh wrote: On Sun, Dec 14, 2003 at 05:41:59PM -0200, Joao S. O. Bueno wrote: Since it talks specifically about GIMP python, which me, by chance, was trying for the very first time in gimp 1.3 (no kidding --- I've been on gimp 1.2 with my python fu stuff so far), it is interesting to mention that as of now gimpImage neither gimp.pdb.gimp_image_new seens to be working. Therefore it is currently impossible to create a new gimp image from python. I am posting it here instead of bugzilla just to check if I am missing something obvious. What exactly are you seeing? It works fine here. I just tried to create a new Image from the python console,a nd got this: b=gimp.Image (1, 640, 480) Traceback (most recent call last): File console, line 1, in ? error: could not create image Try b = gimp.Image(640, 480, RGB) I'm not sure where you got the 1, idea from, it's not like this in pygimp 1.2 either. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: [Gimp-announce] ANNOUNCE: gimp-plugin-template 1.3.2
On Tue, Dec 02, 2003 at 04:09:04PM +, Thierry Vignaud wrote: Sven Neumann [EMAIL PROTECTED] writes: standard libray versioning scheme is to set soname to libname.major (library being named libname.major.minor on filesystem) Don't get confused by the numbers, libgimp-2.0 is the library name we've choosen. There is nothing wrong with that. It's just a name. if the a branch of a library is not compatible with the previous one, maintainer only has to bump its major. nothing more. That's exactly what we are doing. Nothing more. Please have a look at the versioning scheme I pointed you at. It does exactly what you are suggesting. but it makes packaging harder for distros. both debian and mandrake (and even redhat now due to gtk+-1.2 to gtk+-2.x transition) use versionned packages for library (eg one can install libfoo2-1.0.1 and libfoo3-1.1.9 at the same time) this system works great for quite a number of libraries. but for libraries that include their version number into their soname, this makes packaging harder when one want to still be able to keep several versions of the same library. This is what GTK+ does. libgtk-1.2.so.0 and libgtk-x11-2.0.so.0. GIMP does the same thing as GTK+. since the major is not anymore unique (eg gimp-2.0.23 will provide libgimp-2.0.so.23 with the same major as libgimp-1.3.so.23 from gimp-1.3.23), we've to include version number into package name too. No, you misunderstand. GIMP 2.0.0 will provide libgimp-2.0.so.0.0.0. GIMP 2.0.23 will provide libgimp-2.0.so.0.0.23. ABI will be maintained for the the 2.0.x series (and possibly the 2.x series, if we decide to do that). There are no ABI guarantees for 1.3.x since it's a development series. As Sven said, we do break it. It is a development series, so you just have to deal. When it hits 2.0, that's a stable series, and the ABI will be maintained. Note that GTK+ 1.3.x bumped the major so number at every release too. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: [Gimp-announce] ANNOUNCE: gimp-plugin-template 1.3.2
On Tue, Dec 02, 2003 at 11:30:26PM +0100, Marc A. Lehmann wrote: On Tue, Dec 02, 2003 at 01:25:24PM -0800, Manish Singh [EMAIL PROTECTED] wrote: since the major is not anymore unique (eg gimp-2.0.23 will provide libgimp-2.0.so.23 with the same major as libgimp-1.3.so.23 from gimp-1.3.23), we've to include version number into package name too. No, you misunderstand. GIMP 2.0.0 will provide libgimp-2.0.so.0.0.0. GIMP 2.0.23 will provide libgimp-2.0.so.0.0.23. ABI will be maintained for the the 2.0.x series (and possibly the 2.x series, if we decide to do that). hmm, I don't think both of you are talking about the same thing, as I think both of you are right, but you are talking past each other. No, I think I answered the question, since the original poster brought up a number of libraries that do the same foo-X.Y.so.Z as doing the right thing. The point is, according to custom packaging rules: libgimp-1.3.so.23 = libgimp23 libgimp-2.0.so.0.0.23 = libgimp23 (debian, mandrake.. linux in general). Gimp uses a major of 0 all the time, and thus it's useless to distinguish between major numbers, you need to include the version number (that is, not the library version number but the version string encoded in the _name_, or stem), and, while this is correct, it's a hassle, somewhat more difficult to use etc. Of course, it's perfectly doable. the question is what the benefits are, I mean, you usually get some benefits while sacrificing others. And since the normal way to manage libraries is both established and does solve the problems, it's hard to explain why a second, incompatible (but of course perfectly working) scheme is required or useful. I simply suspect that this has crept in because it's the only portable way to get it right (e.g. on windows, which doesn't have a de-factor workign dll versioning system, although dlls do come with versions). So, the gimp scheme works anywhere where you can have long enough filenames (== everywhere), while the usual ELF-way only works on platforms where encoding the major at the end is established practise. As such, the benefit might be less hassle and less platform specific code. That is enough to justify it, to me, but if it's the case one should acknowledge it and simply tell people: if you want to fixed, write the patch and get it into the neccessary packages... OK, the main reason is that while the so major number solves things for running binaries compiled against different library versions, it doesn't address *building* binaries against different library versions in the same prefix. So if there was a libgimp.so.1 for 1.x and libgimp.so.2 for 2.x, the compile time linker only looks at a libgimp.so, which can be symlinked to one or the other, but not both at the same time. So if a user wants both a build environment for 1.2 and 2.0 installed, he'll have to jump through extra hoops to get it to work. Hence the different sonames. Another reason, which admittedly solves what can be termed as an annoyance, is that many users simply don't get that the so version numbers don't necessarily match the actual version of the software. Look at the people who think they have Freetype version 6 just because the so major num is 6 (current version is 2.1.7). This means more round trips and confusion when dealing with bugs. So what are the real downsides here? pkg-config deals with the library names, so that isn't really an issue. Packagers have to put version numbers in their package names, but that enables a useful feature of parallel installation, so it's good to have. It causes *less* confusion with users since libgimp-2.0.so.0 is obviously a gimp 2.0 library, as opposed to libgimp.so.47. Note that GTK+ 1.3.x bumped the major so number at every release too. Again, others do it, is not a sound argument... Yeah, but the original poster implied in his mail that GTK+ was doing the right thing by him. I was pointing out the GTK+ does the same thing as GIMP, so if he thinks it's right, then GIMP is right too. ;) -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GimpCon 2004
On Thu, Nov 20, 2003 at 03:11:03PM -0800, Carol Spears wrote: lets take a different approach. when you don't have the money to pay for the flight to represent the gimp at a conference or whatever the event, you won't be volunteering. i was unable to fund a flight to las vegas to represent TheGIMP; i tried to make myself available to dsrogers to help with one. i thought it was very nice that he had the money to get himself there and did not worry with little facts like that he doesn't know that much about TheGIMP and what have you. i also tried to do some things locally to see that I might be able to fund myself enough to pay for the flight to las vegas to represent TheGIMP for a crowd, large or small. to find out that 1) the trip was funded and 2) dsrogers went without a plan of what he would say or do there. i am simply unable to explain more than this. so here is a new question. what qualified dsrogers to attend this gimp event? To clear things up, O'Reilly only paid for the hotel, and that's only after it was made clear to them that nobody would come to represent GIMP unless hotel was covered. What qualified dsrogers was that he lives close enough to Vegas to drive there in a reasonable amount of time, precisely because there weren't funds for airfare. They also didn't even provide computer hardware. It didn't really seem like they allocated a whole lot of funds in general, or really think that there actually are still major free software projects that don't have corporate backing. Chalk it up to them doing something new at the last minute I guess. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] [Fwd: binaries available from the Cooperative Bug Isolation Project]
Forwarding due to list troubles... -Yosh - Forwarded message from Ben Liblit [EMAIL PROTECTED] - From: Ben Liblit [EMAIL PROTECTED] Subject: binaries available from the Cooperative Bug Isolation Project Date: Mon, 20 Oct 2003 18:09:29 -0700 To: [EMAIL PROTECTED] User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 The Cooperative Bug Isolation Project is a research effort at UC Berkeley and Stanford that is exploring novel ways to track down bugs using automated, lightweight feedback from actual user runs. Our suite of instrumented applications includes The GIMP 1.3.21, with Red Hat Linux 9 RPMs ready for download. http://www.cs.berkeley.edu/~liblit/sampler/ http://developers.slashdot.org/article.pl?sid=03/10/09/1446240 http://news.com.com/2100-7344-5092919.html The more users we get, the more data we get. And the more data we get, the better information we can provide back to you about how The GIMP behaves (or misbehaves) in the real world. Toward that end, would you like to add a link to our project from The GIMP's download page? Perhaps something like the following could be added to either http://www.gimp.org/download.html or http://www.gimp.org/devel_ver.html: pa href=http://www.cs.berkeley.edu/~liblit/sampler/downloads/;Specially instrumented builds/a for Red Hat Linux 9 are available from a href=http://www.cs.berkeley.edu/~liblit/sampler/;the Cooperative Bug Isolation Project/a. These builds send feedback that may help us find and fix bugs even faster./p Let me know what you think, or if you have any questions about what it is we're doing. Cheers! - End forwarded message - ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp 1.3.21 is on slashdot
On Tue, Oct 07, 2003 at 07:01:32PM +0200, Sven Neumann wrote: Hi, Joao S. O. Bueno [EMAIL PROTECTED] writes: That means that over the next hours, tens of thousands of people will point there browsers to www.gimp.org. Some people in the foruns, including me, have provided links to mmmaybe.gimp.org. However, the latest release on mmmaybe is 1.3.17. Could 1.3.21 be announced there in the next minutes? The 1.3.21 announce has been submitted yesterday already. It seems the news engine is broken which keeps it from showing up. Now who can fix this? Fixed now. Unfortunately, the current situation requires news updates to be regenned by hand. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-web] Re: [Gimp-developer] Proposal for protesting against software patents in Europe
I just moved the old index back, with the postponement of the vote, the protest page is not as relevant. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] bugs@gimp.org spam getting a little out of hand
On Tue, Aug 19, 2003 at 06:20:43PM +0200, Sven Neumann wrote: Hi, On Tue, 2003-08-19 at 18:04, Rapha??l Quinet wrote: We cannot easily change that address because that would require changing all gimp bugs, which are using this as the contact address. But as I suggested during GIMPcon, we could configure this address so that it accepts mails from Bugzilla only. Anything that is not coming from Bugzilla would be bounced back to the sender. I think everyone keeps suggesting this for quite some time already but we need Yosh to implement this suggestion... Done. But if anyone is filtering on the X-Mailing-List, you'll have to change it (this is something I wanted to avoid doing, but I haven't figured out how, so hence the wait) -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GimpCon RFC: Portable XCF
On Wed, Aug 20, 2003 at 08:54:55PM -0400, Leonard Rosenthol wrote: At 11:42 PM + 8/13/03, Phil Harper wrote: as for TIFF, you wouldn't be able to do it in a standard readable TIFF, This, however, is wrong! We can represent EVERYTHING in GIMP today, and EVERYTHING for GEGL (etc.) in the future with TIFF. And other programs simply will ignore them as they do with other features of TIFF they don't support. Does TIFF support, for example, float16 data, or a CIE XYZ colorspace? I'm somewhat concerned with going with an externally standardized format, then running into a wall with it at some later point, and not being able to add a feature without breaking standards compliance. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GimpCon RFC: Portable XCF
On Thu, Aug 21, 2003 at 10:16:13AM -0400, Leonard Rosenthol wrote: At 11:42 PM -0700 8/13/03, Manish Singh wrote: Supports IEEE floats, but not float16 (a 32-bit float cut in half). RH added this to filmgimp since they had established this format in their workflow with other tools already. Why would you only use half of a 32bit float?? That reduces your accuracy/precision and makes you incompatible with the rest of the world doing floating point imaging. But if your other tools already use it (for whatever reason, technical or historical) easier have GIMP support it rather than change the rest. This is precisely the reason RH decided to go with an open source solution like GIMP (they could hack float16 support in) instead of Photoshop or some other closed paint program. And admittedly, it's not a big deal to convert... And makes the file size twice as big... One of the goals of GEGL is to allow GIMP to be adapted to wacky formats like these easily. I would argue that using wacky formats is a bad thing. The more wacky you make things, the less change you have for interoperability with other tools. If you make it easier to accept wacky things, you interoperate better. Suppose someone wants to use GIMP to manipulate what their neurological imaging scanner spits out at full precision; GEGL is supposed to make that possible. Yes, there should be efforts to make the common case easily interoperable, but uncommon things should be possible with the minimum amount of hoops. It's not just the tags, but extending value ranges for tags (needed for the two cases above). And a lag time means either waiting for an updated spec, which is a holdup, or going ahead and running the risk it not being granted because someone else tried to get their conflicting values in first. The spec is only updated every 18-24 months when Adobe releases a new version of Photoshop - so you definitely don't wait for that! As for the other, yes, that is true you could wait, but nobody does... And Foo organization adds a tag with the the same value as Bar organization, for different purposes, since neither cares to wait. Part of the reason why there is a lot of bad tiff processors out there I think. With the XML+AR idea, there's a little work needed to make a DTD, and then just putting some building blocks together, like an xml library and some ar processing code (multiple implementations exist) and some convenience wrappers. Never implemented a file format, have you ;). What widely used formats have you implemented? :) Reading/Writing the 'ar' archive, and reading/writing the XML is the easy part - because you can leverage existing libraries to some extent. The toughest part is putting it all together in a library of its own that allows for full random access. Most archiving libraries are all at once solutions, they aren't designed for single file extraction. We, of course, need that. We also, as ar supports random access and single file extraction just fine. Take a look at the manpage for it sometime. :) part of the DTD/Schema work need to define how you go from a GIMP image in memory to a disk representation and then back and work out the details. And for TIFF we need to define how you go from a GIMP image in memory to TIFF tags and values. Remember GIMP has to carry around a fair amount of metadata, like layer settings, paths, parasites, etc. Worth the work, sure! Trivial - no way! It doesn't seem to me that using libtiff saves us a significant amount of work. Also, suppose customizing libtiff is needed (and it sounds like it would be), that'd mean forking libtiff and the maintainence problem of tracking the original for bugfixes and enhancements. There is no need to touch libtiff - and if there is, you don't work, you modify and then submit your changes back. libtiff is an active library, and the maintainers would happily accept changes... Yeah, but there are people out there still running outdated installed, it's harder to get them to upgrade a system library. If we add and extend tags, their definitions should go in the library, no? So what to do in the time before those changes are accepted... Also, one has to wonder why Adobe is keeping PSD around if TIFF does everything. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
