Re: Toolbox (interface.c) Solaris x86 probs
Nem W Schlecht [EMAIL PROTECTED] I'm having a couple problems w/ gimp-1.1.x that I've been trying to figure out. The Gimp toolbox doesn't come up correctly (there is "blank" column on the right hand side), and each successive time I run the Gimp, the toolbox gets smaller and smaller. Hi, I reported the shrinking behaviour as bug Bug#9683. I'm thinking it must be CDE on Solaris now! Keith.
gimp-plugin-template questions
What is the purpose of including src/plugin-intl.h in the template? Does #include "plugin-intl.h" do something that #include libgimp/gimpintl.h does not? How are individual user installations supposed to work? (is there a target that installs to ~/.gimp?) are config.sub and guess necessary for most plug-ins? Thanks, - Kevin -- Kevin Turner [EMAIL PROTECTED] | OpenPGP encryption welcome here Plug-ins: They make GIMP do stuff. http://gimp-plug-ins.sourceforge.net/ This list is archived at http://marc.theaimsgroup.com/?l=gimp-developer To unsubscribe, mail [EMAIL PROTECTED]
Re: gimp-plugin-template questions
Hi, What is the purpose of including src/plugin-intl.h in the template? Does #include "plugin-intl.h" do something that #include libgimp/gimpintl.h does not? Yes, a lot! Actually plugin-intl.h as shipped with gimp-plugin-template is the equivalent to libgimp/std-plugins-intl.h which is included from all plug-ins in the standard distribution. plugin-intl.h includes libgimp/gimpintl.h and builds a wrapper around the basic internationalisation macros defined their. By including it you get two macros: INIT_I18N() and INIT_I18N_UI() that do the dirty work of binding your application to the libgimp's and its own textdomain. I'd suggest you take a short look into plugin-intl.h, it should be self-explanatory. How are individual user installations supposed to work? (is there a target that installs to ~/.gimp?) I don't think so. Do we need to add that? are config.sub and guess necessary for most plug-ins? AFAIK they are necessary if you want to use configure. Salut, Sven
Re: Feature idea: rotate brush while following a path
Tom Rathborne wrote: On Mon, May 29, 2000 at 02:28:33PM +0200, Raphael Quinet wrote: [...] rotate a brush automatically according to the local tangent of the path that the brush is following. [...] [...] What other transformations could be added? How about: blur, colour rotation, scaling... I wrote a short piece on implementing this sort of thing a while ago. Wrote the code and it seemed to work OK; but I was having trouble deciding on the best way to incorporate it into the existing GUI, and I thought that 1.2 was closer than it has turned out to be, so I left it for later. The writeup is at: http://www.ozemail.com.au/~hodsond/gimpbrush.html for those who might be interested. -- David Hodson -- [EMAIL PROTECTED] -- this night wounds time
XCF loader for gdk-pixbuf
Hello, dudes, Jens Finke [EMAIL PROTECTED] has sent me an amazing patch to add support for XCF file loading to gdk-pixbuf. I would really like to have this sort of functionality so that simple programs like EOG can view GIMP files. However, there is the issue of licensing. Gdk-pixbuf is released under the LGPL, and the XCF loader uses big chunks of GPLed code from the GIMP. I am not sure what is the best way to proceed. [For the GIMP developers who may not be aware of how gdk-pixbuf works, it is a little library that lets you load images and perform some simple operations on them. The image loaders are loaded on demand as shared libraries, so we have dynamic objects for GIF, JPEG, PNG, TIFF, etc.] I would appreciate your suggestions. Thanks, Federico
Re: XCF loader for gdk-pixbuf
On May 30, Federico Mena Quintero wrote: However, there is the issue of licensing. Gdk-pixbuf is released under the LGPL, and the XCF loader uses big chunks of GPLed code from the GIMP. I am not sure what is the best way to proceed. I would appreciate your suggestions. Do you know who all of the copyright holders of that code are? -Phil
Re: XCF loader for gdk-pixbuf
Federico Mena Quintero [EMAIL PROTECTED] writes: However, there is the issue of licensing. Gdk-pixbuf is released under the LGPL, and the XCF loader uses big chunks of GPLed code from the GIMP. I am not sure what is the best way to proceed. Well, there are not many options. a) You find all the authors of that GPL code and get the license changed (avoiding this mess is the advantage of copyright assignment...) b) You don't include the code in gdk-pixbuf c) You do a clean-room reimplementation of the code Havoc
Re: XCF loader for gdk-pixbuf
On Tue, 30 May 2000 11:27:37 -0400, Phil Schwan [EMAIL PROTECTED] said: Do you know who all of the copyright holders of that code are? At least myself, Peter, Spencer, and Adam Moss. There are almost certainly others. Kelly
Re: XCF loader for gdk-pixbuf
On Tuesday, 30 May 2000, [EMAIL PROTECTED] wrote: On Tue, 30 May 2000 11:27:37 -0400, Phil Schwan [EMAIL PROTECTED] said: Do you know who all of the copyright holders of that code are? At least myself, Peter, Spencer, and Adam Moss. There are almost certainly others. I can't remember if it was me or Jay Cox which added the resolution property reading/writing code. But if it was me, I hereby give permission for the licence on my portions to be changed to LGPL. Austin
Re: XCF loader for gdk-pixbuf
Austin Donnelly wrote: On Tuesday, 30 May 2000, [EMAIL PROTECTED] wrote: On Tue, 30 May 2000 11:27:37 -0400, Phil Schwan [EMAIL PROTECTED] said: Do you know who all of the copyright holders of that code are? At least myself, Peter, Spencer, and Adam Moss. There are almost certainly others. I can't remember if it was me or Jay Cox which added the resolution property reading/writing code. But if it was me, I hereby give permission for the licence on my portions to be changed to LGPL. I did the GimpUnit loading/saving stuff. Go ahead and make it LGPL. BTW, I'd suggest that we put the xcf code into a library for Gimp 2.0. Gdk-Pixbuf and whatever-image-viewer will then use the same code as The GIMP for loading XCFs. ciao, --Mitch
Re: XCF loader for gdk-pixbuf
On 30 May 2000, Havoc Pennington wrote: Federico Mena Quintero [EMAIL PROTECTED] writes: However, there is the issue of licensing. Gdk-pixbuf is released under the LGPL, and the XCF loader uses big chunks of GPLed code from the GIMP. I am not sure what is the best way to proceed. Well, there are not many options. a) You find all the authors of that GPL code and get the license changed (avoiding this mess is the advantage of copyright assignment...) b) You don't include the code in gdk-pixbuf c) You do a clean-room reimplementation of the code I think c) is the best solution. It's surely quite hard to find _all_ contributors to the code. And b) isn't a good solution if you imagine what cool applications could be done with a xcf-loader module (e.g. nice image cataloging tools). Also there are a lot of modifications to the original gimp code in the xcf-loader yet. So a clean rewrite is probably the best solution for everyone. Regards, Jens
Re: XCF loader for gdk-pixbuf
On Tue, 30 May 2000 20:04:02 +0200 (MEST), Jens Finke [EMAIL PROTECTED] said: I think c) is the best solution. It's surely quite hard to find _all_ contributors to the code. Actually, I think that the version that was initially put into CVS was pure SP, so the CVS log should adequately document all contributors since then. Kelly
Re: gimp-plugin-template questions
On Tue, May 30, 2000 at 12:06:58PM +0200, Sven Neumann wrote: What is the purpose of including src/plugin-intl.h in the template? Does #include "plugin-intl.h" do something that #include libgimp/gimpintl.h does not? Yes, a lot! [...] I'd suggest you take a short look into plugin-intl.h, it should be self-explanatory. Ok, the reason I asked was because it did not appear to need any customization for the individual plug-in. But looking closer, I suppose this is because it relies on the macro PLUGIN_NAME being defined, which is set in the individual plug-in distribution... btw- the plugin-intl.h in the template calls itself "freetype-intl.h" in the comments at the top ;) How are individual user installations supposed to work? (is there a target that installs to ~/.gimp?) I don't think so. Do we need to add that? Well, the usual way for people to install plug-ins they downloaded has been "gimptool --install" (or "gimptool --install-bin" called by the Makefile), which installs to the gimp directory in $HOME. So I think that is the expectation based on Gimp history. And unless we have decided that everyone who uses gimp is either a sysadmin or on a single-user box, it makes sense to keep that behaviour. are config.sub and guess necessary for most plug-ins? AFAIK they are necessary if you want to use configure. Hmm. I had a configure.in which ran without these... on the other hand, that didn't work very well which is why I switched to the way the template has it. ;) It is just that I feel silly having so many bytes used for the auto* when the plug-in needs no system-dependent changes... If we could get a template with working i18n without auto*, I would happily use that, but all gettext docs I have read say "use autostuff". :( Also, are there some packaging-people who could add an rpm spec file and a debian/ directory to the template? Thanks, - Kevin -- Kevin Turner [EMAIL PROTECTED] | OpenPGP encryption welcome here Plug-ins: They make GIMP do stuff. http://gimp-plug-ins.sourceforge.net/ This list is archived at http://marc.theaimsgroup.com/?l=gimp-developer To unsubscribe, mail [EMAIL PROTECTED]
Re: IrfanView
By default photoshop saves a flattened version of the image as well as all of the layers for backward compatibility purposes. I would assume that IrfanView is just displaying the flattened version of the image straight from the file. We may want to add similar functionality to gimp and the xcf format at some point to make it easier for other applications to display xcf files. No no no, or optional. I got a .psd and it was big (now I know why). I loaded into Gimp, saved and compressed and it become small (it had two layers, plus the copy, after only two real ones and bzip2'ed). So the "full copy in one layer" should be optional, like GIF comments or similar things. I do not want to waste disk space just cos others want to view .xcf (what I always take as the source file of image works, a .c file for images, not the binary, the final image). And btw, to quick load, have anyone tried "gimp --no-data --no-splash file"? It is not as faster as a viewer, but it is better than other solutions. It seems to me like we should provide a libxcf for applications such as this. Better. GSR
Re: XCF loader for gdk-pixbuf
Havoc Pennington [EMAIL PROTECTED] writes: Federico Mena Quintero [EMAIL PROTECTED] writes: However, there is the issue of licensing. Gdk-pixbuf is released under the LGPL, and the XCF loader uses big chunks of GPLed code from the GIMP. I am not sure what is the best way to proceed. Well, there are not many options. a) You find all the authors of that GPL code and get the license changed (avoiding this mess is the advantage of copyright assignment...) b) You don't include the code in gdk-pixbuf c) You do a clean-room reimplementation of the code What's wrong with d) Keep the XCF loaded GPL if I understand that correctly, the loaders are shared libraries which dnyamically loaded so they can theoretically have different licenses or do I miss something ? Sure, I'd prefer a) - but IMO d) is much better than b) or even c). -- Martin Baulig [EMAIL PROTECTED] (private) [EMAIL PROTECTED] (work)
LinuxTag: Sorry, im unavailable right now.
Hi all. Currently our local university has massive problems with the net so I'm currently not normally reachable via EMail. If you need to urgently reach me try the Adress [EMAIL PROTECTED], this is especially targeted to all people who contacted me for the Gimp-Booth at the LinuxTag. Sorry, currently I'm nearly cut off from my EMail-Communication. Sorry for the inconvenience. Bye, Simon Budig -- -- currently not reachable via [EMAIL PROTECTED] Sent through GMX FreeMail - http://www.gmx.net
Re: XCF loader for gdk-pixbuf
Havoc Pennington [EMAIL PROTECTED] writes: Martin Baulig [EMAIL PROTECTED] writes: Well, then I think you misunderstood me. What I suggested was added XCF as a nice add-on to gdk-pixbuf for the situation where gdk-pixbuf is used under the GPL. Of cause, this means that you can't use XCF loading in a proprietary app where you use gdk-pixbuf under the LGPL. Maybe. It's a big can of worms though - can Red Hat and SuSE ship the XCF add-on, for example? Probably not. Hmm, yes. -- Martin Baulig [EMAIL PROTECTED] (private) [EMAIL PROTECTED] (work)
Gimp-Print 3.1.5 release
This is a development release. Usual caveat about aerodynamic print heads and fine Oriental rugs apply. This is a fairly substantial release. The .tgz file is much bigger than before because of new dithering matrices. Print quality should be greatly improved. 1) Greatly improved print quality. In particular, ordered dithering and adaptive dithering methods are now much better than ever before. We recommend ordered dithering for four-color printers and either adaptive hybrid or adaptive random dithering for six-color printers. 2) If a print job is canceled from within the Gimp, the partial file will not be sent to the printer. 3) Support for additional Canon and Hewlett-Packard printers. 4) Epson Stylus printers can now print much closer to the edge of the page. They can print to the extreme top edge and much closer to the bottom than before, although there is some loss in quality close to the edge. 5) Greatly improved black quality. 6) The preview window now shows the borders of the printable area in addition to the borders of the page. In addition, the offsets are now from the true edge of the page rather than from the edge of the printable area. 7) 720 dpi highest quality and 1440x720 dpi highest quality are now supported on the new generation Epson printers. 8) Epson printers will now print faster on sparse pages and in pure black and white. This is of particular interest for the Ghostscript driver. -- Robert Krawitz [EMAIL PROTECTED] http://www.tiac.net/users/rlk/ Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for The Gimp Print -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton
