Re: [Gimp-developer] what is up to day
dont whant to bother,..but how about an totally alphabetic release,..like picasso, vinci il mondo, maya art, gliphic insight?,,,ha,..galactic green,.. ...the number? regards Joel ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] What's new in GIMP-1.3 so far
Hi, Le jeu 19/06/2003 à 10:55, Sven Neumann a écrit : You can get 160 hits on google for whatever statement you would like to make. It is a stupid attempt to try to prove anything with a search engine that has billions of pages archived. I also agree that coming up with a google search is ridiculous. I'm afraid, there would be lots of people asking where is CMYK support and where is GEGL? It is very hard to alter such widespread knowledge. It could get a real PITA. As I said in another mail already, I believe that it will be a major PITA to explain why it GIMP uses GTK+-2.x and still is not called 2.0. I could surely come up with a google search to proove this but this is getting ridiculous. Anyone who followed the discussions on various sites that announced GIMP-1.3 releases lately, will have noticed that people keep asking for a GIMP port to GTK+-2.x. Going for GIMP 2.0 will IMO be less confusing than sticking to 1.4 just because we stated so 3 years ago. The problem is not that 2.0 == Gegl was stated 3 years ago, but that everyone (ie: magazines, websites) stated it since these 3 last years. As a Gimp user I am particullary enthusiastic with the changes introduced in the 1.3 branch, but I think in this scope it would make much more harm to call it 2.0 than 1.4, even if it is based on GTK+2. But don't be affraid, whatever your decision will be, ppl here will support you. And ppl are confident in you, and the way you have (will) managed the Gimp since all this time. If you (and the other main gimp developpers) finaly decide to call it 2.0, I think you should really insist, in your press release, on the fact that this realase was so good that you finally decided to call it 2.0 instead of 1.4. And that 2.0 will be 3.0. This would be a really positive and understable way to explain the change. Thanks, -- Dam ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New thread on GIMP 1.3+
Am Don, 2003-06-19 um 21.44 schrieb David Neary: I'll get the ball rolling: 2.0 1.4 -- Servus, Daniel ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New thread on GIMP 1.3+
On 20 Jun 2003, Daniel Egger wrote: Am Don, 2003-06-19 um 21.44 schrieb David Neary: I'll get the ball rolling: 2.0 1.4 Damnit, call it GIMP XP already. Marco ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New thread on GIMP 1.3+
On Thu, 19 Jun 2003 21:44:01 +0200, David Neary [EMAIL PROTECTED] wrote: I'll get the ball rolling: 2.0 FWIW, 1.4. Yes, I know that I supported 2.0 three days ago, but I have changed my mind since then. In any case, I don't think that making the poll on the developers' list is useful. If anybody wants to make a poll, it should be done on the user's list or in comp.graphics.apps.gimp. We would like to to avoid bad press from the users, not from the developers. So we should ask the users instead. The users' poll should start with a brief summary of user-visible changes and it should also mention what the next release will not have. -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp/GScanner leaking fd - by design ?
Hi, Hans Breuer [EMAIL PROTECTED] writes: Sent to gtk-devel w/o response Did you file a bug-report? This is unlikely ever to be fixed without a bug-report. Current Gimp cvs (compiled on win32) triggers the one in g_scanner_get_char() and as a result looses it's reference to the input file. Actually, I'd be interested to hear how exactly we are triggering this. When I saw your mail on gtk-devel I looked at the code in question but I could not find out what is going wrong. +typedef struct _GimpScannerUserData GimpScannerUserData; I always wondered who invented the term user_data, can't it just be GimpScannerData? Apart from that (and a missing blank) the patch looks OK. However I'd rather see this fixed in GLib. So it should probably be marked with a #warning and removed later when we can depend on a fixed version of GLib. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Macro Recorder 2nd Try
Hi, Hans Breuer [EMAIL PROTECTED] writes: - Intercept every PDB call if a macro recorder instance is running. (try to guess the call stack depth to avoid recording functions called by a plug-in) That would mean that all actions go through the PDB. The fact is that no user action goes through the PDB at the moment. Only plug-ins call PDB functions, the core doesn't. We definitely need to change this to make macro recording possible. Now for my questions : - are there further huge changes planned for the plug-in/pdb code (time involved to maintain my patch) ? Yes, definitely. The PDB needs to be completely dumped and redone. It lacks such important features as named parameters and default values. Nathan is already working on a replacement library that is supposed to provide that functionality. We should consider to revamp the PDB soon after the release. - is the outlined approach mature enough to be at least considered for acceptance if I have a first working version ? We usually prefer if code is developed in the CVS tree. Most attempts where people tried to prepare a working version in their tree lead to rotting bits and wasted time and effort. It seems like the macro recorder needs some substantial changes to the framework. Once these are done, it should be a piece of cake to implement. That said, I'd suggest you help defining and building the framework needed. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Macro Recorder 2nd Try
At 15:20 20.06.03 +0200, Sven Neumann wrote: Hi, Hans Breuer [EMAIL PROTECTED] writes: - Intercept every PDB call if a macro recorder instance is running. (try to guess the call stack depth to avoid recording functions called by a plug-in) That would mean that all actions go through the PDB. The fact is that no user action goes through the PDB at the moment. Only plug-ins call PDB functions, the core doesn't. We definitely need to change this to make macro recording possible. This is the all-or-nothing argument. IMO a macro recorder would already be useful if it only records the calls done as reaction on users menu usage, where many go through the PDB. Without looking further I thought there are already core functions which work like this, too. Obviously the recorder should be written that every function which finally goes through the PDB gets recorder as well. But it would be rather difficult to _not_ make this happen automagically ... Now for my questions : - are there further huge changes planned for the plug-in/pdb code (time involved to maintain my patch) ? Yes, definitely. The PDB needs to be completely dumped and redone. It lacks such important features as named parameters and default values. Nathan is already working on a replacement library that is supposed to provide that functionality. We should consider to revamp the PDB soon after the release. Probably I should have choosen my words more careful. Second try: Are there _short-term_ huge changes planned for the plug-in/pdb code ? - is the outlined approach mature enough to be at least considered for acceptance if I have a first working version ? We usually prefer if code is developed in the CVS tree. Most attempts where people tried to prepare a working version in their tree lead to rotting bits and wasted time and effort. Agreed, been there doen that ;) OTOH before putting something into cvs it should basically work, which my original patch against gimp-1-2-cvs did - at least it did not break anything else. It seems like the macro recorder needs some substantial changes to the framework. Once these are done, it should be a piece of cake to implement. That said, I'd suggest you help defining and building the framework needed. That's what I tried with my additions (half a year ago) to http://bugzilla.gnome.org/show_bug.cgi?id=51937 But beside the valueable input from Raphael there was no further response/interest. Sven Hans at Breuer dot Org --- Tell me what you need, and I'll tell you how to get along without it.-- Dilbert ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp/GScanner leaking fd - by design ?
At 15:05 20.06.03 +0200, Sven Neumann wrote: Hi, Hans Breuer [EMAIL PROTECTED] writes: Sent to gtk-devel w/o response Did you file a bug-report? This is unlikely ever to be fixed without a bug-report. Current Gimp cvs (compiled on win32) triggers the one in g_scanner_get_char() and as a result looses it's reference to the input file. Actually, I'd be interested to hear how exactly we are triggering this. When I saw your mail on gtk-devel I looked at the code in question but I could not find out what is going wrong. I'm not sure if it is a win32 only thing. Without very deep understanding of GScanner I thought it always runs to no-more-chars-avail in g_scanner_get_char(). Maybe you can reproduce by simply checking the return value of close() in gimp_scanner_destroy() To reproduce I simply start and quit The Gimp. It happens on all file in ~/.gimp13/tool-options and documents, sessionrc. The latter can not be written on exit cause they are still open (on win32). This already gave an error message. +typedef struct _GimpScannerUserData GimpScannerUserData; I always wondered who invented the term user_data, can't it just be GimpScannerData? Apart from that (and a missing blank) the patch looks OK. However I'd rather see this fixed in GLib. So it should probably be marked with a #warning and removed later when we can depend on a fixed version of GLib. Given the other use cases of GScanner I looked at (in gtk) I'm not sure if input_fd is supposed to stay valid - they all maintain their fd independent of it. But one could still call it a documentation bug of GLib :-) Hans Hans at Breuer dot Org --- Tell me what you need, and I'll tell you how to get along without it.-- Dilbert ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] what is up to day
This is the best idea so far. Helvetix On Fri, Jun 20, 2003 at 01:47:14AM -0700, Joel Eduardo Rodriguez Ramirez wrote: dont whant to bother,..but how about an totally alphabetic release,..like picasso, vinci il mondo, maya art, gliphic insight?,,,ha,..galactic green,.. ...the number? regards Joel ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Status of MMX code in The GIMP
Last Februrary, I volunteered to help with the GIMP MMX implemetation that had been languishing and had recently started to cause problems when building the current GIMP code. This (http://oak.mysterious.org/~helvetix/practicum/gimp-composite.tgz) is release 0.0 of an extensible and customisable image compositing interface for the GIMP. This doesn't really provide any 'user visible' changes, other than the potential (and actual in this case) performance improvements. I'd like to hear feedback. What you get is this: * A general mechanism for incorporating compositing functions based upon the compositing function and the pixel formats of the inputs and the outputs of the function. * Generic implementations of the supported compositing functions as a foundation for further/future improvements. * The general mechanism allows any compositing function implementation to be replaced by a different implementation. This is particularly useful in that one can write specialised implementation of some, many, or all of the compositing functions. These specialised implementations can be written to take advantage of special CPU instructions, such as VIS, AltiVec, MMX, and so forth, and special hardware acceleration that might be available. Currently, I have an incipient set of functions implemented which use the MMX instruction set of the Pentium processor. Helvetix ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Macro Recorder 2nd Try
On Fri, 20 Jun 2003 16:50:37 +0200, Sven Neumann [EMAIL PROTECTED] wrote: Hans Breuer [EMAIL PROTECTED] writes: This is the all-or-nothing argument. IMO a macro recorder would already be useful if it only records the calls done as reaction on users menu usage, where many go through the PDB. Without looking further I thought there are already core functions which work like this, too. I don't want to disappoint you but besides the menu entries that are installed by plug-ins no GIMP menu entry calls a PDB function. Your macro recorder would miss almost all of the user action unless we change this. When I worked on this a bit more than a year ago, I was able to record (some of) the menu entries belonging to the core, such as Layers-Flatten Image, Image-Scale, Image-Mode-... I do not remember exactly how I did it and I think that it was not very elegant, but it seemed to work. I think that I had to modify each core feature separately and add a hook using the GimpScriptRecorder object before the end of each function. The biggest problem for me was to generate the equivalent PDB calls for brush strokes, gradients, fills, selections, etc. Especially since I wanted these to be scalable (see my comments in bug #51937 for details). At the moment it's probably easier to use Gerd for macro recording purposes. This is fine if you want to record a complete GIMP session from the beginning to the end, but this is probably the least frequent usage of a script recorder. I expect that the most common reasons for using it would be: - to apply similar operations to different images, - to repeat a sequence of operations several times on the same image, - to get a skeleton of a script that you can edit later. Gerd does not solve any of these problems, unfortunately. Those who do not know what Gerd is can have a look at these links: http://bugzilla.gnome.org/show_bug.cgi?id=51937 http://www.gtk.org/~timj/gerd/ By the way, the last time I checked (end of last year), Gerd was only working with GTK+ 1.2, not 2.x. I don't know if it has changed since then. -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New thread on GIMP 1.3+
On Friday 20 June 2003 07:10, Marco Wessel wrote: On 20 Jun 2003, Daniel Egger wrote: Am Don, 2003-06-19 um 21.44 schrieb David Neary: I'll get the ball rolling: 2.0 I wil stay with 1.4 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] ANNOUNCE: Gimp-Print 4.3.17
Gimp-Print 4.3.17, released June 20, 2003, is a development release of this package. Like all development releases, this version is considered unstable and should only be used by those individuals tolerant of the likelihood of problems. Individuals desiring a stable release of Gimp-Print should use the latest 4.2 release. Gimp-Print is a suite of printer drivers that may be used with most common UNIX print spooling systems, including CUPS, lpr, LPRng, or others. These drivers provide high quality printing for UNIX (including Macintosh OS X 10.2 and newer) and Linux systems in many cases equal to or better than proprietary vendor-supplied drivers, and can be used for many of the most demanding printing tasks. This software includes the Print plug-in for the Gimp, and Ghostscript and CUPS drivers, including Foomatic data. The Print plugin for the Gimp requires the Gimp 1.2 (later versions of the Gimp are not supported). You may need to install a package named gimp-devel or the like on many distributions. The CUPS driver requires CUPS 1.1.15 or higher. You may need to install a package named cups-devel or the like on many distributions. The Foomatic data will work with either Foomatic 2.x or 3.x. Foomatic 3.x has additional capabilities that this package detects and takes advantage of. The IJS-based GhostScript plugin driver requires GNU Ghostscript 6.53 or later, ESP Ghostscript 7.05 or later, or APFL GhostScript 7.04 or later. Users of Macintosh OS X 10.2 and above can use this package, as the printing system is based on CUPS, which is supported by Gimp-print. Note that Macintosh OS X 10.0 and 10.1 (including 10.1.5) cannot use this package. Please read the README file for full instructions on installing this package. Gimp-Print 4.3.17 contains the following major changes over Gimp-Print 4.3.16: 1) The libxml2 package is no longer required for building Gimp-Print. It has been replaced with a very light weight XML package called mxml, which is compiled into the library. 2) The glib package is no longer required for building the GhostScript IJS driver (ijsgimpprint). 3) The libgimpprintui library is now correctly built or not depending upon whether --enable-libgimpprintui is passed or not. 4) White output is now truly white. In 4.3.16, a very small number of dots was printed even for white output, which in some cases made printing take much longer than required. 5) Roll feed should now work correctly on Epson printers that do not have a paper cutter. 6) Default values for dither algorithm and image optimization have been added; this allows the user to not specify these options. 7) A new Quality setting has been added for the Epson driver. This enables the user to choose from a set of named qualities (e. g. economy, draft, standard, photo, etc.), simplifying the choices for the user. When the user selects a Quality setting, the Resolution, Ink Type, Ink Set, and Printing Direction controls are disabled. Different Quality settings are available depending upon the printer's capabilities and the choice of media type; e. g. the higher quality photo settings are not available on plain paper, while draft and economy settings are not available with high quality photo papers. The CUPS driver does not currently enforce these limitations, as the PPD files do not currently support constraints on option values. In the future, the Quality setting may control other settings as well, such as dither algorithm, image optimization, etc. 8) A new auto-size option for roll paper has been added (currently in the GIMP plug-in only). 9) Preliminary support for the Epson Stylus Photo 935, and the PM-940C and PM-980C. 10) The numeric options now offer increased precision in the CUPS driver, by way of coarse and fine adjustments for each option. The coarse adjustment offers adjustment in units of 0.1; the fine adjustment offers additional increments of 0.005. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New thread on GIMP 1.3+
Hi, Nathan Carl Summers [EMAIL PROTECTED] writes: Otherwise, the Slashdot headline we will get is GIMP 2.0 Fails to Deliver Promised Features Do you really expect this to happen? Well, of course there will be the inevitable casual trolls, but apart from that, do you really expect bad press in the spirit of not delivering promised features? Did we ever promise anything? I can not remember that we did that. Sorry, if this sounds as if I would not believe you, but this idea seems beyond my imagination... Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
