[Gimp-developer] Gimp 1.2.4 Final?
Greetings, First: thanks for the excellent software!! Does anyone have an estimate of when Gimp 1.2.4 will be final? Pre 2 appears to a be a few months old. I scanned through the archives and could not gather much about the anticipated release time. Thanks again, Jeshua Lacock __ Programmer/OwnerPhone: 760.935.4736 http://OpenOSX.com Fax:760.935.4845 -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New version of the preview requirements
Hi, Ernst Lippe [EMAIL PROTECTED] writes: At the moment my development environment is nicely organized for my own developments, I've got a standard Gnu distribution with autoconf, automake, gtk-doc. Altogether I've got 44 files in CVS just for this project. I can't imagine that you would be very pleased to add all of them to Gnome CVS. I'd rather see it integrated into the GIMP module but if you prefer to work outside the GIMP tree for some more time, that's up to you. Another point is that the current name of the widget is GimpPreview and for some reason I don't think that you will like that name (even though my widget is a direct descendant of Shawn's widget that was written somewhere in 1998). we should discuss this. Generally GimpPreview is perfectly acceptable as a name but since we use it in the core already we should consider to look for another name to avoid confusion. All this does not mean that I would not like to see my preview in the GIMP CVS ASAP. I'd really like to have the preview and at least a few of the plug-ins in the official 1.4 distribution. (BTW is there already a new deadline? I believe that it was originally scheduled for the end of last year). I don't think it has ever been scheduled with a fixed date. It's ready when it's ready but we are now trying to push things a bit. I'm putting some pressure on you just to let you know that we'd rather like to see a working-yet-not-perfect plug-in preview widget than no plug-in preview widget at all. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp 1.2.4 Final?
On Thu, 20 Mar 2003 01:51:15 -0800, Jeshua Lacock [EMAIL PROTECTED] wrote: Does anyone have an estimate of when Gimp 1.2.4 will be final? Pre 2 appears to a be a few months old. I scanned through the archives and could not gather much about the anticipated release time. The release date has been shifted a couple of times. It could have been before Christmas last year, but that didn't happen. I think that the official word is: when it is ready. If you want to know what is blocking the release of 1.2.4, follow this link to see the list of bugs that have the target milestone 1.2.4: http://bugzilla.gnome.org/buglist.cgi?product=GIMPbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDtarget_milestone=1.2.4 If you can help solving any of these problems, then 1.2.4 will be released earlier. The most annoying one is bug #83362 (licenses). -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] mouse pointer and brush size (was: Somefeedback on Gimp 1.3.x)
On Tue, 18 Mar 2003 23:14:47 +0100, Simon Budig [EMAIL PROTECTED] wrote: Branko Collin ([EMAIL PROTECTED]) wrote: [CinePaint] The Windows version also comes with a nice mouse pointer the size of the current brush. Doesn't quite seem to work yet, but very handy. Since this pops up again and again, I thought I'd share my thoughts on how this might be implemented. We could generate an outline of the current brush in the same way as we create an outline for the selection. The result would be a black/white image that roughly shows the size/shape of an brush. (For brush pipes we could simply use the first brush in the pipe or combine the black/white for the various brushes. Since the latter would be a pretty black image for huge brush pipes a better idea would probably be a bounding box or something like that.) Changing the X11 Mousepointer itself is most probably not an option, since some platforms have a size limit on that pointer (32x32 or so - pretty small). But if the brush is small at screen resolution (size of the brush * zoom factor), then using the X cursor is the best option because it will probably be the fastest solution. So it would be better to check what is the largest cursor supported by the X display and to use the cursor for drawing the outline, as long as it fits in the acceptable dimensions. Unfortunately, it looks like GDK does not provide direct access to XQueryBestCursor(), which would be the correct way to check the sizes accepted by the current display. Another option is to use gdk_cursor_new_from_pixmap() and check if it fails. Also moving an additional shaped window synchronously with the mouse pointer sounds like a bad idea to me, since complex shaped windows have a big performance impact on the X Server. So we could simply XOR the image on the image view window. The GimpDrawTool could be extended with functions to draw a bitmap on the image and the GimpPaintTool would optionally use this feature to place the above mentioned image on the view area. Some servers are relatively fast at XORing large bitmaps over the image, but some others are slow. For other servers, it could be faster to draw a set of lines showing the outline of the brush (if the outline is not too complex). Even for a given server, the optimal choice can change if the GIMP is used remotely (over the network) instead of locally. Also, at some zoom factors, the brush outline could as large as the screen, or even larger. Using a bitmask for this could consume too much memory, while using line segments would not have a big impact. All these things are summarized in bug #32498: http://bugzilla.gnome.org/show_bug.cgi?id=32498 In particular, check the comment that I posted on 2002-01-08, quoting Mattias Engdegård about line segments vs. bitmasks. -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp 1.2.4 Final?
Hi, Raphaël Quinet [EMAIL PROTECTED] writes: If you want to know what is blocking the release of 1.2.4, follow this link to see the list of bugs that have the target milestone 1.2.4: http://bugzilla.gnome.org/buglist.cgi?product=GIMPbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDtarget_milestone=1.2.4 If you can help solving any of these problems, then 1.2.4 will be released earlier. The most annoying one is bug #83362 (licenses). I don't think that any of these bugs warrants a further delay of the 1.2.4 release. The most ridiculous one is certainly bug #83362 (licenses). Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp 1.2.4 Final?
On 20 Mar 2003 14:27:19 +0100, Sven Neumann [EMAIL PROTECTED] wrote: Raphaël Quinet [EMAIL PROTECTED] writes: http://bugzilla.gnome.org/buglist.cgi?product=GIMPbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDtarget_milestone=1.2.4 If you can help solving any of these problems, then 1.2.4 will be released earlier. The most annoying one is bug #83362 (licenses). I don't think that any of these bugs warrants a further delay of the 1.2.4 release. The most ridiculous one is certainly bug #83362 (licenses). Well, yes this is a ridiculous bug. However, the license problems are now publicly known. And there is a Debian bug report related to that. So I assume that any distribution that is aware of these issues and cares about being able to distribute packages legally would consider this bug to be a blocker. Otherwise, they would be liable in the (unlikely) case that some copyright holder complains about the licenses. Not very likely, maybe, but some distributors are probably taking these legal issues seriously. -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp 1.2.4 Final?
Hi, Raphaël Quinet [EMAIL PROTECTED] writes: Well, yes this is a ridiculous bug. However, the license problems are now publicly known. And there is a Debian bug report related to that. So I assume that any distribution that is aware of these issues and cares about being able to distribute packages legally would consider this bug to be a blocker. Otherwise, they would be liable in the (unlikely) case that some copyright holder complains about the licenses. Not very likely, maybe, but some distributors are probably taking these legal issues seriously. Well, we already took care about a couple of affected files. Let's look at the remaining files: plug-ins/common/edge.c This file has about 500 lines from which at least 400 are completely GIMP specific. The algorithm used boils down to a few lines and could probably be discovered by any high-school student who made his/her maths homework from time to time. I'd like to cite RMS here: You don't need to worry about copyrights or licenses for just a few lines of code. plug-ins/common/gif.c This one is difficult since its a mix of some older code for which the license is not perfectly clear and lots of new code that has been added while this file lived in the GIMP source tree under a GPL license. Definitely a difficult choice with rather unpleasant consequences since other projects have long adapted this code under GPL and LGPL licenses. plug-ins/common/mail.c This plug-in contains a few lines that perform base64 encoding. The authors of this code should feel honored for being mentioned since anyone could take the base64 spec and rewrite this from scratch. plug-ins/common/nlfilt.c The algorithms here are not really trivial and it would make sense to try to contact the author. If he doesn't agree to relicense his code, we could just drop the plug-in. plug-ins/common/tiff.c I don't see where this plug-in uses any non-GIMP-specific code that is worth being mentioned. The TIFF file format is handled by libtiff and I doubt there's anything in this plug-in that can not be determined from reading the libtiff docs. plug-ins/webbrowser/webbrowser.c The algorithm used here is rather trivial and can be redone using the docs provided by Netscape. The original authors should feel honored for being mentioned. We want to get rid of this plug-in for GIMP-1.4 anyway. plug-ins/script-fu/interp_slib.c I'd rather not have to rewrite this one. But then we have always very clearly stated the source of the SIOD interpreter that runs Script-Fu. Just go and try 'gimp-1.3 -i -b -'. You will see the following lines: Welcome to SIOD, Scheme In One Defun, Version 3.2x 12-MAR-96 (C) Copyright 1988-1994 Paradigm Associates Inc. Help: (help) IMO this is exactly what the SIOD license asks for. I don't see any problems. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Some feedback on Gimp 1.3.x
On Tue, 2003-03-18 at 17:48, Olivier Ripoll wrote: Just to say I do not think it is un-obtrusive. My default image size is 256*256, and the menu is too big to fit in the image window (or just creates a huge empty window). However, this could be a tip for the tips and tricks window. Well, I know most users don't read this window anyway. I'm working with very small images (icons) all the time and the menu just feels weird since I can only access a minimal number of items. On the other hand this is about a sensible default. Having it on by default may help new users find the functionality they would fail to find in a right click menu. Those are the people that would use gimp to sharpen their image, crop it, rotate it and save to a different format. People like me and Olivier would have no trouble turning it off. I think it's less of a pain for us to turn it off than to spoil new-user experience with a trivial UI issue like hiding basic functionality like this. cheers -- Jakub Steiner [EMAIL PROTECTED] Ximian, Inc. signature.asc Description: This is a digitally signed message part
Re: [Gimp-developer] caching considerations in gegl
On Wed, 2003-03-12 at 00:03, Daniel Rogers wrote: Adam D. Moss wrote: The idea isn't that the layer mask usurps image alpha, but that traditional paint/fill tools are generally used to increase opacity and define colour simultaneously (they do), while layer masks are extremely handy ways to safely experiment with eroding opacity away again as a logically separate composition step rather than a destructive processing of the RGBA data. --Adam I like this distinction. This should be written down somewhere. Probably in the manual (if it isn't already). This clearly describes precisely what approach to use when. Related to this, I would love to have a function that would enable me to create a layer mask from alpha channel or apply it to the existing mask. That way it would be possible to increase opacity with a layer mask by first applying the alpha channel to the mask and then 'darkening' the layer mask. To me this is a missing link between alpha channel and mask. We already have similar function when working with selections/channels. cheers -- Jakub Steiner [EMAIL PROTECTED] Ximian, Inc. signature.asc Description: This is a digitally signed message part
