Re: [Gimp-developer] Handling of transparent pixels
Hi, Raphaël Quinet wrote: One thing that has not been mentioned in this discussion so far is that there are two kinds of transparent pixels: those that have been made transparent during the current GIMP editing session, and those that were already transparent when the file was loaded from disk or obtained from a plug-in. Like nomis and Sven, I don't see there being any inherent difference here. 1) For the pixels that have been made transparent during the current editing session, one point of view could be to consider the alpha channel as a "hiding mechanism" that does not modify the RGB data. However, if the goal is to be able to un-erase some pixels that were accidentally made transparent, then an "undo brush" would be a more appropriate solution to that problem. So the concept of "hiding without destroying" is not really necessary if the same data can be retrieved from the undo history with the same convenience. I don't follow your logic here. It is undoubtedly useful to consider an alpha channel as a way to hide data, therefore it is not necessary to modify data in the RGB channel when we modify the A channel. In any case, masks and alpha channels are also used to hide data across sessions for several file formats (eg. png), and we have ven had a bug report against the GIMP (http://bugzilla.gnome.org/show_bug.cgi?id=82882) because someone expected this behaviour from the tiff plug-in (apparrently this is provided by other programs). 2) For the pixels that have been obtained from an external source, then the "hiding" concept does not fit because the RGB data is undefined. This is where we start to voilently diverge :) I disagree that this is the case. It may be considered to be the case in some specific circumstances, but in general, we should not destroy data, IMHO. Not destroying it means, inevitably, allowing it to be manipulated. Your suggestion amounts to pre-multiplying RGB by alpha regardless of the file format, and I consider that just wrong. Beyond the next release, this is also why we should consider removing the "anti-erase" mode of the eraser tool in a future release and replace it by an undo brush. As a matter of interest, how would an undo brush work? I'm having trouble getting my head around the idea. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Displaying image using GTK
Hi Shrinivas, Shrinivas Kulkarni wrote: Is there any way to display GIMP image in GTK controls? If by GIMP image you mean an XCF, then I don't know of any such widget. However, the GtkImage widget supports a number of file formats - including png, tiff, xbm, gif and jpeg. There is one more question I have is that, can we write a standalone app using GIMP. This question arises, because, I do not want to use all the funcitonality of GIMP, but want to have my own toolbox and still able to use selective functionality from GIMP. You might be better looking at something which was designed as a graphics toolkit, such as ImageMagick. The GIMP application contains quite a bit of the functionality we use, and plug-ins communicate with it using a wire protocol that I don't understand. You could steal the minimum of code from the GIMP to use the PDB, or you could do as Simon suggested in another thread, and run the GIMP im batch mode. Hope this helps, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Building GIMP1.3.22 using MSVC++
Hi Shrinivas, Shrinivas Kulkarni wrote: Is there any help on steps to build GIMP 1.3.22 using MSVC++ 6.0? There are instructions on building the GIMP for windows in the wiki: http://wiki.gimp.org/gimp/HowToCompileGimp/MicrosoftWindows, but that article seems more oriented towards using gcc on either cygwin or msys. Perhaps Hans could comment on this - he seems to be the local MSVC++ expert :) Despite a short search, I haven't been able to find something more appropriate. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Displaying image using GTK
Hi Shrinivas, Shrinivas Kulkarni wrote: By "using GIMP" I mean to use GIMP as library. Such facilty may be necessary since we may not want user to have all the functionality that Core GIMP provides. For example, we may want user to draw on the image( lines, curves), but may want user to allow apply rich filters GIMP provides. Ah... if this is really a typical problem area, then you might have some problems. The GIMP is organised in 2 parts, the core application, and its plug-ins (and associated infrastructure, libraries, etc). It would be possible to link against the libgimp libraries to create a plug-in, or example, or as someone suggested to replace the core with a "lite" core which understood the PDB, and communicate with plug-ins that way. But since you don't seem to be too interested in the filters, and seem more interested in the core application, that doesn't seem to be what you want to do. The core application contains (more or less) tools, internal data structures for images, layers, vectors and so on, a number of widgets for the UI, code for loading and using external data (brushes, patterns and so on), and the PDB core implementation (the protocol we use to talk to plug-ins). Since this seems to be the code you're interested in, that's what you would be looking at. Unfortunately, it's not written to be used as a library - you can't link with the draw tools only, for example, in a 3rd party application. Howeveer, the code is quite modular, and I think you could probably dump most of the filters (except file loaders for formats you're interested in, or else use a GtkImage), dump many of the tools, lose more than half the GUI code, and arrive at something resembling GPaint. Or, you could write a corba control for GPaint, and embed that in your application? I do not understand, why I cannot have image created and displayed without GIMP running. I understand. However, it was not our goal to provide a reusable graphics framework at this stage. That is a goal of gegl, though. And that should be possible within a few months, if all goes well. In short, the edit window, right now we have that should converted to widget and developer should be able to use it even without running GIMP. ( This implies that user should be able to call even PDB functions that is calling procs from PDB.)Right now the edit window, seems to be very much tightly coupled with Toolbox. If we provide such facility GIMP will be really extensible. I'm not clear on how this could be accomplished. Would you like to write a proposal on how you think this might happen? I mean, how you would make the toolbox, for example, optional or modifiable. This is something that we would like to see, and if you have ideas we would love to hear them. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Displaying image using GTK
Hi Shrinivas, Shrinivas Kulkarni wrote: Therefore I got pkg-config-0.15.0 and tried building it first, unfortunately it is giving some compiler errors. Is there any place where I can get precompile binaries for pkg-config. I am really running short of time, therefore I do not think I should spend more time on this. I am following the instructions from http://wiki.gimp.org/gimp/HowToCompileGimp/MicrosoftWindows in order to build GIMP. You can get everything you need to build the GIMP from source at http://www.gimp.org/~tml/gimp/win32/ - this has zips containing DLLs, header files, lib files, etc. There are pointers for binary downloads of everything you need, including build tools from GNUWin. You might also consider using the Dropline builds of GTK+ 2.2.x, these install DLLs "properly" for Win32, and there are instructions on their site for building stuff using them. Cheers, Dave. PS: Please note that I've never managed to get a full GIMP build on Win32, although it's almost a year since I last tried. I have always had linker problems. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Open Source myths
Hi, For those (like me) who rarely read slashdot and missed this: http://www.onlamp.com/pub/a/onlamp/2003/12/11/myths.html This is an article which sums up a number of myths about open source software, as well as talking about ways that some of them can be addressed. A number of these are relevant to the GIMP, I think. Of notable interest: * If the only way to learn the basics of a project is bug fixing, most developers won't bother * If the software is hard to install, most users will not install it * Being open source isn't enough to get new developers. * End users don't follow CVS Anyway - I thought it was interesting. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GEGL in GIMP
Hi again, Sven Neumann wrote: David Neary <[EMAIL PROTECTED]> writes: What I would propose is that the GIMP CVS module have an app/gegl directory which is linked to the gegl module, so that doing a cvs co of the GIMP would also check out gegl. This is insane. CVS modules cause nothing but trouble. If you want to use GEGL, then depend on it. If you are afraid of this dependency, don't do it then. I really didn't expect this to be so controversial. GTK+ was developped as part of the GIMP until it reached a certain state of maturity, I'm not suggesting that we absorb the goat, just that we include it in our tarball (again, to make the GIMP easier to build - which comes back to the other mail). Other people do this, so perhaps it's not as obviously insane as you're making out. There is no fear of the dependency... but until gegl is in a state where it's mature enough to make standalone releases, then it's more or less exclusively a GIMP project. Why not help it along? Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Dependency version changes (was: GEGL in GIMP)
Hi, This has split into 2 different issues again, replying twice with appropriate subjects. Sven Neumann wrote: David Neary <[EMAIL PROTECTED]> writes: I think that we could perhaps do the version bump in an organised way this time, at least? What are you trying to say here? I don't remember any unorganized version bumps. In the past, I recall there being problems with the trasition from GTK+ 1.2 to 1.3, Ipersonally heard about the version bump from GTK+ 2.0 to 2.2 when the build failed, idem for the fontconfig requirement, idem for the version bumps in automake during the release cycle. By "in an organised way", I mean simply that we make a decent effort before changing build requirements to let people know that they're going to be changed, when, why, and what they need to do to keep a working GIMP CVS build environment. This is not the trivial problem you're making it out to be. We should wait for the gtk+-2.4 release and then wait another week or two to give distributors a chance to prepare packages. The rule of thumb in the past has been to wait for the package to appear in debian testing which is a rather conservative distrubtion. I think that we should definitely have a release from CVS before changing (at least a week before changing) and have something in the release notes saying that the GTK+ version will bump in the next release. And pair this up with a mail to gimp-developer saying when the change will happen, and how to keep things working. The bump from gtk+ 2.0 to 2.2, for example, was not just a simple version bump, because there were about half a dozen other packages that needed to have recent versions installed. It would have been nice to have a small list, and a couple of days notice that things were going to change. > No-one said we want to do that. What are you talking about? We talk > about depending on GTK+-2.4 which will be the latest stable release of > the GIMP toolkit at the time we start to use it. You don't want us to > ignore the features it offers and use an unmaintained version instead, > do you? No-one who is not a GNOME developer will have GTK+ 2.4.0 installed on their machine. The first time people will have this software installed is the early-adopters of GNOME 2.6.0 in April and May. So I don't mind being on GTK+ 2.4 at that stage. I don't even mind being on it earlier, as long as we don't assume that people will just have it installed. That means putting some work into letting people know how to migrate their build stuff (see above). At the heart of this issue is whether we want to make it easy for people to build the GIMP. I think we do. Depending on software that they haven't installed yet makes it a bit harder. Breaking build environments by changing dependencies without giving people adequate warning does too. I want to avoid things that make it harder for casual people to keep up to date with CVS GIMP. And that's all. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gegl-developer] Re: [Gimp-developer] GEGL in GIMP
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? Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gegl-developer] Re: [Gimp-developer] GEGL in GIMP
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? 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+. 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). Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [PATCH] Gradient-Fu for 1.3.x - Complete but not Final
Hi Shlomi, Shlomi Fish wrote: Check: http://t2.technion.ac.il/~shlomif/grad-fu/1-3-x.html for a link to the up-to-date patch. Thanks for the patch. Would you mind attaching this to the bug report, just in case your hard-drive fries over the holidays or something? Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gegl-developer] Re: [Gimp-developer] GEGL in GIMP
Manish Singh wrote: On Tue, Dec 23, 2003 at 09:35:09AM +0100, Dave Neary wrote: 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. We could think about it now, and do something about it post 2.0 :) That's all I am doing is throwing ideas around. 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. So having the GIMP use gegl will be beneficial to gegl :) In any case, that is not the goal of the 2.2 release. I still believe that always stable, always releasable, with a 6 week freeze on functionality and a release for GUADEC are the technical goals of the 2.1.x series. If we start using tiny bits of gegl, then that's great. 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? You didn't propose having gegl and gimp downloads in the same directory till today. So I don't follow the logic. ;) The post you replied to immediately before this one talked about having the tarballs together. I posted that yesterday. 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. I agree. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Aqua GTK+OSX
Hi Robin, Selon Robin Rowe <[EMAIL PROTECTED]>: > GIMP on Mac OS X without X11: > > http://gtk-osx.sourceforge.net/docs/gimp.html Congratulations! Anyone know if there is there a gdk aqua back-end in gtk+ 2.2.x? If not, is one planned? Cheers, Dave. -- Dave Neary Lyon, France ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Quick progress report
Hi, Sven Neumann said: > I am in favor of doing 1.3.24 today or tomorrow. Doing a 2.0-pre > release will not only mean closing the remaining bugs but it also > involves a couple of file moves in the CVS tree (files that have the > 1.3 version number in their names). At the moment I'm quite busy with > christmas, Blinkenlights Reloaded and preparation of 20C3. I would > manage to do 1.3.24 release but I'm not sure if a 2.0-pre release > would fit into the schedule. Of the 1.3 bugs remaining, I think the grey point for the levels tool should be added. Unfortunately, I have no access to a gimp source tree until the 4th of January, so I won't be able to do this. I think that doing the necessary with what Maurits did is also a prerequisite, that requires someone to generate a patch, and then move some stuff about. Apart from that, I'm happy to have 2.0 pre1 as we are. I would agree to have a 1.3.24 now (or tomorrow), and have 2.0pre1 after the holidays, when these last 2 things are handled. That will also give you guys a chance to do some hacking at the CCC ;-) Anyway, happy Christmas everyone, and here's to 2004. Cheers, Dave. -- Dave Neary Lyon, France ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Friends of GIMP
Hi, Quoting Kevin Cozens: > What is supposed to be the point of such a list? If you pulled names from a > changelog you are probably making a list of the more active developers of > the GIMP who are probably already on the gimp-devel mailing list. A couple of people asked this question - I thought I'd explained the idea pretty well, but I guess I missed the mark. The list is a list of people who were active in the project several years ago, but who have gone on to other things. It would be nice to get some of them back working on the GIMP, if they have the time. So this is a little effort on our part (on my part) to communicate better with some people who are likely to be interested in what's happening with the gimp. The list is pretty incomplete, as Daniel Egger says, that's why I sent it here to get more suggestions. And as you say, some of these people are still on the developers list. Basically, the two groups where we can hope to get volunteers are people who have already helped with the gimp, and people who have never done so. The problem with the latter group is that they don't have the accumulated knowledge of experience, and we don't know who they are. The former group are both experienced, and known. Therefore, they're easier to get in touch with :) So - that's the idea. Any additions to the list are graciously accepted. Cheers, Dave. -- Dave Neary Lyon, France ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] ANNOUNCE: The GIMP 2.0pre2
Hi,
The most recent installment from the GIMP production line, version
2.0pre2, is available now for perusal, downloading, evaluation, testing
and use from
ftp://ftp.gimp.org/pub/gimp/v2.0/testing/
or from one of the mirrors listed at http://gimp.org/download.html
Since the last release, nearly 40 known bugs have been killed, and many
other small changes have been made during code reviews.
Given the relatively small number of bugs reported against our past
pre-release, we expect this to be the final pre-release before 2.0, so
we extra-appreciate the time you spend testing and breaking it.
Happy GIMPing,
Dave.
Bugs fixed in GIMP 2.0pre2
==
- 130828: Compile error with gcc 2.95 (Adrian Bunk)
- 35335: Curve tool doesn't conserve black (Simon)
- 130866: Remove multiple PNG entries in file type dropdown (Brix)
- 106991: Add mnemonics for all menu items (finished by Mitch)
- 130869: Add smaller image templates (Dave Neary)
- 130916: Handle multiline texts better (Mitch)
- 120424: Add dirty flag to default image title (Brix)
- 130912: Fix rounding errors in JPEG plug-in ([EMAIL PROTECTED])
- 131016: Add support for layer offsets in multipage tiff loading (Pablo
d'Angelo)
- 124073: Modify behaviour of zoom tool to avoid funny fractions (Dave
Neary, Simon)
- 131088: fix select-to-pattern script-fu (Mitch)
- 82478: Fix zoom handling in fractal explorer (Pedro Gimeno)
- 115793: Make thumbnail preview of indexed images match display (Pedro
Gimeno)
- 130471: Handle RGBA images correctly in the CEL plug-in (Dov Grobgeld)
- 131109: Remove EMX specific code (Sven)
- 130118: Handle GIMP2_DIRECTORY with non-UTF-8 characters correctly
(Tor Lillqvist, Sven)
- 82465: Make preview match image when image is greyscale (Sven)
- 92586: Force SF_IMAGE value to reflect the selected image (Sven)
- 116765: Fix selection artifacts while moving selections (Pedro Gimeno,
Mitch)
- 131215: Only call bind_textdomain_codeset when available (Reinhard
Geissler)
- 125141: Resolve API issues with GimpPixelFetcher and
GimpRegionIterator (David Odin, Maurits Rijk)
- 109078: Fix histogram for graylevel images (Pedro Gimeno, Mitch)
- 131146: Fix drag & drop of patterns to layer masks (Dave Neary, Mitch)
- 128112: Use a better error message if help files are not present
(Mitch)
- 78732: Don't paste outside the visible screen, if possible (Mitch)
- 131561: Make "Condensed" fonts available for use (Manish Singh)
- 71922: Fix SuperNova preview for Alpha channel (David Odin)
- 82464: Fix SuperNova preview for greyscale images (David Odin)
- 121966: Fix SuperNova plug-in (David Odin)
- 110610: Allow user to choose file formats even if the current image
type is not supported by them (Pedro Gimeno)
- 131980: Fix crash in crop tool (David Odin, Sven)
- 131030: Allow saving data without pre-multiplying by alpha channel in
tiff plug-in (Pablo d'Angelo, Dave Neary)
- 125864: Guides behave correctly when spacing is set to 1px (Brix)
- 131721: Fix handling of alpha channels across undo steps (Mitch)
- 128025: Fix behaviour when there is a floating selection (Mitch)
- 131076: Make fuzzy select tool respect alpha channel in indexed mode
(Mitch)
- 131779: Improve indexed scaling dialog (Mitch)
- 127673: Overlapping widgets in gradient editor {Mitch)
Other contributions:
David Odin, Manish Singh, Simon Budig, Michael Natterer, Sven Neumann,
Tor Lillqvist, Henrik Brix Andersen
--
Dave Neary
[EMAIL PROTECTED]
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] gimp-data-extras update
Hi all, I was a little bored after lunch, so I updated the configure.in of gimp-data-extras to work with the 1.3 releases. For those who want to install these with an old 1.2 gimp, the branch gimp-1-2 was created. To get the extra brushes, patterns and gradients that were collected all those years ago, cvs co the gimp-data-extras repository on cvs.gnome.org, run autogen.sh and then make install. Those of you using anonymous CVS will have to wait a while. Those of you who don't want to go messing in CVS will get a tarball soon. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Possible 2.0 pre bug
Hi, David Hodson wrote: I don't have pre2, but in my (1.3.23, I think) version, the general Convolution Matrix filter seems broken. Is this still broken in the latest? (If so, I'll try to fix it - seems simple.) I couldn't find anything in Bugzilla. I just checked here on Windows, and it seems that way. Could you open a bugzilla report for this, please? And a fix would be most welcome :) Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] The GNU Image Manipulation Program
http://www.gimp.org The GIMP project has been one of the headline Linux applications for over 5 years, since before the release of version 1.0 in 1998. It attained that project entirely through the work of volunteers, and apart from a short period around 1999/2000, has never had corporate financing to help its development. In that time, it has continued to advance, and with the upcoming release of version 2.0, it should concrete its position as one of the major free applications. An Open Source Award, aside from recognising the pedigree of the GIMP project, and the work of a large number of people over several years, would help the project move forward to fulfill its vision of a free, flexible and extensible image manipulation framework. One of the things which have slowed this progression are the costs associated with meeting up, and if the project were to win an award, the money would be spent on partly financing travel expenses for GIMP developers to a GIMP conference in June. Because of its continued excellence and longstanding presence as a key free program, I think that the GIMP deserves an OSA. Regards, Dave Neary. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The GNU Image Manipulation Program
Hi all, Dave Neary wrote: > Because of its continued excellence and longstanding presence as a key > free program, I think that the GIMP deserves an OSA. I CCed the list with this just to let people know that I'd nominated the GIMP for an OSA - awards are of $500, $1,500 or $10,000, and would help a lot towards covering travel costs for next June. I have also sent a mail to the OSI requesting contacts and fundraising advice. Myself and Daniel Rogers have been talking recently about how we should approach fundraising for GUADEC, and Daniel has had a number of very good ideas. Over the next few days, we (actually, Daniel's done most of the work) will put together a plan of attack and mail it to the list, looking for volunteers to help. Hopefully by the time 2.0 comes out we will be ready to go full bore into a fundraising drive which will get us enough money to pay for the conference. Apologies for jumping the gun, I hope I didn't step on anyone's toes doing this. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Update
Hi Raymond, raymond ostertag wrote: Aside from that, there's lots of stuff happenning outside CVS too... the help team recently did a pre-release of the gimp-help-2 module, and it's looking very good. Roman, Daniel, Raymond, Niklas, Sven and everyone else who is working on the help right now are doing a great job. s/sven/julien Perhaps s/sven/julien and sven/? Sven's put quite a bit of time into the docs recently, and it's because of him that we can now make snapshots that actually install. I consider that Julien is a main doc-writer. Sorry - excuse the omission - I have understood that you were now the main .fr GIMP docs contributor. Merci Julien for les docs en francais. L'oublier c'est une insulte grave aux contributeurs !!! As I know, Sven did'nt wrote any chapter (thank you for install script aniway). Excusez moi tous - j'ai bien sûr pas été complète, et je voulais surtout pas insulter qui que ce soit. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Update
Hi, raymond ostertag wrote: Julien wrote : - french translation of main tools - english and french doc for color tools - english and french doc for the fisrt part of the filters : Blur/ color / Noise / Edge / Enhance / Generic (some filters are still not committed in CVS) - english translation for my path tool and corrections of my dialogs doc I only wrote : - doc for path tool in french, layer (not in CVS) and channel doc in french and english (And also many works on fr.po) I have looked at the changelog for the docs, and indeed between yourself and Julien, you've written over half of the English docs in there. I really do apologise for the omission - until yesterday I wasn't aware of the work ye had done. Would it be possible for the dcs team to do occasional update reports like I've tried to do over the past few months? It's easy to forget about ye, because all too often we don't look at the docs until there's a release. Roman did an update recently, and it would be nice if this became a regular feature, just to let us know who to thank :) Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Win GIMP
Daniel Rogers wrote: A good window manager makes the window-in-window concept unnecessary. However if someone wanted to develop such an approach for all the poor users that are forced to use a not so advanced window manager, then it should probably be addressed at the toolkit level. What Sven is saying, is that it is basically impossible to get Window in Window support working on linux. Just a small precision - it is impossible to do WiW with gtk+. QT does it OK. And in fact, there is a project (I don't recall the name) which does just that - creates a window, and then embeds GIMP windows in it, using QT. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Misnamed structure element in SFScript structure?
Hi, Sven Neumann wrote: Simon Budig <[EMAIL PROTECTED]> Include a GUILE in the Gimp sourcecode, make sure that it doesn't conflict with other GUILEs on the target system and use it as the GIMPs default language. Perfectly fine with me as long as I have a language that is guaranteed to be available for 99% of the GIMP installations. I don't think we should do that simply because I don't see what is so important about having a self-contained scripting language. I'd rather like to see three or four well-maintained and working scripting languages that can be installed separately. If we can make sure that the language extensions work and can be easily installed that should be good enough then. I'm with Simon - at least one scripting language installation's a good idea. We might assume that perl or python are more or less universally available, but we can certainly not assume that guile is always installed. Given the fact that script-fu has historically been the reference language binding (and it continues to be), we should go out of our way to make sure it's available, IMHO. Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Updated roadmap
year release cycles are not. And of course milestones aren't required, that's just ridiculous. But they can be useful. That's all... don't read more into this than was intended. Time based releases are hard, but for them to work, there need to be times. Do you think that people working on GNOME have less fun because they have a plan now? I know GNOME users have more fun - they get all the cool stuff within 4 months of it going into CVS. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Misnamed structure element in SFScript structure?
Hello, Sven Neumann wrote: It's just a packaging issue. As long as we make sure that everyone can install gimp-script-fu, we have script-fu support. Do you really want to continue to include it with GIMP with all the problems that arise from doing that? I don't think it's worth it. Including guile doesn't mean supporting it. As it is, there are a bunch of things we include that don't get much support because the original authors have gone their own way. This time we're not even talking about *pretending* that this is a GIMP thing - we set up a configure script that checks if there's a local guile installed, if there is it uses it, otherwise it calls configure && make on its copy, and uses it in the GIMP. It is the same thing as we currently have, except that instead of George Carrette's SIOD, we'll be using GUILE. And this time, we will be using an official release of a scheme interpreter, not a GIMP modified copy. I don't see a downside. In the long run we should move as much as possible out of the GIMP package. This will assure that we provide a stable and powerful API and will enable more extensions and plug-ins to be written. IMO moving script-fu out of the tree and putting it on the same level as gimp-perl and other language bindings is a very important thing to do. There is a certain point at which this is unreasonable. If we move all the C plug-ins out into another module, and all the brushes, patterns and other data to another module, and all the script-fu and python-fu to separate modules, we'd have a small, stripped down core, but a usable GIMP would be made up of 6 or 7 CVS modules, 6 or 7 packages to download, and 6 or 7 packages to maintain. The sooner it happens the better. Actually I was considering this for 2.2 (along with gimp-python). We are not doing ourselves a favor if we treat Script-Fu any better than other language bindings. Especially since it is technically the worst of them all. I'm afraid that moving all of the langauge bindings out of the core would only result in the bindings not being maintained as well. As it is, the Python bindings are in need of a bit of a work-over before 2.0, if I remember correctly, and script-fu itself is only getting the minimum of maintenance for it not to be broken. Anyway - working towards a minimalist GIMP is kind of going away from what I'd like to see. I'd be more interested in being pretty liberal about the patches and plug-ins we accept in the core, and get more plug-in authors involved in maintenance work and development. For that we need to define guidelines for getting a plug-in into the core, and get the word out that we're interested in more or less anything and everything to do with image processing. Hand in hand with that we would also need guidelines for when a plug-in would get dropped (temporarily?) from the distribution if it is unmaintained. If we have decent guidelines, this would add very little work for maintainers, who could just let plug-in authors take care of their own code. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Misnamed structure element in SFScript structure?
[EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) wrote: On Thu, Feb 05, 2004 at 01:06:58PM +0100, Sven Neumann <[EMAIL PROTECTED]> wrote: I don't think we should do that simply because I don't see what is so important about having a self-contained scripting language. I'd rather like to see three or four well-maintained and working scripting languages that can be installed separately. If we can make sure that the language extensions work and can be easily installed that should be good enough then. I think this is already reality, as most people will get gimp from a gnu/linux distribution and many if not most of them will ship these extensions as seperate packages already. Actually, most GIMP users probably get their GIMP from Jernej - OK - the GNU/Linux side of things gives us a nice big install base on Linux, but proportionately very few Linux people actually *use* the GIMP. I'd guess that the majority of our power users are on Win32. (and the rest should easily be prepared to deal with installing things from source). This is the big developer fallacy... installing from source is not easy, particularly if you have a desktop set-up and not a developer's set-up. If you have to install a C compiler, you probably won't bother. To me it's all a matter of the installer. Agreed. The installer should, IMHO, install almost everything (within reason). It makes more sense to have separate packages for stuff on Linux (that's the Linux way) but on Windows, people expect to be able to install 1 thing. 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. Agreed. So - who's been thinking about the macro recorder? :) Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Updated roadmap (so people don't laugh at the old one)
Hi, Henrik Brix Andersen wrote: On Thu, 2004-02-05 at 13:27, Sven Neumann wrote: [...] nail us down [...] [snip] Imposing a fixed release schedule [...] [snip] [...] this road map should not be set in stone. I think both you and Sven have somewhat missed the point. The funny thing is, we are *almost* in agreement. I'm not trying to nail anyone down. I don't think anyone is. I'm not *imposing* anything. The roadmap (as has been shown by the last one) is *not* set in stone. However, it is precise. I don't think this should be a stick we use to beat ourselves with. I don't think we should get upset if a release isn't done *exactly* on the 31st of March or whatever. But I think that we're more likely to be close to the bigger dates if we have smaller, closer dates to aim for. I also think that we should release regularly, regardless of whether we think things are "ready" or "finished", because it's healthy for the project. Releasing should not be a big deal. It could be as simple as doing cvs tag GIMP_2_1_1 cvs diff -r GIMP_2_1_0 -r GIMP_2_1_1 > the_diff In which case, there'd be no reason not to do it often. Currently, we impose a standard somewhat stricter on ourselves, which means that making a release takes a long time (it can take 7 or 8 hours on a fast machine). But who cares if that thing you wanted to fix didn't get done? It'll be done for the next release. A release is *not* a deadline, it's a liberation of the work of the last 2 weeks. It's no secret that the GIMP project is rather short on active developers these days (I haven't been very active myself lately either) - and I think setting a tight release plan/road map will only discourage new developers to start spending what little spare time they may have contributing to The GIMP. Well, myself and Sven are in agreement on the tight release plan, more or less. I think it might be a little too tight, and I personally would have aimed for a first pre-release for guadec, with a final 2.2 in August, but I think a 4 month release is possible. The *only* difference between my idea and yours and Sven's is that I think that giving concrete dates as rough guidelines for milestones is better than having bigger milestones every 6 weeks to 2 months. I respect that you don't want to have to stick to dates. Like I said, there will be no Stazi knocking on your door if you don't. The roadmap is meant to be specific, but flexible, in my mind. If the majority opinion is against that, I will re-do a vaguer roadmap with no precise dates. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Misnamed structure element in SFScript structure?
Hi, Sven Neumann wrote: Dave Neary <[EMAIL PROTECTED]> writes: I'd guess that the majority of our power users are on Win32. Are there any numbers you can base this statement on? No, it's a guess. Not that it would matter much but I doubt there are more Win32 GIMP users than Linux GIMP users. It's possible. I'd also like to get an idea of the number of MacOS X GIMP users. I'd say not many. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Tentative 2.2 feature list
Kevin Cozens wrote: On Thu, 2004-02-05 at 17:12, David Neary wrote: 9) A decent image browser/thumbnail viewer + cover-sheet support This sounds a bit like the old GUASH (which I have started to port to GTK+ 2.x/GIMP 2.0) but I'm not sure what you mean by "cover-sheet support". http://bugzilla.gnome.org/show_bug.cgi?id=132532 Photographers make these a lot to have a nuber of photos in an array on paper. Perhaps this should/could be done at the gimp-print level, but it should integrate nicely into the thumbnail viewer... By the way, Sven has also been talking about doing a thumbnail viewer based on libgimpthumb. I don't know what stage it's at though. In any case, updating GUASH to 2.0 should be a fairly quick job, good luck - perhaps some code clean-up would be nice too? :) Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Updated roadmap (so people don't laugh at the old one)
Sven Neumann wrote: Hi, David Neary <[EMAIL PROTECTED]> writes: You can certainly spread it around. I update the NEWS now, as well as you. Anyone can do that. Same thing goes for making the announcement on freshmeat, gnome-desktop, linuxartist... I can do bugzilla tags. Well, I am certainly not going to ask for this and so far I have always waited about a day if someone else would post announcements on gnomedesktop and other sites. But it seems that noone but me is interested enough to post there, so I guess I will continue to do that. After all I am interested in people trying the release when I've gone through the trouble of doing one. Perhaps people hesitate about this because they don't want to step in on what might be perceived as your territory? If I understand correctly, you'd like to be able to have it announced on the mailing lists (as I do now), and then the people on the list make the announcement known in the places that are important to them. That seems reasonable, and I think that now that you have said so, this might well happen for the next release. That looks like a reasonable time frame. I expect that we will have to extend it a bit but that was the point of starting with a tight schedule. What's missing now is some agreement on what we want to achieve in 2.2 but I think we can as well delay this discussion until 2.0 is finally done. That's one reason I didn't put any meat on the bones when I made this proposal. 2.0 is the priority right now. You're contradicting yourself a bit too - one of your complaints was that there was no meat on the propsal. Anyway - I think we can agree to maintain a vaguer roadmap. I'd still like to think that we can be sensible about trying to keep to the things we say in it. Cheers, Dave -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Tentative 2.2 feature list
Hi, Sven Neumann wrote: David Neary <[EMAIL PROTECTED]> writes: 3) Edit patterns in-place 4) Save as GIMP Pattern saves direct to ~/.gimp-1.3/patterns (same for "Save as GIMP brush) This would be nice but I don't think it's a blocker for 2.2. If someone wants to give it a try, fine. Not sure if it should be on the list though. I'm interested in doing this, I think it's a very nice feature. It would also fit nicely into "hiding" system brushes as described in bug #118742 - http://bugzilla.gnome.org/show_bug.cgi?id=118742 5) Preview widget to replace GimpOldPreview That's a rather large change. If we get someone interested and a proposal for an implementation is posted early enough, then it should probably go in. David Odin has said he would like to do this for 2.2, which is why it's on the list. 6) User-defined presets for most plug-ins Can you explain this further? Actually I don't like the idea of doing it the way we've done it for PNG now. I'd rather attempt to develop a new PDB that can be used alternatively. That redesigned PDB would then bring default values, user-defined presets and lots of other nice things to all plug-ins using it. Did anyone check how far libpdb has come? Would be nice if we could base our efforts on it. The idea I had (knowing that this is a big change) is to export the serialisation stuff to libgimp, have plug-ins which want presets extend GimpPlugIn which will implement the serializable interface. The plug-ins should then move from a structure of options (as they currently have) to GObject properties for options they want serialised. Then we could re-use the widgets that are in place in the core in the plug-ins. I won't be able to do this myself, but it would be a very nice feature for someone to take on, if that plan sounded reasonable. 7) Move from SIOD to guile for script-fu Guile or another interpreter or fix the current implementation. All nice but we keep asking for this for years now and I don't see it happen until summer. Let's say, it would be nice to have but it shouldn't block 2.2. Agreed. But someone could claim this now, and make it the thing they do for 2.2 - given the work that mitch did recently in further separating out siod from script-fu, this should be a fairly small job. I also doubt that it makes sense to tackle layer groups and layer effects in 2.2. The timeframe is way too short for these. They were on the list as stuff which would be possible, if someone claimed them now and started working on a proposal between now and the middle of March when we will branch. On the policy side, here's how I would like things to be handled in 2.1.x: - Every feature added to CVS has a bug # associated with it How is that more useful than annoying? "feature" = "big change which might introduce bugs" - this will allow cross-referencing later. It will also make it more transparent for people following from a distance, or website maintainers, to maintain a list of features in 2.2. The ChangeLog is far too voluminous to serve as a feature tracker. Bugzilla is made for that. It will also help to see if people are starting big features just before a feature freeze, so that we can maybe bump things before there's a big block of unstable code committed. It might be annoying - it's certainly something I'd like to see tried. It's intended to help us work on stuff that's on the planned feature list too. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Tentative 2.2 feature list
Hi again, Dave Neary wrote: Sven Neumann wrote: David Neary <[EMAIL PROTECTED]> writes: 5) Preview widget to replace GimpOldPreview That's a rather large change. If we get someone interested and a proposal for an implementation is posted early enough, then it should probably go in. David Odin has said he would like to do this for 2.2, which is why it's on the list. As a matter of interest, why do we not simply take the old GtkPreview code an rename it GimpPreview, put it in libgimpwidgets and use that? Just wondering. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Tentative 2.2 feature list
Hi, Sven Neumann wrote: Dave Neary <[EMAIL PROTECTED]> writes: As a matter of interest, why do we not simply take the old GtkPreview code an rename it GimpPreview, put it in libgimpwidgets and use that? Just wondering. Because the old GtkPreview code is not what we would like to see as a GIMP preview widget? It shares a few characters in the name but that's about where the similarity ends. Ah - I recalled you saying on several occasions that you didn't understand why GtkPreview had been deprecated, that you thought it was a very good widget. I must have misunderstood. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Tentative 2.2 feature list
Hi, Sven Neumann wrote: David Odin <[EMAIL PROTECTED]> writes: What we are aiming for is a lot more complex than what GtkPreview is providing. The goal is to have a widget that can zoom and pan. This would be cool. It should also provide an API that allows to use the same image processing routines for the preview as are used for the drawable. The plug-in author shouldn't have to care much about the preview. I'm not sure what you mean by this - wouldn't the preview just be a copy of the drawable which gets rendered? What API is needed? I have trouble following the problems you see. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Last day for abstracts
Hi all, A quick reminder that today is the 16th of February, the last day for submission of abstracts for GUADEC talks. The original call for papers is here: http://2004.guadec.org/cfp2004.html Paper abstracts should be sent to [EMAIL PROTECTED] Thanks for your time, see ye all in Kristiansand, Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] GUADEC: Abstract submission deadline extended
** Abstract acceptance date extended to Friday 20th (for those in a hurry) ** Hi all, A number of people who had planned on submitting abstracts for GUADEC, but who had the misfortune to be in the US over a holiday weekend, missed the Monday deadline and by a general consesus among the organisers, it has been decided to extend the date for acceptance of abstracts to Friday the 20th of February (as usual the deadline is midnight, UTC for those who like to leave it late). The original call for papers is here: http://2004.guadec.org/cfp2004.html Other dates will not be affected. The papers review committee will start reviewing papers already submitted this week. For information purposes, 48 proposals for talks or BOF sessions have been received so far, covering a wide range of topics. For those who would like more information, the guadec-papers mailing list archives contain all of the abstracts received so far. So get writing, and get those abstracts in. There will not be a second extension. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Tentative 2.2 feature list
Hi, Ernst Lippe wrote: Sven Neumann <[EMAIL PROTECTED]> wrote: http://refocus.sourceforge.net/preview/gimppreview.html The major points in the discussion were that some people did not like the way that the preliminary version of the preview tried to prevent recursive updates and that the names did not start with GIMP. As far as I can tell these points have been fixed in the first official release. As a matter of interest, do you do any optimisation based on the current viewport in the preview? Do you generate a viewport-sized (+ margin, say) drawable from the original drawable that you pass to the function connected to the "update-preview" signal? Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] GIMP preview widget (was tentative 2.2 feature list)
Hi Ernst, Ernst Lippe wrote: Dave Neary <[EMAIL PROTECTED]> wrote: As a matter of interest, do you do any optimisation based on the current viewport in the preview? Do you generate a viewport-sized (+ margin, say) drawable from the original drawable that you pass to the function connected to the "update-preview" signal? > The first question that you face when you want to add this, should the drawable be scaled or not? The kind of logic I would have thought might be reasonable is: 1) if the original drawable is zoomed out, do a messy scale of the original to give the new drawable (accuracy isn't *hugely* important in general in this case), then take the tiles containing the part of that drawable that will be visible in the viewport, and generate a drawable from them, and apply the transform to that. 2) If the original drawable is at 100% or greater, then calculate the pixels that will be in the viewport, take the tiles containing that bounding box, generate a drawable from them, apply the filter, then expand the result as necessary to bring it up to the scale ratio. For example, say I'm doing a blur on a 400% zoomed copy of an image, and the viewport (256x256, say) is showing pixels (0,0) -> (64,64). In this case I take all the tiles that box covers (easy enough in this case, it's just 1 tile), make a new drawable with those tiles, apply my blur (on a 64x64image it should be quick), and zoom the result to 256x256. If I'm blurring a 25% zoomed copy, the easiest way is to do the scale on the image first, blur that with a radius r * 0.25, and show the result. In the former case (zoomed in), I'm not blurring 90% of the image data that won't ever be displayed in the viewport, and in the latter I'm doing a "good enough" zoom on scaled image data (with no interpolation). Also, as long as the zoom ratio doesn't change, I keep my reference zoomed drawable around so that I don't have to re-do the calculation/zoom every time I pan around in the viewfinder. How does that sound? There is not much point in using an unscaled drawable because the plug-in could easily extract it from the original image, and there is no performance advantage by doing it in the preview. The performance advantage is surely in performing the preview calculation on a (possibly small) subset of the total image data, isn't it? > Also, I have added a utility function to the preview (gimp_preview_get_temp_drawable) for doing this, so it is very easy for the programmer to do this in the signal handler. Yes, I'd noticed - that could be one way of doing this, I guess. It would be nice to avoid plug-in programmers having to repeat this logic, though. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Tentative 2.2 feature list
Hi, Sven Neumann wrote: Ernst Lippe <[EMAIL PROTECTED]> writes: The decision if the plug-in "needs" the temporary drawable is made by its designer and it is certainly not forced by the preview. So you are seeing the GimpPreview as just a widget that plug-ins can draw on. However our goal is to provide a way to add a preview to plug-ins basically w/o changing their code. The change should be limited to the plug-in dialog and a few hooks here and there. Your preview widget could be part of this infrastructure since it provides a way to draw pixels to the screen, but in its current state, it certainly doesn't meet the goals I outlined above. It is certainly a step in the right direction, though, and I think that it is something that we should try to use (and improve) during the 2.1 cycle. It is more than a simple widget that you draw on too - you get feedback from the widget about which pixel region is currently in the viewport, and you can quite easily generate a drawable from that which you pass to your filter function. Given that there are now 2 developers interested in working on this (Ernst and dindinx) I think there is a good chance that working together on it (in GIMP CVS, so that we get some feedback from the plug-in authors who use it too) we will have a nice to use preview widget by 2.2 Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP preview widget (was tentative 2.2 feature list)
Hi, Ernst Lippe wrote: Dave Neary <[EMAIL PROTECTED]> wrote: 1) if the original drawable is zoomed out, do a messy scale of the original to give the new drawable (accuracy isn't *hugely* important in general in this case), then take the tiles containing the part of that drawable that will be visible in the viewport, and generate a drawable from them, and apply the transform to that. 2) If the original drawable is at 100% or greater, then calculate the pixels that will be in the viewport, take the tiles containing that bounding box, generate a drawable from them, apply the filter, then expand the result as necessary to bring it up to the scale ratio. How does that sound? First of all you need a larger input area otherwise the image near the edges of the preview are incorrect. That's a minor implementation issue - we can take the drawable used to generate the preview to be the viewport +/- some arbitrary amount of pixels, or perhaps take 1 tile more than we need in the horizontal and vertical direction. part of the preview is "close to the edge". But the actual size of the margin depends on the blur radius, so when you want the preview to provide the scaled data, there should also be some mechanism to tell the preview how large this extra margin should be. This assumes that the preview should be precise. One of the merits of the preview, though, is that it is an impression of the effect and renders quickly - quick and dirty should be OK. Of course, there's a compromise to be made in there. But I don't think plug-in previews need to be 100% exact. But when the image does contain sharp differences there can be an important visual difference: consider an image with alternating black and white pixels (they alternate in both horizontal and vertical) when the image is zoomed at 50% and then blurred the When the image is zoomed to 50%, the image itself is either grey or all black/white (depending on the scaling algorithm we use) - if it's grey, then so will the blur be. That said, I get the point. Also with this approach you will probably get some very obvious visual effects when you zoom in or out. Again, I see the point. And I agree that your proposal to start with unscaled data and see how slow it is before moving on to scaled copies is reasonable. Yes, but that is something that the plug-in algorithm should do, because it is the only place where you can determine what inputs are needed to generate a specific output area. Think for example of some whirl plug-in, to compute a given output area it will only need a subpart of the original image, but it can be very difficult to determine what part is really needed. So it is the responsibility of the plug-in algorithm to compute only a specific output area. Good point. But shouldn't the preview widget cater to the most common case, while allowing the plug-in to address the less common case? I would prefer to see all convolution based plug-ins (that are essentially local) and render plug-ins (where the result is entirely predefined by a seed) to have a nice easy way of generating a preview that consisted of more or less 1 or 2 function calls, and have a more complicated API to allow things like whorl and the like to calculate their effects using a preview widget, with some more work. Anyhow, a good plug-in should already have the functionality to compute the outputs for a given area (gimp_drawable_mask_bounds), so it should not be too difficult to modify this to use the area that was determined by the preview. It would be nice to move some of this common code into the preview widget itself, so that the common case doesn't have to worry about it. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CinePaint Roadmap
Hi all, I just wanted to correct an inaccuracy in what I'd written before... David Neary wrote: And yes, she is misinformed - the 1.2 branch was merged into the HOLLYWOOD branch when it stabilised. I was mixing up the upgrade to gtk+ 1.2 (which was done by yosh in 2001) and a merge of the 1.2 branch back to HOLLYWOOD. I could find no evidence that this ever happened. So the HOLLYWOOD branch which was taken over by Robin a couple of years ago was based on 1.0.4, and migrated to GTK+ 1.2. I guess yosh and calvin would know better than anyone else whether any code from the 1.2 branch was merged into HOLLYWOOD after their initial work in 1998. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Costs estimates
Hi all, For funding requests for GIMPCon in Norway, it will be very useful to have cost estimates for the event for the GIMP. Could everyone planning to go to Kristiansand send an estimate of how much money they will need to get there? Also, could you mention whether you will need some money in advance to pay for a plane ticket or something? If we know that you need money in advance, we can try and work something out. Your expenses should cover transport and accommodation, and you should also say how much you really need - so for example, "My plane ticket is ¤350, and hotel will be about ¤150 for the 3 nights, so that makes ¤500, but I guess I could get there with ¤300 and put up the other ¤200 myself". Basically, the chances are that there will not be enough money to cover all expenses, but if there aren't we'll try to cover the minimum to have the maximum amount of people there. If you could do a quick search, and send me this information this week, that would be cool. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Press package for 2.0
Hi all,
On IRC a few days ago Sven asked if anyone was working on a press
release for 2.0.
I got thinking that it would be nice to have a press package for the
release, which would contain
- A press release
- Some detail about the GIMP ("The GIMP is..." with the spiel from the
web-page, perhaps spruced up a little)
- A detailed document of user visible features in the release
- Perhaps an article for lazy magazine writers so that they could take
the article, change some paragraphs around, and have a 1 or 2 page
article on the GIMP in their April issues.
I have started a rubric on the Wiki for the press file, which has these
4 sub-topics. It would be really cool for people to contribute to this
(please, say on the list of you are writing something for this so that
people can get collaborative on this).
Here's what's there so far:
Raymond Ostertag and jimmac have both been working on a list of features
in the 2.0 GIMP - here's Raymond's version (in French):
http://www.gimp-fr.org/html/mongimpfr/Presentation_GIMP2.html
Here's the (in progress) translation in English (Sorry, Raymond, I
haven't had the time to read it - perhaps someone on the list will give
some feedback):
http://www.chez.com/lamarque/index.php?gimp2.html
There are also links to what's new in GAP and a tutorial for the new
paths tool, which it would be nice to have translated soon.
The screenshots need to be updated for the English version.
The article needs to be completely written, if we are going to include
it (and that's optional).
So - who has some time to help out with this? Pipe up.
Cheers,
Dave.
--
Dave Neary
[EMAIL PROTECTED]
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Press package for 2.0
Hi all, Dave Neary wrote: I have started a rubric on the Wiki for the press file, which has these 4 sub-topics. It would be really cool for people to contribute to this (please, say on the list of you are writing something for this so that people can get collaborative on this). I didn't give a link: http://wiki.gimp.org/gimp/GimpPressPack Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Release Manager
Hi all, It's become clear to me that the release manager doesn't have the power to do much in the project. Since last Summer I've avoided using the title for the simple reason that other people seem to resent the idea of titles, and I had hoped that actions would speak for themselves. Since then, the idea of having a roadmap has met more opposition that I expected on two occasions, and several people have said that they'd ignore it anyway. Most of what I do these days seems to be PR and developer relations (massaging egos after other people unconsciously piss people off). I can do both of those without the title. In fact, given that we have a de facto maintainer already, who handles releases and controls pretty tightly what gets checked into the tree, the role doesn't have much meaning. So we need to talk about what the role of release manager means to the project. The last time I asked someone what exactly release manager means, I was told that it was a nice title, and I should enjoy having it. If it's decided that it's just a title, then someone else can have it. But if we agree that the release manager has a certain role to play, it should be well defined. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: [Gimp-user] Help docs online
Branko Collin wrote: I disagree. The appearance of GIMP 2 does not all of a sudden make GIMP 1.2 obsolete. There is no technological reason why both manuals cannot be hosted on the same site. How abut having the manual of the latest stable version as the default (gimp 2), and having a link to the old manual (gimp 1.0) on the front page? Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Press pack requests
Hi all, The 2.0 release is getting closer, and there are still some thing missing from the press pack we want to send out. - Could native english speakers who have a few minutes please look at the "What's new in GIMP 2.0" page (http://wiki.gimp.org/gimp/WhatsNew) and correct any grammar problems? - high-res screenshots of The GIMP showing new features are welcome. Examples of the kind of screenshots which are interesting are here: http://jimmac.musichall.cz/stuff/private/gimp-2/html/index.xhtml http://developer.gimp.org/screenshots.html - If anyone would like to donate an article on The GIMP 2.0, it is most welcome (this might also be a source of revenue for funding if magazines re-print it). Thanks a lot, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Press pack requests
Hi again, Dave Neary wrote: - If anyone would like to donate an article on The GIMP 2.0, it is most welcome (this might also be a source of revenue for funding if magazines re-print it). Speaking of magazines, that reminds me of one thing we have not done. I have started a new page in PressPack, MagazineAddresses. Could people add the following information: - Magazine name - editor's e-mail address - postal address if available for all Linux, digital photography and image processing magazines in their country? We should split this by country. Thanks very much to Branko Collins for getting this list started with UK and Dutch contacts. An alternative method would be to have volunteers volunteer to send out the press pack for their country to all relevant magazines. It would be a brilliant thing for LUGs to do to cut CDs of The GIMP 2.0 plus all of the extras for cover CDs. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: [Gimp-user] The GIMP Foundation
Daniel Rogers wrote: Avoid self-dealing. What's this? Be honest. Is this true of every board? Even Halliburton? 1. Will TGF have members? I am talking about members with voting privledges, like I described above. (my vote is yes, btw) Yes. 2. Should the membership be paid? (my vote is yes, for like $50 a year or some toher small amount. It helps for tax purposes). Why not - this is also common in France. That means setting up paypal I guess... Although the GNOME foundation have a membership policy which fits in better with the Open Source model - there is a membership committee, which considers applications for membership on a case-by-case basis based on participation in the community. Membership is reconsidered every 3 years, and is free. 3. Should the membership have additional rights? Aside from voting in the board? Meh... It would be useful to know who is interested in accepting the responsibilites of being a board member (or officer). Me. But a board can only work if the developers and the board work together towards the same goals, so to speak. If the board and the developers are in conflict, it'll bomb, or it'll be a PR disaster. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Project structure
Hi all, I sent this yesterday to gimp-devel but I used the scam.xcf.berkeley.org server, which seems to be still having problems. Re-sending it. I'm also eaving gegldev in the CC, just to keep a common thread for cross-posts. === The major problem that this project has at the moment is its lack of structure. There are no bosses, no maintainers, no active developers (this is a point where I agree with Robin Rowe). I'd like to propose that the following roles be defined and published on the site (if it ever gets updated). Maintainer: Sven Neumann Module owners: Vectors: Simon Budig Core: Sven or Mitch perl bindings: Seth Burgess Python bindings: ? PDB/libgimp: ? Plug-ins: ? (stick with plugin-maintainers?) GAP: Wolfgang Hofer Help: Roman Joost GEGL nodes: Calvin Williamson GEGL data: Dan Rogers I've deliberately left out some obvious modules (web, because it seems that this is now dead, for example). What does the structure buy us? It gives people a point of access to contact if they have suggestions, bugs, questions. It allows people who want to get code included to contact someone directly for code review. It puts names and faces on the organisation for magazines, articles, interviews, presentations. It also obliges people who already have a certain amount of authority and responsibility in the project to assume that responsibility, rather than shirking it by saying that everyone's voice has the same weight. This is clearly not true. I don't expect any of the names to be particularly controversial. This is a request for comments, though - so comment away. Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Project structure
Hi, Sven Neumann wrote: Dave Neary <[EMAIL PROTECTED]> writes: What does the structure buy us? It gives people a point of access to contact if they have suggestions, bugs, questions. It allows people who want to get code included to contact someone directly for code review. I think our policy is to encourage people to use bugzilla and the mailing-lists, and not to contact developers directly. Do you mean is, or should be? I agree that that is the current policy, but disagree that things should be like that. Mailing lists and bugzilla are for the most parts an excessively high barrier to entry for people not already in the community. The quantity of mail we're talking about is not huge either - just because a name is on a website somewhere does not mean that all of a sudden they're going to get slashdotted by 1 mails a day. ... in most cases I ask people to use the public channels. I believe that this policy is a good thing. I believe we should be much more flexible about how we use those public channels, too... for example, someone recently reported a bug on a mailing list. The bug was confirmed on the mailing list, and the fix was trivial. In spite of that he was asked to create the bug on bugzilla so that it would be fixed in the next release, which probably meant taking 5 more minutes than he had already taken to create a bugzilla account. That was, imho, unnecessary. Similarly, someone complained about the interface to another feature in bugzilla, claiming that there was no way to do task X, and that this was a bug. He was asked to contact the user list if he didn't know how to do task X. Again, this was IMHO excessive - especially given that the feature in question is pretty well hidden, and currently undocumented. In the same way, private e-mails are often a lot less intimidating than mailing to a public list which is often not very welcoming (there are countless examples of people understandably not knowing about stuff getting told off for not doing their homework on the lists). For example, the person who is currently the most active contributor to gimp-help-2 has never sent a mail to the list, because he's not particularly technical, and he doesn't feel comfortable mailing the list. Private e-mail is a much nicer way to get involved, particularly if you manage to talk to someone who listens to you and encourages you. I sent my first patches to Daniel Egger, because his name appeared pretty often in the changelog at the time. Daniel was very nice, pointed out where I could improve my patches, committed them for me, and at a certain point pointed me towards the lists and towards mitch when the patches got a bit bigger. In short, Daniel made it easier for me to contribute. If I send a patch to the list, it's actually sending it to no-one. Same thing with a bugzilla report. No-one is responsible, no-one says "I can't help you with this - but person X might". There is no way to know whether a patch will get applied, acknowledged or whatever. Plus, I need to sign up for a list where I might get another 100 mails a month to add on top of the 2 or 300 I already get if I'm a free software developer. I'm not saying that we should actively encourage people to send mail directly to developers, I'm saying that we shouldn't actively *discourage* avenues of communication. If someone contacts me personally with a question (which happens more and more frequently), I reply to the question as best I can. I'm reasonably pleasant, polite and friendly. If I can't help them personally, I might add someone better placed to help as a CC. Or I might reccommend that they ask the list. But if I can help, I do. Sure, there might be some gem of wisdom lost to the mail archives, but the chances are that the GIMP has made a new friend, someone who'll go away and say that the GIMP guys are really nice and approachable. If instead I say "I can answer your question, but first you have to sign up to a mailing list and ask your question there", they're more likely to go away thinking that the GIMP guys are kind of uptight, maybe they'd consider that rude, perhaps they might even go away saying that the GIMP developers are arseholes. Bear in mind that this has very little to do with the fact that you're being polite or impolite. They're asking for help, and you're insisting that they conform to an artificial structure which makes them go out of their way to get help. If we ask people to contact developers directly, we rely on these developers being responsive at all times (which they cannot be, they might be busy or on vacation). We wouldn't be asking people to contact developers directly. We'd be not asking them not to. And no-one expects an individual to be any more responsive to personal mail than normal. It's not a duty call, there is
Re: [Gimp-developer] Project structure
we should. If every team in existence has a leader, it's because that's a decent way to get the team working well together. I don't follow you on this track. We have come a long way without a strict hierarchy. I enjoy seeing GIMP as unstructured as it is. The only thing that really bugs me is the bad state of our web-site. What's with the strict? I'm not talking about a strict hierarchy. I'm talking about a series of people who know bits of the code well, who can decide whether something gets done or not (in other words, we'll finally have some decisions), and who knows who's interested in that code. In other words, a release manager. there's no plan. We need a plan. There is no plan? I think we have a very decent plan. What is it? I published a set of dates, and a set of funtionalities, for 2.2 recently, and it was out of the question that we use dates (even though we ended up using "rough" dates anyway), and the list of functionality doesn't exactly constitute a plan. Our plan is 1. Release GIMP 2.0 2. Release GIMP 2.2 3. Get gegl ready 4. ... 5. Profit!!! There has been lots of discussion, but no decisions, on what gegl needs to be ready, how that will happen and when, nor has there been any decision (again, lots of discussion) on how gegl will actually be integrated into the GIMP, what implications that has for the interface, at what points we have interim milestones where we can settle things down and have a release, etc. I recently (based on a proposal of Dan Rogers) came up with a medium-term planb for integrating gegl into the GIMP, which included functionality lists, rough dates, and so on, which brought me to the end of 2005. What is your plan? Share it with me, because I'm not clear on what you think the plan is. I would very much welcome to see a better roadmap being published than what we have currently. Again, the problem is the web-site, not some general lack of structure or lack of leadership or lack of a plan. The website problems come from the lack of leadership and structure. So do the communication problems. There is no place where you can get the answers to the kinds of questions like "who is responsible for the website?", "How can I get a plug-in added to the GIMP?" - all of those things come from a lack of structure. And I'll say it again - we do not have a lack of leadership. You are the leader. This is clear to everyone. What we have is a lack of a leader who says he's the leader. If we don't do something like that, we're doomed to continue developing in all directions like headless chickens without ever getting closer to the goal (colorspaces + profiles + bitdepth + DAGs + everything else). I wonder what makes you think about GIMP development this way. I do understand if it may appear like this to outsiders (again because of the lack of good public relations, i.e. web-site), but _you_ should be aware that there's a plan and that people are working hard to get things done according to this plan. I don't think that perceptions like this are just outside the organisation. We do not work well as an organisation. That much is clear. I'm not trying to be an agent provocateur here - I'm tryint to make constructive suggestions for how we can improve the organisation (recognise our leaders, don't refuse any avenues of communication which might get people involved in the GIMP, be nice to people, have a plan and stick to it) - these are all constructive suggestions, but they do imply that I want to change the way we do things. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] choosing fonts
Hi Gezim, Gezim Hoxha wrote: If you could make a feature so one can youse the arrows on the keyboard and see how a font looks, and check out the next font instead of having to click so many times. Also adding "letter spacing" feature wouldn't be too bad. In the drop-down box from the text tool font button, there is a button "Open the font selector dialog". This dialog allows navigation by arrow keys. This is also a dockable, so you can add it to the dock beside (say) paint brushes so that it is easily accessible while you are using the text tool. Hope this helps, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Bugs on milestone 2.0
Hi, Sven Neumann wrote: It would also help to have the bugs better prioritized in Bugzilla. Blockers should be marked as such. Bugs not marked as blockers will be moved to the 2.0.1 milestone if they don't get fixed before sunday. Some of the bugs listed can IMO be moved to 2.0.1 or even 2.2 immidiately. We should also categorise most of the -- milestone bugs (I think that these should go to 2.2 or 2.0.1, for the most part). Do we have a volunteer with some free time and bugzilla permissions who wants to help me with the bug maintainance? I'll help out with this, should be pretty quick. Anyone who wants bugzilla permissions drop me a mail. 133719 User Interface crashes on paste I haven't been able to reproduce this, even with a cluttered screen and docks set-up. Bumping to 2.0.1 sounds good. 136636 Tools Selection mode modifier affects selection at mouse release Looks like a GTK+/GDK problem to me. It doesn't crash GIMP but it makes some actions with selections impossible on Windows. Should not be considered a blocker but it needs to be addressed soon. I'll have a closer look at our code, and see if this is a GTK+ issue. If I have the time, I'll do up a test case. Agreed it's not a blocker. 131965 General Deletion of layer with brightness-contract active This is data loss but on the undo stack only. This is critical but it shouldn't block the release. We don't seem to have much clue what is going wrong here. It would be nice to have people look closer at this one before 2.0 - I agree that it's not a blocker though. 93806 Script-Fu 124176 General 120490 Tools 115774 General 76228 Tools 128594 Tools > 123888 Plugins > 65534 Plugins > 97734 Tools > 121871 Plugins > 12253 General > 91384 General Agreed on all of these. 136489 Script-Fu gimp-edit-copy fails on transparent area This is strictly speaking an API change but it seems we better do it since the current API is just plain broken, Yup - there's a patch against this with a few problems, I think we should accept it. 128833 User Interface Tool dialogs block image (crop tool) Smells like another user preference. For anyone comfortable with GimpConfig, this is an easy change to GimpToolDialog, GimpGuiConfig and a line or two in gui/preferences_dialog.c. I'm not comfortable about having this as a preference. The best fix would be to have the crop tool pop up somewhere other than the center of the image, which is possibly the worst place it could pop up. Is this dialog session managed? If not, what needs to be done to make that happen? 112859 User Interface transform tools' preview should take linked-group in conside Not critical but it would be nice to change it now so that the 2.0 UI stays consistent. Otherwise bump to 2.2 ? I'd say bump - unless someone feels happy taking this on with about 3 or 4 days to do it. 109561 General Toggling layer visibility resets tool parameters Not sure how this could be fixed. Shouldn't be a blocker but it is certainly an annoying side-effect. I'd really like to see this fixed before 2.0. Of course, that means someone needs to fix it... I don't think that I will have the time myself. Plus, as you say, the fix isn't immediately obvious. 132698 Plugins Discrepancy in Script-Fu constants vs. DB Browser We need to come to a decision here. Need to look at it again. I think we should do both (keep the old enum naming scheme and add the new one), and deprecate the old one for 3.0 (or possible 4.0). -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-user] Re: [Gimp-developer] The GIMP Foundation
Hi all, Sven Neumann wrote: Also, so far the FSF has done a great job at funding our developer conferences. So we should really have good reasons to form our own foundation since I don't expect the FSF to grant any more fundings as soon as The GIMP Foundation has been created. This is not a vote against the TGF; it's just something to keep in mind... I don't see why this should be the case, unless we have a sufficient revenu stream to fund ourselves. In any case, to have any revenu at all we need an organisation and a bank account, since a private individual accepting donations for a non-existent organisation isn't very professional or reassuring, never mind the fact that it opens up, as Dan said, channels of liability for the individual involved. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP and the new GTK+ filechooser
Hi, Sven Neumann wrote: People will soon start to ask why GIMP 2.0 doesn't use the new filechooser yet. Not sure how we would best react to this. We should just say that GTK+ 2.4 is not out yet, and we can't base stable software on an unstable toolkit. Especially since we've been in a pre-release freeze for 3 months. Should we promote Mitch's patches? No harm in that. If we do that we will most likely very soon see binary GIMP2 packages showing up that have these patches included. Mitch, what do you think? Would that be a problem at all? I doubt that. Especially since the sources we'll provide will only require gtk+ 2.2. The target, I guess, is to have a GIMP based on 2.4 around the time where distros start shipping GNOME 2.6. Which will probably be towards the end of the Summer. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP and the new GTK+ filechooser
Hi, Sven Neumann wrote: The target, I guess, is to have a GIMP based on 2.4 around the time where distros start shipping GNOME 2.6. Which will probably be towards the end of the Summer. Distros will start shipping GNOME 2.6 shortly after it has been released and the release schedule for GNOME 2.6 says March 22nd. This date will have to be corrected due to the delayed GTK+-2.4 release but I think we can expect a GNOME 2.6 release in early April. Thus, we should face the fact that at least some distros will make their GIMP 2.0 packages depend on GTK+-2.4 and ship with these patches applied. If distributions choose to do that we certainly won't stop them. I think that we could also encourage distributions to use development releases if they're releasing GNOME 2.6 - we're planning on keeping the development releases more or less always releasable, so this could be possible. I think that you're being optimistic to say that distris will ship with GNOME 2.6 as soon as it hits 2.6 - even if it's out in early April (and I have no doubt that it will be), the release schedules for the distros are not going to coincide so that Mandrake 11 comes out a week afterwards with GNOME 2.6 in there. Optimistically, GNOME 2.6 will start appearing in stable distro releases 2 to 3 months after it's released. Which brings us to June or July. It looks like gnome 2.6 will probably not make it into Fedora Core 2 (which is due out in May, but should be frozen by the time GNOME 2.6 comes out) - since Mandrake 10 just came out I don't think Mandrake 11 will be for a few months, and Debian aren't really that bothered about releases bug GNOME'll be in testing before the end of April. So who does that leave? I'm not sure what Suse's release schedule is, but based on the above, the first mainstream distro with GNOME 2.6 in a release will be either Fedora Core 2 in May, or Mandrake in August or September. That is, unless Debian decide to have a surprise stable release in May or June with GNOME 2.6 in it. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Print plugin for 2.0
Hi, Robert L Krawitz wrote: Does 2.0 have any functioning print plugin? If not, what changes need to be made to the current 4.2-based plugin? As far as I know, if you have gimp-print 4.2.x installed, it will be used for the gimp-print plug-in. The plug-in has been updated to the 2.0 API. It would be nice to have the plug-in updated to 4.4.0 when it comes out (which should be any day now, I think) - in fact, if 4.4 comes out this week, it would be nice to be able to use that for The GIMP 2.0 (imho). Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Print plugin for 2.0
Hi, Robert L Krawitz wrote: I'm the Gimp-Print project lead, that's why I asked the question :-) I know :) Sorry to hear the 5.0 release is still a bit away. In the 5.0 tree, the plugin has been split into two pieces, a UI library (libgimpprintui) and the GIMP plugin proper (which is tiny, and contains all of the GIMP-specific code). We should work out the appropriate ownership of of these two components, and the correct dividing line. It would be really great if you would continue to maintain the gimp-print plug-in that's in GIMP CVS. Understandably, since gimp-print is now very much its own project, our release schedules aren't going to match up for the most part, but currently the goal would be to support the latest stable release of gimp-print in the GIMP. Having 2 GIMP plug-ins (1 in gimp-print that's based on the last stable GIMP and another in the GIMP that's based on the last stable gimp-print) doesn't really make sense. I would propose that the gimp-print plug-in gets updated in the GIMP tree when the libgimp API changes, and then gets updated to use the new gimpprint when a stable release comes out. What do you think? Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Questions from Hungary
Hi Balazs, Márton Balázs wrote: So, dear guys, I have a big question: Is there somebody, who is already working on GIMP's hungarian translation? I saw the translation of version 1.1, but it's very incomplete and a lot of the messages are still in english. And if I can cooperate with my work: where can I find the latest version's .PO file? This is great to hear, thanks for the offer. The translations of the GIMP are done by the GNOME i18n team and the head of the Hungarian team is listed as being Szabolcs "Shooby" Ban (shooby at gnome dot hu) - I'm sure he'd be pleased to hear from you. The latest po files for the GIMP are in GIMP CVS (in the directories po, po-libgimp, po-plug-ins and po-script-fu). Thanks again, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Press pack
Hi all,
So, over the weekend I did some work on the press pack, mainly re-wording some
thing in the article (there are some things I removed too) to get to a 4 page
article. The article, with screenshots, is online at
http://scrappy.ath.cx/~bolsh/ - the article itself is in presspack.pdf (1.1MB),
the latex input file is in presspack.tex, and the screenshots for the article
are in that directory too. To re-generate the article, you'll need a recent tex
& latex version (I made it with RedHat 8), and you'll need to convert the pngs
to epss - I did this with
for i in *.png; do
convert $i ${i}.eps
done
So - there we go. I have a copy here, and I think it looks pretty good. The text
might need a bit more work, and if anyone wants to comment, they are free to do
so (currently the wiki is down, but I will put the revised text in a different
wiki page, WhatsNewBolshEdit, since I've changed quite a lot). Some of what I
removed were tutorial type key-sequences and some details which I didn't think
fitted well with an introduction article.
Currently there are creditted authors - I think in the final version there
shouldn't be. And the credits do not include the number of people who modified
or improved the wiki page, since I don't have that list.
So - there we go. Any reccommendations before 2.0 should go here, or to the wiki.
Cheers,
Dave.
--
Dave Neary
[EMAIL PROTECTED]
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Press pack
Hi, Roman Joost wrote: On Mon, Mar 15, 2004 at 05:26:34PM +0100, Dave Neary wrote: you'll need to convert the pngs to epss - I did this with May I suggest, that 'pdflatex presspack.tex' will do the job very quickly without converting the png's into eps files. Yes you may - except brix got there first :) You learn something new every day. Using pdflatex messed up the figure scales though, and made the pdf file bigger. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp.app application bundle
Hi Aaron, Aaron Voisine wrote: I have a self contained application bundle for the gimp on os x. Would this be of use as a binary download for the mac? Thanks a lot, this could be great. We have a kind of policy of not providing "official" binaries (it's simply a question of resources), although I would like to see us build up a set of external binary download links (like Tor and Jernej's sites for Win32) for mac, and the most common Linux & Unix file formats (.deb, .rpm, Mandrake .rpm, .pkg) - would you be happy doing this? Can we provide a link to your download page from the gimp.org downloads page? It seems like it would be useful for the greater gimp using community as the current method of getting the gimp on mac is ... I agree, mac users expect things on a platter. I don't have the bandwidth to host a publicly available download. What's the best way to make this available? Ah... Do we have any volunteers willing to host mac binaries for free downloads? Thanks a lot for this. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The Mark Shuttleworth offer
Hi Dan, Daniel Rogers wrote: More details have come forward about the Mark Shuttleworth offer. Mark Shuttleworth made up his mind and decided to fund myself and Calvin to work on GEGL and GIMP/GEGL integration. Congratulations! :) Also, I want to prepare a press release about this, and would like some help with that. I can write the content, but those current press releases are so purty, and I'd like any new one to look like them. Can I suggest that you talk to Mark? He has more PR experience than any of us, and I'm sure that he would have some ideas to offer for a press release. 3. begin gimp integration () Time for completion: about a month -- a. replace tile manager with data compatible GeglBufferedImage. This involves modifying the existing gimp-compositing system to use GeglImage, as well as modifying GimpImage and GimpColor to use GeglImage and GeglColor. > 4. start adding deep paint () time for completion: about 4-6 months -- a. modify GimpImage and GimpLayer to use a set of GeglOps. -- a. design a new file format (this has already begun), and start converting all the plug ins, core, and paint to use high bit depth (16 bit or float). If you started 3 after 2.2, that would have a 3.0 milestone somewhere around here. Can I check, then, what exactly will get done here? Do we keep a PDB compat layer around so that plug-ins that don't get changed still work, but only on 8 bits per channel? Do we declare teh milestone complete when the core has support internally for floating point, so that only tools get converted first, and we start working on plug-ins afterwards? I think that you're probably underestimating 4 by a bit, particularly since we will want a stable release at this point, which will mean (probably) a 3 month pre-release cycle like the one we've just had. Completion in 6 months is possible (with all plug-ins, I'm not sure), but that would make the 3.0 release next Summer - does that sound reasonable? We could even consider having a quickish stable release after 2.2 with just GeglImage replacing GimpLayer, which would give us a chance to work out any wrinkles in that milestone before we start really relying on it... 6. The big ones () Goal: start adding some long wanted features. a and b probably need to take place at the same time. () time for completion: about 6 months -- a. build the CMYK painting system. This will involve figuring out all the equivalent CMYK and RGB operations, and modifying the GIMP to use CYMK equivalent operations in place of RGB operations. -- b. add color management to the gui. -- c. add layer effects -- d. add layer groups. -- e. add clone layers. Cool - this sounds like a plan. At what stage do we turn plug-ins into nodes and replace the PDB with a node handler? I know that corba's a bad word, but how will plug-ins work after that? Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
Hi, Sven Neumann wrote: now that 2.0.0 is released, it's about time to make some plans for the future. IMHO, we should try to come up with a roadmap that is clear and detailed for the next months and reasonably vague for the time thereafter. We can then make precise plans for the time after 2.2 at GimpCon. I think we should have a good chat now about post-2.2, since the work of others in the meantime (Dan and Calvin) will depend on that plan. But that can be sufficiently vague as "Dan's plan sounds sane, we'll go that way", and set up 3 or 4 major milestones after 2.2 when we can do stable releases. - Do a 2.0.1 release in about two weeks. And IMO we should not branch CVS before 2.0.1 is released. Agreed. - 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. One example of something which would definitely miss 2.2 if we release in June is libpdb, and I doubt that a preview widget would make it in either (it would depend on the amount of free time David Odin has, and how well he can co-ordinate with Ernst). I wouldn't be able to commit to getting the pretty small feature I said I'd do in that time scale either, particularly with gimpcon preparations underway. Setting up a 3 month release cycle sets us up for GTK+ 2.4 migration, committing outstanding features with patches attached, and maybe re-arranging the menus again. I don't see any major features going in in such a short cycle. Plus one of the objectives of 2.2 was to have complete coverage for docs - that seems unrealistic for June. I would prefer to see us set ourselves up for a 6 month cycle and stick to it, rather than a 3 month cycle that we know is going to end up as 6 months in the end. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP 2.0.0. out, gimp.org dead?
Hi, Nathan Carl Summers wrote: On 25 Mar 2004, Sven Neumann wrote: IIRC the URL is either http://www.gimp.org/~tml/gimp/win32/ or http://www.gimp.org/win32/. Yeah, I know that. That url wasn't working either. Now it is. Perhaps some cache needed to expire. Still not working for me. wilber.gimp.org/~tml... works fine. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP 2.0.0. out, gimp.org dead?
Hi, Sven Neumann wrote: Either your DNS is stale or Yosh is moving the server again. Stay calm. In the end it will all work. I'm very calm :) It was just a piece of information. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
Hi, Manish Singh wrote: 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. I think that if it's done, and works correctly, and is useful, we should use it. I think we should avoid the temptation to think 1 release ahead - you say that it'll only live for 1 release, but that release might be around for a long time. At one stage there were similar things said early in the 1.3 release cycle (the effort on thing X wouldn't be worth it because it would be superceded by gegl anyway) - I don't recall exactly the features in question, but layer grouping comes to mind as one of the things suggested a couple of years back that is, imho, doable reasonably nicely with the current core. The PDB redesign is vaporware, and might not even be done before gegl gets integrated. If libpdb helps in the meantime, I'm all for it. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] ANNOUNCE: Pre-releases for Perl bindings, Help pages and GAP + Win32 installer
Hi Tino, Tino Schwarze wrote: Is there a dedicated mailing list for Gimp-Perl? I had troubles installing this... It doesn't seem to work with the latest ExtUtils::Depends ... And I'd like to have all these perl plug-ins back! As far as I know there isn't (although Marc might correct me) - here is the best place. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
Hi, Sven Neumann wrote: Helps for what? If libpdb is not our PDB redesign, what is it then? What is it? Rock? I may be misunderstanding what it is, but I understood that libpdb was an extra layer between the existing (unchanged) PDB and plug-ins which allowed things like named parameters, and sockets rather than shm for plug-in/core communication. Aside from those 2 things, I know nothing about it except that someone is actively working on it, and that person was under the impression that it was scheduled for inclusion in 2.2. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-web] Re: [Gimp-developer] ANNOUNCE: Pre-releases for Perl bindings, Help pages and GAP + Win32 installer
Hi Carol, Carol Spears wrote: On Fri, Mar 26, 2004 at 04:27:13PM +0100, Dave Neary wrote: Tino Schwarze wrote: Is there a dedicated mailing list for Gimp-Perl? As far as I know there isn't (although Marc might correct me) - here is the best place. seth burgess has been working on this. thanks for your answer, however, mr. neary. articulate and wrong. As I said earlier - both Seth and Marc are here, and there is no standalone gimp-perl list. So how exactly was my answer wrong? Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
Hi, Joao S. O. Bueno wrote: would it be too troublesome to call this release that will just finish things that have started, as 2.0.X series, instead of a 2.2 ? IMHO, that would be fine - but the "just finish things" won't just finish things, it will add smallish features too. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
Hi William, William Skaggs wrote: If you plan for three months, it will take nine months, so you should plan for three months. If you plan for six months it will take over a year. Feynman's Law: Everything takes twice as long as you expect it will, even when you take into account Feynman's Law. The problem is that if you go way over schedule (that is, if we say 3 months, and we're still not at 2.2 in 6 to 8 months time), you end up moving to a feature-based thing. People start working on things which hadn't been planned and you end up with so much schedule creep that the old schedule is eventually ignored and forgotten (I think in 1.3 this happened sometime at the start of 2002, although I wouldn't be able to put my finger on a particular event). At which point you need to come up with a new plan. I could be convinced that having a release in 3 months is the right thing (I am under no illusions though - if I disagree with it, that won't necessarily influence the eventual decision). It would depend on the feature lists we compile over the next few days/weeks. But I would be worried that if we set off on too short a cycle that people will not start features which won't be done in 6 weeks. And we might only end up with 2 or 3 people working on 2.1.x, which would be a shame given that we are getting more & more people contributing code at the moment. I'm agreed that if we have features without someone to write them that they shouldn't hold up a 2.2 release, though. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
Hi, Sven Neumann wrote: I suggested that we make a list of changes for 2.2, so I sat down and tried to come up with such a list. This list is not meant as the list of things that need to go into 2.2 but it's a list of things that could go into 2.2. A prerequisite for each item is that someone volunteers to work on it. And of course the list is by no means complete. Please send a mail if you want to see items added. I would still like to do this one: Allow creation and editting of patterns in the pattern dock, as well as a "Save as GIMP pattern" menu entry which automatically saves the image as a .pat in .gimp-2.0/patterns http://bugzilla.gnome.org/show_bug.cgi?id=132208 The latter part (save as GIMP pattern) would be trivial, more or less. Handling the semantics for creqting new patterns in the pattern dock and duplicating/editting existing patterns is trickier. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
Hi, Sven Neumann wrote: Dave Neary <[EMAIL PROTECTED]> writes: The latter part (save as GIMP pattern) would be trivial, more or less. Handling the semantics for creqting new patterns in the pattern dock and duplicating/editting existing patterns is trickier. Well, there is already a menu entry for saving an image as GIMP pattern; it's nicely handled by a simple Script-Fu. That's good news, I'd suggest putting it in the File menu then. Really, I don't see this as an urgent issue, but sure, if you want to duplicate the image editing functionality of GIMP in the pattern editor, give it a try. I see this like Guillermo - creating a new pattern should bring up the new file dialog, and save the new image silently with an automatically generated filename and a .pat extension. That way, when you click on "New pattern", you get a new image dialog which you handle as usual, and then the .pat "Enter pattern name" dialog to save the pattern. It could be nicer, but I think that's sufficient. Duplicate is, as Guillermo said, just a copy (well, not quite - I'd see it more like the duplication of a gradient works, and use the GIMP Item code to do it). Editing a pattern is just opening the file. Almost trivial. Dragging & dropping images to the pattern dialog is a different matter, and a little more complicated. The reason why these shortcuts are interesting is because they make making custom patterns obvious for people who don't want or need to know about the contents of .gimp-2.0. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
Sven Neumann wrote: Hi, Dave Neary <[EMAIL PROTECTED]> writes: I see this like Guillermo - creating a new pattern should bring up the new file dialog, and save the new image silently with an automatically generated filename and a .pat extension. That way, when you click on "New pattern", you get a new image dialog which you handle as usual, and then the .pat "Enter pattern name" dialog to save the pattern. It could be nicer, but I think that's sufficient. You will run into problems as soon as people start to use multiple layers, channels, layer masks and the like on the pattern image. Not at all - Ctrl-S or File->Save will go through the pat plug-in which will propose the conversion. It's no more of a problem than if I save something as a pattern now and then add a layer. The reason why these shortcuts are interesting is because they make making custom patterns obvious for people who don't want or need to know about the contents of .gimp-2.0. I see your point. But you don't really need to know about .gimp-2.0 in order to use Script-Fu->Selection->To Pattern. I just tried this, and it didn't appear to work. At least, I didn't see my pattern show up in the pattern list after doing a refresh. As I said, that's the easy part, though - making stuff in the patterns dialog act sanely is a little trickier. It would definitely be better to have this script in File->Save as GIMP Pattern though. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Adjustment-layers in GIMP?
Carol, Carol Spears wrote: On Fri, Apr 02, 2004 at 02:46:24AM +0200, Baard Ove Kopperud wrote: I'm not 100% sure I understand your question, but I'll try to explain how it works (from the users pov) in PS... okay, i am at a disadvantage here as i am not a photoshop user nor a gimp developer -- however, i will try to describe what the developers need before they will help you. You are hardly an authority on this. This feature has long been on the TODO list of the GIMP, but it has not yet been done. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Adjustment-layers in GIMP?
Hi, Carol Spears wrote: On Fri, Apr 02, 2004 at 11:36:19AM +0200, Dave Neary wrote: Carol Spears wrote: okay, i am at a disadvantage here as i am not a photoshop user nor a gimp developer -- however, i will try to describe what the developers need before they will help you. You are hardly an authority on this. This feature has long been on the TODO list of the GIMP, but it has not yet been done. > not an authority about what -- that i am not a photoshop user or that i am not a gimp developer? Not an authority on what the GIMP developers need before they will or will not help someone. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] preparing the 2.0.1 release
Hi all, Sven Neumann wrote: we said two weeks for 2.0.1, so that'd be this tuesday. Some time has been spent on the 2.0.1 bug list this weekend but still there's quite a list. I just created the 2.0.2 milestone in Bugzilla. I think that we should start thinking about ways to tidy up bugzilla somehow - in theory we should only have 2 or 3 active milestones (2.0.x, 2.2, Future, say) and we should be getting rid of a bunch of older 1.3.x releases, if possible. We currently have over 30 versions and 10 milestones which is making bug entry more complicated than it has to be. I agree that all the bugs you suggest bumping should be bumped. Getting the bug fixes we have already done out there is more important. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] GIMP presence on guadec.org site
Hi all, Things are moving along nicely on the GUADEC front, and the new web content for the site is almost ready to go live. One thing that we're missing at the moment is some GIMP content for the site. The GUADEC team are happy to give us a presence on the front page, with a link to GIMPCon resources. Jimmac will do a GIMPCon icon and we have a 2 or 3 line paragraph on GIMPCon, with a link through to a guadec GIMPCon site (basically, the list of gimp-related talks, and links through to the developer.gimp.org GIMPCon pages). Does anyone have any ideas or preferences for the type of content we should have? How about improvements to propose for the dgo pages (which are pretty sparse at the moment)? For everyone's information, 4 GIMP-related papers were accepted to GUADEC - Simon Budig on the future of vector imaging in the GIMP, Dave Neary on programming GIMP plug-ins, Dan Rogers on gegl and the GIMP, and Oyvind Kolas on gtk-cairo widgets (not really a GIMP talk, but we'll claim pippin anyway). There are also a few other interesting graphics related talks - Liam Quin on typography and graphic design for programmers, Dave Coombes on WvSync (gstreamer internals talk), and Hubert Figuere, on Digital Photography in the GNOME environment. Oh, and Daniel Egger on docbook. So all in all, looking interesting. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp usability tests
Hi Roman,
Roman Joost wrote:
Well, i think first a bit to the background of upcoming Usability Tests.
I met Ellen Reitmayr at the GIMP 2.0 Release Party in Berlin and she is
involved in some Usability studies for the KDE Project (with the whole
company relevantive AG). After some discussions about the KDE Usability
tests, we agreed, that some Usability tests for the GIMP would be nice
for having feedback to the developers from some usability experts.
This is excellent news, and an excellent initiative.
I've added [EMAIL PROTECTED] to the CC list for their feedback too, and left
the entire mail intact.
Thanks for doing this, Roman, and I'm looking forward to seeing the results.
Cheers,
Dave.
I met Ellen again and we put some tasks for people who are new to
the GIMP and poeple who consider to change from photoshp to the GIMP.
Ellen wrote the draft that you'll find below. It's considered as a
basis for comments and suggestions to improve the usability of the GIMP
interface. It should not test the functionality itself and issues
already known as bugs. The test should be as effective as possible with
the 4 users and the mostly common tasks.
The first test consists of 4 persons and deals only the 'all-day-use'
with the Gimp (what is the handling of the application like, how good
can one achieve a task etc.). Later, we want to conduct a more extensive
test that will also consider the users' understanding of the common
concepts, such as layers, paths etc. - and how the new user could be
helped to learn these basic concepts (that would be nice to know for the
gimp-help-2 module to get the manual as effective as possible for
helping the user).
The GIMP is the SuSE package of the GIMP 2.0 with the german language
enabled.
Tasks for the first test (all-day-usage; all of the are common tasks for
all people, except the one where the indicated group is mentioned):
1. Create a rectangular selection and subtract the edge of the created
selection.
a) Were the necessary modes found?
b) Does the user select the modi in the right sequence to achieve the
goal. ('Replace a current selection', then use 'Subtract from the
current selection')
c) Does the user know, that the starting point of the subtract selection
has to be placed outside of the current selection and not inside the
selection itself.
2. Create a selection with fixed width and height and a fixed aspect
ratio.
a) Does the user find the right input field.
b) Does the user understand 'Fixed Aspect Ratio' or the german label:
'festes Seitenverhaeltnis'.
3. Selection by color, fill an area with a pattern and cancel the
selection.
a) Does the user find the right tool in the toolbox or in the menu?
b) Does the user know how to fill the area with the patterns?
c) How to cancel a currently activated selection?
4. Measure how long a distance between some image objects is.
a) Does the user find the right tool in the toolbox or in the menu?
b) Does the user find the value directly?
c) Where does the user look for the value? At the statusbar or at the
info window?
5. Clone an image object with the clone tool.
a) Does the user find the right tool in the toolbox or in the menu?
b) Does the user understand how to indicate the starting point for the
clone tool?
c) Does the user choose the right brush from the brush browser?
6. Transform image objects.
The photoshop user should create a layer and shear it with a value for
XX pixels.
The new user should only shear the whole image.
a) Does the user find the right tool in the toolbox or in the menu?
b) Is the user able to use the grid for shearing?
7. Use the color picker to get the color info with sample merged
enabled.
a) Does the user find the right tool in the toolbox or in the menu?
b) Does the user know why the color which is shown in the image window
is not the same which the color picker gets from the layer?
c) Does he know how to find the checkbox to enable the 'Sample Merged'
function?
8. Using the undo history.
a) Does the user find the journal directly?
b) Does the user understand, how to undo single steps?
9. Add an image grid and change the distance of the grid points.
a) Does the user find the image grid function?
b) Does the user find the image grid preferences in the preferences
dialog?
c) Does the user find the correct option for changing grid preferences?
10. This task is only for photoshop professionals. They should use the
path tool to create a cloud and stroke it with some patterns.
a) Does the user find the path tool?
b) Does he know how to use the path tool?
c) Does he know how to stroke the created path with a pattern?
11. Try to dock some tabs into the docks.
a) Does the user understand that only tabs can be moved betweend docks
and not the docks itself.
b) Does the user find the active area, where he can drop the tab to the
dock.
Thats all of them. In hope it would be useful,
Greetings
--
Dave N
Re: [Gimp-developer] Gimp usability tests
Hi Simon (and Brix), Simon Budig wrote: Roman Joost ([EMAIL PROTECTED]) wrote: 1. Create a rectangular selection and subtract the edge of the created selection. c) Does the user know, that the starting point of the subtract selection has to be placed outside of the current selection and not inside the selection itself. c) is not necessary. When pressing CTRL you can happily subtract stuff starting inside the current selection (otherwise it would be impossible to create holes in the selection) I know we're correcting the usability expectations with these comments, but somehow they have already highlighted some usability concerns - if the people doing the usability tests, in consultation with someone pretty familiar with the GIMP, isn't aware of these things, it might indicate that this is non-obvious (for example, the separation of the default grid and the grid in the current image is one which is not obvious, similarly, selection handling with modifier keys is not obvious). If I understood correctly, the objective of this exercise is to see if people find the tool options, understand the icons, and understand what the changing cursor means. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Gimp 2.0
Hi Marcus,
I'm forwarding your mail to the developers list for two reasons.
First, it's a major problem that people feel obliged to mail people off-list
because they are "safe" to talk to and this is something that we need to talk
about urgently. For the benefit of the people on the list, this is not the first
time this has happened. It seems like I get mail from people weekly from people
who have valid points to raise, but are intimidated by the list.
Second, I have been very occupied recently in real life, and will have very
little time to consecrate to the gimp over the coming months, so I'm sure that
there are other people better placed to answer your queries.
For that reason, I'm leaving your entire mail intact, as well as adding my
comments inline.
Regards,
Dave.
Markus Triska wrote:
Dear Dave!
First, let me explain my greatest thanks and admiration for Gimp 2.0. You all
did a great job.
I'm writing you because from following the mailing list I got the impression
that you are someone that I can contact "safely" with my issues:
I have beein playing around with Gimp for some time now, and one procedure I
apply every once in a while is to make a copy of each visible layer and merge
them to a new one (as a means comparable to "CVS tagging" - to mark and save
a stage of development). In fact, I have beein wondering why this is not an
option in the layer context menu (like "copy visible and merge those") - is
there maybe a better way to do this? I use it also when I need a filter to
operater on the whole picture ("all layers").
I don't see a way that this could be nicely implemented in the interface -
"duplicate all layers" doesn't seem like an operation which would be very common
or useful for most people, but perhaps a "merge visible layers (and keep old
layers) option would be useful...
As an aside, applying a filter to several layers at once works would be useful,
and should (in the first instance) work on linked layers, and later work on
layer groups (when we have them). The best way to have this scheduled by someone
is to create a bugzilla report for it, and bring it up here on the list for
implementation ideas and advice.
Also, I find the picture of the wet baby in the "Screen Shots" section rather
annoying. I mean, it's not the baby's fault, but I think that with all the
stuff going on in Europe (Dutroux), placing a half-naked kid with amateur
lightning in this section is not a matter of particularly good taste. Maybe
it would be good to show more neutral photographs, like skies and landscapes
etc. that are bright and where's much to look at.
The baby is my son, I didn't think of any negative connotations, but indeed I
wasn't thinking "that way". Given your comments and the way you saw it, I will
take them down. I'm not sure where screenshot submissions should go though -
perhaps someone else will pipe up with ideas about that?
Best regards,
Markus Triska.
Cheers,
Dave.
--
Dave Neary
[EMAIL PROTECTED]
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Gimp 2.0
Hi, Sven Neumann wrote: Dave Neary <[EMAIL PROTECTED]> writes: I make a copy of each visible layer and merge them to a new one. I have beein wondering why this is not an option in the layer context menu (like "copy visible and merge those"). There is Selection->Copy Visible which essentially does just that. I would never have found that in a million years. Would it be possible/desirable to duplicate this function in the Layers menu (Layers->Copy Visible or wherever) which creates a new layer which is a combination of the visible ones? The baby is my son, I didn't think of any negative connotations, but indeed I wasn't thinking "that way". Given your comments and the way you saw it, I will take them down. Please don't take the pixture down. It's ridiculous to say that putting such a picture on the internet will cause children to be abused. People who abouse children are sick; not showing them baby pictures won't change that. The picture is in no way offensive and anyone who draws a relation to the Dutroux tragedy is either sick himself or overly cautious. Of course it's your choice what to do since it's the picture of your son. But I don't think there's any reason to take it down. I took the screenshot down, and perhaps I should explain why in light of Simon and Sven's comments... when I read this mail, I got defensive a bit - the thought that someone thought the photo could be viewed sexually kind of turned my stomach. So I took it down. Anyway - people kind of missed the whole point of me sending that to the list... this person mailed me off-list because he saw me as someone "safe" to talk to. That's not a nice way to have things on our mailing list. What can we do to change that? Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Gimp 2.0
Hi, Sven Neumann wrote: There is Selection->Copy Visible which essentially does just that. I don't have a "Copy visible" entry in the Selection menu. Is this in 2.0.x or in the HEAD? Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Gimp 2.0
Hi, David Gómez wrote: I'm not sure where screenshot submissions should go though - perhaps someone else will pipe up with ideas about that? I think the actual policy is ok, to put good screenshots, not politically correct ones. My point was that I'm not sure what the policy for getting screenshots on the website(s) is. That is, where to send them, where that's documented and so on. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Gimp 2.0
Hi, Sven Neumann wrote: Dave Neary <[EMAIL PROTECTED]> writes: There is Selection->Copy Visible which essentially does just that. I would never have found that in a million years. Would it be possible/desirable to duplicate this function in the Layers menu (Layers->Copy Visible or wherever) which creates a new layer which is a combination of the visible ones? "Selection->Copy Visible" is next to "Selection->Copy". That's IMO the perfect place and it does certainly not belong into the Layer menu. You might not have noticed, but there is no "Layers" menu at all. Still don't see it. I thought the Copy & Paste items were in the Edit menu anyway? And my point is that I would never have associated "create 1 layer containing the merging of the visible layers" to be in the Selection menu. That is clearly (for this usage) something you expect to find in the Layers dock context menu, and perhaps the Layer menu. You still haven't said if this is in 2.0.x or HEAD - if you're talking about HEAD, then I am not able to verify what you're saying. Where was this reorganisation of the menus discussed? Or if it wasn't discussed, where's the document outlining how it will be now? Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Gimp 2.0
Markus Triska wrote: Again, I have to point out that I never intended to send the mail that Dave quoted to the list - I only thought that he would understand the issues I raised, and right I was. I owe Markus a public apology for forwarding this on to the list. In fact, the baby part of the mail was way down at the bottom of the reasons I did so. The main reason (as I've already said) is that it illustrates the point that this list is intimidating. The second reason was to expose the technical issue to a larger audience (which it did, and that is now resolved). I intended to start a discussion on what we could do to make the list a friendlier place, and not one on censorship or sexual standards (which, while perhaps more interesting, is less useful to this community). With that in mind, the "correct" thing to do would have been to answer Markus's mail personally, and copy the appropriate section only into a separate mail to the list, conserving his anonymity. That I didn't do that has, apparrently, made the list an even more intimidating place, and I now have to accept that I have aggravated the problem I was hoping we could address. I should have followed my own advice, and considered the person who sent me the mail before I mailed to the list. I apologise for not having done that, and ask Markus to excuse my behaviour. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] what's wrong about this list [was: Gimp 2.0]
Hi, Sven Neumann wrote: So IMO the things we need to consider are: - how can we make gimp development more transparent? - how can we publish short and long term plans and roadmaps? - why is there no maintained user FAQ? - why is the mailing-list archive not working? Good questions... - A list of active developers would help, along with their domains of expertise. The GIMP's been around for nearly 10 years now, and the full list of contributors doesn't really emphasise who's doing the main body of the work. - The roadmaps (when they change) should be announced on the list, stored on developer.gimp.org and linked to from www.gimp.org somehow. The roadmaps, IMHO, should be time based rather than feature based (as we have discussed in the past), and should aim for roughly 3 timescales 1) near-term: next 6 months 2) medium term: Next 12 to 18 months 3) Long term: major goals not covered in 1 or 2, with how to get there (a brief list of prerequisites). In our context, that would mean 1) Plans for 2.2 2) Plans after 2.2 (notably, gegl integration, and whether that's realistic for 3.0, and to what level) 3) Other stuff. I think we should also have "projects" which can proceed independently of these - things like the usability tests can have their own schedule, with perhaps a developer who agrees to blindly put in place agreed reccommendations. Also, we need to define a kind of general set of guiding principles - are we going for a minimalist GIMP with lots of stuff addable, but very little installed, or for a kind of all-encompassing GIMP? How are we going to finally handle the plug-in distribution problem? In the meantime, how do we handle requests for plug-ins to be added to the main distribution? Currently there is no way to handle them, which meansthat we get no requests, more or less. There are some really good plug-ins which could be added, I think. - I really have no idea why there is no maintained user FAQ. It seems like there is very much an idea that the users and developers are two distinct, disjoint groups. Perhaps we should be asking user groups to maintain a FAQ, and encouraging them to contact us if they have any problems. This kind of comes around to an older issue too. Years ago the GUG contacted someone (I don't know who) about having a user group space on www.gimp.org, and apparrently they came away from that with a bad taste in their mouth. Perhaps the time has come to try and re-build that bridge and see what we can give each other? - As to the mailing list archives, I guess yosh will have to answer that one. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Gimp 2.0
Hi, Carol Spears wrote: is this person with the smutty mind a developer? Perhaps you missed it, but he didn't mail the developers list. I did. And I shouldn't have. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Baby photos
Hi, Simon Budig wrote: Markus Triska ([EMAIL PROTECTED]) wrote: Maybe Dave can explain to you why he did so, and you can then try convincing him that he put the picture back, if this is what you want, but please keep me out of that. "Uh, this is getting too hot for me, let Dave pick the potatoes from the fire since he is the one who implemented my wish". How convenient. Please bear in mind the origin of the mail (me, not Markus). Indeed, as has been said, the original mail was the trigger - until I had received that mail it would never have occurred to me that the screenshot could be viewed sexually. After the mail, that thought did occur to me. Perhaps if it were me and not Thomas, I wouldn't mind, but, well, I don't apply the same standards to myself as I do to my behaviour with respect to my son. [1] Please note, that the removal of the image does not necessarily mean, that Dave agrees with your opinions on a rational level. His description of the events very clearly indicates an emotional reaction - this is by far easier to accept for me than your poking in the fog. Yeah, this is pretty accurate... in general I think baby photos are great, and I have no problem showing photos of Thomas to more or less anyone. But this discussion (or rather, the original mail) made me see a popular website's place in the internet slightly differently. I'd appreciate it if we could let this thread drop, though. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Volunteer needed
Hi J., J. Grant wrote: GNOME Foundation c/o Novell, Inc. 8 Cambridge Center Floor 5 Cambridge, MA 02142 USA Perhaps the country name could be added as well? Otherwise people may assume it is the first Cambridge (UK) or one of the other international cities using the same name. Good point. I'm not sure who's putting this up on the site, though. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Refactoring code from GPL to LGPL
Hi, Sven Neumann wrote: "Robin Rowe" <[EMAIL PROTECTED]> writes: I honestly am not sure what the process for moving code to libgimp is... essentially it is just moving the code to a library, and then adding a wrapper (if required) around those functions to expose them to the PDB. Good technical anwer, thanks. Well, the answer was technically incorrect since it's the PDB and libgimp that's a wrapper around code in the core, not the other way around. Oops. At least I qualified it by saying I wasn't sure what was involved :) My understanding came from looking at libgimpthumb, which was added into 2.0 - what's in libgimpthumb looks to me like a complete implementation of the thumbnail spec, as opposed to PDB wrapper code. Ah - looking at the gimp-2.0 binary it looks like we just link libgimpthumb into gimp-2.0, and let plug-ins link with it if they want, so it is pure implementation. How do you get permission to move GIMP code from GPL into LGPL? Basically we do this so rarely that is hasn't been a problem so far to get permissions from everyone who touched the code in question. Following what you (Sven) said in the previous mail, it also seems like the libgimp parts are independent of the original code, and calls the original functions via a PDB proxy, so licence issues wouldn't come into it. May I ask why you are asking these questions? I imagine it's because he wants to do the same thing... just a wild guess. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Refactoring code from GPL to LGPL
Hi Robin, Robin Rowe wrote: Good technical anwer, thanks. Apparently I got it wrong. Anyway - I just improved my understanding with a concrete example. Let's take gimp_layer_add_alpha() as the example (the function adds an alpha channel to an RGB background layer that doesn't have one yet). The implementation is in app/core/gimplayer.c. In app/pdb/layer_cmds.c (still in application space), we have a wrapper function (layer_add_alpha_invoker), and a procedure which we register with the PDB (layer_add_alpha_proc), which registers the _invoker function as the "run" callback. Finally, in libgimp/gimplayer_pdb.c, we have the wrapper function which is called in plug-ins. This calls gimp_run_procedure on the procedure above, and invoked the core code as a direct result, as with a normal user-defined PDB function. Core types and enums are wrapped automatically by the perl scripts in tools/pdbgen (although this is somewhat black magic to me). I'm also wondering from a license standpoint. The code in app is GPL, but libgimp is LGPL. Given the above, the core code is GPL, the app/pdb code is GPL, and libgimp/* is LGPL, so there are no licence issues. Hope this clears everything up, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Refactoring code from GPL to LGPL
Hi, Sven Neumann wrote: Dave Neary <[EMAIL PROTECTED]> writes: Following what you (Sven) said in the previous mail, it also seems like the libgimp parts are independent of the original code, and calls the original functions via a PDB proxy, so licence issues wouldn't come into it. Well, there are license issues when a non-GPL application makes calls to GPL-ed code by whatever means. I don' think this is an accurate representation of the issue. It certainly doesn't tally with my understanding. That said, I'm no expert. But let's take an example... I write a GPL network daemon (say red carpet). Someone write a non-GPL compliant client (say an LGPL encapsulation of the RedCarpet XML-RPC protocol to allow proprietary implementations). Now that library is calling GPL code, albeit via a network protocol. Is the client library in breach of the GPL? How about if the relationship is via an ORB? A GIMP plug-in is a completely different process space than the GIMP core. Information is passed via a wire protocol which is implemented at both ends using LGPL code. I don't see how this is different from viewing the GIMP as a server, and the plug-in as a client. Or alternatively, the PDB as a broker and both the plug-ins and the rest of the core as clients. This is a difficult subject and it's hard to judge if a plug-in should be considered part of the GIMP application (which would mean that the GPL applies) or if it's a mere aggregation as per section 2 of the GNU General Public License. Our position on this is outlined in the file LICENSE which is included with the GIMP source tree. While the exemption in the LICENCE file does indeed clear up any possible confusion, I'm not sure it's necessary. What it also clears up, though, is that there are no licence issues with exporting a core procedure to the PDB, and wrapping that procedure in libgimp, which was the case in point. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] GPL discussion (was something else)
Hi, I guess since we explicitly exempt libgimp and plug-ins, this discussion is purely of academic interest. Anyway - it interests me enough to ask a couple of questions. [EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) wrote: On Wed, May 12, 2004 at 01:12:03PM +0200, Dave Neary <[EMAIL PROTECTED]> wrote: Now that library is calling GPL code, albeit via a network protocol. Is the client library in breach of the GPL? Well, that's what the license says: The "Program", below, refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term "modification".) I've read and re-read this, and I'm having trouble figuring out how anyone can consider a network client as being a derivative work of the server. The client does not contain any of the server. The server exposes an API using an open protocol, and the client formulates requests to the server, and gets a response (still using xml-rpc as the example). At no stage does the client contain part of the server. The client can exist with an alternate, non-GPL implementation of the same server with no change (similarly, someone could conceivably use libgimpwire to implement a simple plugin-based batch processor and use the existing farm of GIMP plug-ins with no changes). The client and the server are distinct entities. Somewhere along the line, I don't get it. But that's OK :) So I hope it's very clear now that "it depends". Ummm.. no. And getting unclearer all the time. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Volunteer needed
Hi, Update on the paypal details. The form to be added to the web page to allow one-click donations is this: https://www.paypal.com/cgi-bin/webscr";> http://www.gimp.org/sponsors/thanks.html"; name="return" type="hidden"> Is anyone currently working on the web pages? A reply from someone who is with a "yes, but I don't have time" would be fine, but the absence of response to my last mail is worrying me. I'm quoting the entire previous mail, in case anyone missed it. Do we have a web team any more? If so, who's on it? Cheers, Dave. Dave Neary wrote: So - here's the request: The following information needs to be added pretty quickly (and prominently) to the webpage, so that we can start advertising the ways to fund the GIMP around community sites. Is there anyone with the time to do this today or tomorrow? I won't have time to do this (even if it's pretty small) until next week, at the earliest. Thanks, Dave. = Fundraising info to add to the webpage === Donating money to the GIMP is easy! The guys at the GNOME Foundation have graciously agreed to act as fiscal agents for us, which means we can offer tax deductible donations in the US. There are 3 ways to support the GIMP financially, and get as many of the GIMP Developers as possible to the GIMP Developers Conference, taking place in Norway as a sub-event of GUADEC at the end of June, as well as expenses associated with the establishment of the GIMP Foundation: 1) Cheque, made payable to the GNOME Foundation, and sent to GNOME Foundation c/o Novell, Inc. 8 Cambridge Center Floor 5 Cambridge, MA 02142, USA with a cover-letter (or a note in the "memo" field) saying it is for the GIMP. You can additionally send a mail saying that you have donated to [EMAIL PROTECTED], if you want to. 2) Wire transfer Send an email to [EMAIL PROTECTED], requesting bank details, and specifying that you are donating to the GIMP. 3) Paypal Donate to [EMAIL PROTECTED], this will notify us, and the GNOME board, that funds have been donated to the GIMP. Credit card donations are also accepted via this route. Please indicate whether you would like your donation to remain anonymous, as otherwise you will be listed as a sponsor of the GIMP on the gimp.org web-pages. Note: The following can be added to allow a paypal donation to be just one click from the website (the page http://www.gimp.org/sponsors/thanks.html should exist with a short thank you message, otherwise the "return" field should be omitted): https://www.paypal.com/cgi-bin/webscr";> http://www.gimp.org/sponsors/thanks.html"; name="return" type="hidden"> I've attached donate.png, which is directly taken from www.gnome.org/friends. Alternatively, we can use the paypal icon like this... https://www.paypal.com/images/x-click-but04.gif"; type="image"> ...but since we're not getting anything from paypal, perhaps the neutral one is better. Thanks a lot, Dave. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Refactoring code from GPL to LGPL
Hi, Robin Rowe wrote: "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/ This is exactly what happened to the code in /app between 1.2 and 2.0 - its internal structure changed drastically, without reducing its external behaviour. Although of course, not only was the code refactored, quite a few features were implemented with the new structure too. What I am saying is that moving redundant code out of application space into libraries is a significant component of refactoring. I would rather say that the modularising of an architecture, the separation of distinct functionality into distinct modules, is an essential part of refactoring. Putting this functionality into a library is simply a matter of passing the linker the right flags. 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). Actually, shared memory. But it amounts to the same thing. It's all IPC. Appreciate the clarification. No problem :) Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GPL discussion (was something else)
Tor Lillqvist wrote: [EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) writes: > According to you, this shouldn't be. Additionally, one would assume that > these are additional restrictions that are explicitly forbidden by the GPL > itself. But these restrictions are placed by the MySQL copyright holders themselves, aren't they? It's those who *copy* (download, install) and redistribute MySQL that the license applies to, and it's they who can't add any additional restrictions. Or am I confused...? For a licence to be considered GPL, it can impose no further restrictions beyond what is in the GPL, excluding exceptions which are explicitly allowed (linking to library X, for example). Of course, the copyright holders can place the software under any licence they see fit. Including the GPL, but also including weird GPL hybrids. But since the MySQL copyright holders say that the licence is GPL, I suppose they get to have some say in what they consider to be a derived work. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
