Trouble with gimp_text_get_extents_fontname and gimp_text_fontname
[using gimp-1.0.4-3 ] Dear Gimp-developer, I have a Gimp-perl script for generating rollie buttons that used to work but now fails, presumably because of the following message I receive on starting Gimp: 1: wire_read: unexpected EOF (plug-in crashed?) 2: overwriting Gimp::Lib::gimp_text_get_extents_fontname (1,1) 3: overwriting Gimp::Lib::gimp_text_fontname (1,1) 4: overwriting Gimp::Lib::gimp_text_get_extents_fontname (1,1) 5: overwriting Gimp::Lib::gimp_text_fontname (1,1) wire_read: unexpected EOF (plug-in crashed?) (my linenumbers) Line 1: no idea what it is but I don't think it is relevant. Lines 2-5: gimp_text_get_extents_fontname and gimp_text_get_extents_fontname are the routines where my plugin _now_ crashes. "Now" means I have successfully used the script a few weeks back and have not changed it since. This begs the question "what has changed". In any case it seems these scripts are being corrupted on startup. Thankfull for any advice, Darren Kelly
Re: The Gimp is wasting a lot of memory
On Sun, 23 Jul 2000 20:45:32 -, "somnorici " <[EMAIL PROTECTED]> said: >Kelly: no, I'm not asking gimp to not store the image decompressed, I >just want it to use a display buffer sized to the window size, not to >the image size. Of course, several copies of the image (in this case >105megs) will be used for layers, alpha, undo, whatever. However, >when I crop and I have zero levels of undo, the swap file size should >not grow! If I work on a rectangular selection, there should be no >working copy, just work on the current image. I'm not sure if the projection buffer is constructed conservatively or not. As I recall projection is done bottom-up instead of top-down, which makes conservative construction difficult. I planned a top-down revision once but never implemented it because it was too extensive a change. If we had top-down projection, the projection buffer would only be populated by those tiles actually needed for the displayed region. The entire tile manager would be allocated, of course, but only those tiles actually accessed would be populated. I've also wanted to allow for a left and top offset into tile memory so that tiles could be partially shared. This makes crop a zero-copy operation; the cropped image would reference the same tiles with left and top offsets. Again, never done because of the extensiveness of modification required. Kelly
Re: Gimp on MacOS
On Fri, 21 Jul 2000 16:09:31 -0400, "Jason T. Slack" <[EMAIL PROTECTED]> said: >A question: (An odd question) How did GIMP get permission to use the >same Icons in the toolbox as Photoshop. Did they have to goto Adobe >and get permission? They just look the same. Doctrine of merger would probably apply (there's only so many ways to draw a paintbrush). Kelly
Re: The Gimp is wasting a lot of memory
On Thu, 20 Jul 2000 21:45:05 -, "somnorici " <[EMAIL PROTECTED]> said: >I set the undo levels to zero and loaded an image. 9376 by 11488 >pixels grayscale is 107,711,488 bytes. My display depth is 16 >bits. It didn't take long to link this with the swap file, which >after loading the image was 292,421,632 bytes, plus the 32 megs of >tile cache (it's on a 64 megs machine used for testing), it kinda >equals three times the size of the image. Yes, because there's a selection mask of equal size to the image, and a projection buffer, also of equal size to the image. Although I think that if there's no selection mask, that tilemanager should be unallocated, and when there's only one layer, the background layer doubles as the projection buffer, so there shouldn't be a separate projection buffer. It's been quite a while since I dug around in this part of the code, though. >This takes me to the conclusion that gimp kindly allocates the memory >for storing the image after extracting it from the file, and the >whole image used for displaying, instead of only 3-7% which is >actually used for an image so big. Now this is a serious thing, and >I'll have to start digging the source to fix it... Is there anyone >else aware/working on this issue? Well, it has to allocate the memory to store the image somewhere, even for parts that aren't presently being viewed. It's not practical to swap image data from the source file; most image storage formats are compressed such that it is not possible to read data out of the file except sequentially from the start. Kelly
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 S&P, so the CVS log should adequately document all contributors since then. Kelly
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: Why host plug-ins at SourceForge? (Was: I want to develop IPTC-data support for The Gimp.)
On Fri, 25 Feb 2000 19:00:28 -0500, Robert L Krawitz <[EMAIL PROTECTED]> said: >I think it's great that plugin development is "fragmenting" in this >fashion. It isn't going to weaken the Gimp; it's going to increase >the pool of people who want to write plugins for it, which is all to >the good. It will also force us to develop tools for the separate compilation of plugins and develop a plugin interface that is versionable Kelly
Re: An experiment (was Re: Move help menu item...)
On Mon, 14 Feb 2000 14:21:39 -0500 (EST), Glyph Lefkowitz <[EMAIL PROTECTED]> said: >Rather than doing this, wouldn't it be possible to do the same thing >that terminals do, I.E. make the window resizable by char cells >rather than pixels? I like the fact that I can resize the window as >I work, rather than digging through dialogs to choose a setting... The problem is that the buttons in the toolbox are themselves resizable. Kelly
Re: resend
On Sun, 13 Feb 2000 10:06:24 -0500, Robert L Krawitz <[EMAIL PROTECTED]> said: >So one thing that springs to mind here is if the Gimp itself were to >warn if you attempt to exit while a plug-in is in progress of >execution. Gimp folks, would that be feasible? That would seem >useful for other long-running things (and some of the filters take a >long time to run). Erk. I looked into this a while ago to solve the related "GIMP does Bad Things if you delete an image while a plugin is using it" bug. It's not easy. The code for running plug-ins is NOT very friendly. Kelly
Re: Problems with gimp-1.1.17?
On Sat, 12 Feb 2000 17:32:41 + (GMT), Austin Donnelly <[EMAIL PROTECTED]> said: >Maybe we should make it our problem. >I think that given the number of people who are bitten by this, is >there nothing we can do in the gimp to work-around the GTK problem? Why not just fix the problem (although I believe it's already been fixed and released)? In the past when GIMP development has uncovered GTK bugs, we've just gone and fixed the GTK bug. Never forget that GTK is the *GIMP* toolkit. :) Kelly
Re: Toolbox layout and Help menu
On Fri, 11 Feb 2000 14:05:42 -0500 (EST), Glyph Lefkowitz <[EMAIL PROTECTED]> said: >It seems like this is really the only reasonable option -- I think >that there should be a 'menu' spot in the tools, like the top-left >menu in the image windows, since the toolbar is frequently too thin >for the menus anyway (vertical layout, try using a large font in your >gtk theme sometime...) and if it's not (horizontal layout), then the >menubar is taking up far too much screen real estate for no reason. It would not be hard to add a "button" that pops up the menus. People would probably go "Where the hell is the menu?" if we did that, though. Kelly
Re: An experiment (was Re: Move help menu item...)
On Fri, 11 Feb 2000 13:25:04 +0200 (EET), Tor Lillqvist <[EMAIL PROTECTED]> said: >One suggestion would be to not have the toolbox user-resizeable via >the window manager at all, but to have in the Preferences a setting >where you use a spinbutton to set the number of columns. If you start >from, say, three columns, and keep increasing the number, at the >point where the number of rows is less than the number of columns, >the colour, brush, pattern and gradient selectors could automagically >jump to be at the right side instead of the bottom. This is as good an idea as any I've seen so far. Kelly
Re: An experiment (was Re: Move help menu item...)
On Thu, 10 Feb 2000 19:50:07 +0100 (CET), [EMAIL PROTECTED] said: > Hm, couldn't we use the event handling system to automatically resize > the toolbox to a new good value on every resize event: > If you enlarge the toolbox the window size automatically snaps on the > next convenient size and vice versa... This can be dangerous; you can get a resizing loop if your code isn't carefully written. Window managers can refuse to accept a client resize request or can modify it, which could result in a duel between GIMP and the window manager as the two fight over who gets to decide what size the window will be. Kelly
Re: CMYK when?
On Wed, 9 Feb 2000 19:47:42 -0500, Robert L Krawitz <[EMAIL PROTECTED]> said: >CMYK is a bit of an oddball subject. Partly this is because there >are so many variants (CMY, CMYK, CcMmYK, CcMmYy, CcMmYyK), and partly >because (to the best of my knowledge) this color space is really only >useful in the context of specific output devices, which is what the >print plugin deals with. Full CMYK (that is, at least 8 bits per channel, not the twiddly 2-bit stuff you deal with working on the printer drivers) is _absolutely necessary_ for GIMP to be viable for prepress work. Kelly
Re: Sample Colorize [Was: Re: Buggy plugins]
On Mon, 7 Feb 2000 09:22:09 +0200, Tuomas Kuosmanen <[EMAIL PROTECTED]> said: >So it is basically Gradient Map on steroids? Yeah, Gradient Map with a "preserve luminosity" option and the ability to synthesize a gradient on the fly from an input image. Kelly
Re: Sample Colorize [Was: Re: Buggy plugins]
On Sun, 06 Feb 2000 19:04:12 -0500, "Garry R. Osgood" <[EMAIL PROTECTED]> said: >Personally, I think similiar tricks may be pulled fully in the confines >of the Curve tool, but as Marc pointed out, not everyone is a copy of me >(or is it 'a copy of Daniel Egger'? I forget ... ;), so some people >may find this plug-in to be lots and lots of fun. I've found Sample Colorize to be occasionally interesting, and certainly harmless. It should be an optional plugin post-1.2, but I see no reason not to include it in 1.2 if rendered relatively bug-free. Kelly
Re: story on advogato
On Sun, 6 Feb 2000 01:18:12 -0600, "Shawn T . Amundson" <[EMAIL PROTECTED]> said: >Wilber t-shirts and hats for everyone!!! ;) Hell, that would be fine with me. :) Kelly
Re: Buggy plugins
On Sat, 05 Feb 2000 23:50:56 -0800, "Martin Weber" <[EMAIL PROTECTED]> said: >Here a list of buggy plugins in GIMP-1.1.16: >tileable blur plugin: >the status bar is appearing in an extra window >-- >color exchange / color mapping plugins: >color selection: you can choose a color but black is taken instead >-- >sample colorize plugin: >when starting this plugin you get: >Gtk-CRITICAL: file gtkwidget.c: line 3313 (gtk_widget_set_sensitive): >assertion 'widget!=NULL' failed. >-- >max rgb / value invert plugins: >the effect is only applied to a small rectangle >-- >curve bend plugin: >no undo possible >-- >pnm plugin: >When I save pbm in GIMP it is not saved as pbm but as pnm. Here's a novel idea: file bug reports, eh? Kelly
Re: story on advogato
On Sat, 5 Feb 2000 21:00:19 -0700 (MST), "Michael J. Hammel" <[EMAIL PROTECTED]> said: >The last comment I saw under this story said that a $2K award was >given to "Wilbur the Gimp". Since Gimp has no non-profit (or for >profit) organization, who got that money? Just curious. It goes to Yosh, who will decide what to do with it. Kelly
Re: Removing pencil?
On Sat, 5 Feb 2000 11:45:16 +0100 (CET), [EMAIL PROTECTED] said: > I think it's time to remove that useless pencil before the release >of the magic version 1.2. Did anyone use it in the last time? It >contains no functionality that paintbrush doesn't have except of hard >edges (anyone needing that "feature"?)... I find it very useful when working on small pixmaps (like icons). Kelly
Re: Plugins at Sourceforge
On Sat, 5 Feb 2000 12:33:38 -0800, "Michael J. Hammel" <[EMAIL PROTECTED]> said: >I'm curious why any new plug-ins should be added to the core *at >all*. Gimp's distribution is fairly large as it is. Isn't it >getting time to limit additional plug-ins to the core distribution to >plug-ins which are considered "vital" in some way? Even some estoric >file plug-ins need not necessarily be included with the core package. >Throwing in the kitchen sink is what's starting to bloat some Linux >distros. I couldn't concur with you more. I'm radical enough to suggest taking all the plugins out of the standard distribution entirely. :) Kelly
Re: Plugins at Sourceforge
On Fri, 28 Jan 2000 17:29:48 +0100, Marc Lehmann <[EMAIL PROTECTED]> said: >As it is now there is the slight danger that the "self-management" >can cause _more_ work for the maintainers. If Sven has to od a >one-line change in every plug-in he would be force to use two >different cvs servers. Well, hopefully this sort of thing shouldn't have to happen; that would occur because of a noncompatible interface change and I'd like to think we can avoid that. (If the interfance needs to be changed, we should offer a "legacy mode" so unadapted plug-ins continue to function.) Kelly
Re: Plugins at Sourceforge
On Fri, 28 Jan 2000 12:40:32 -0500, Zach Beane - MINT <[EMAIL PROTECTED]> said: >Count this as a cry out against it. I suggest waiting for a logical >pause in development, such as the release of GIMP 1.2, to begin >making these not-insubstantial changes in source management. My position is sourceforge should be used at this time only for plug-ins which are not already in the source tree. Such plug-ins will not be a part of 1.2 anyway because 1.2 is frozen at this time. When 1.3 development begins, we can decide what to do with the plug-ins currently in the distribution. Kelly
PDB_PASS_THROUGH
I can find no evidence that this is actually used anywhere in the GIMP. Anybody know what it's for and whether it even works? Kelly
Re: important: automatic mirroring to the gimp cvs
On Fri, 28 Jan 2000 01:38:32 +0100, Marc Lehmann <[EMAIL PROTECTED]> said: >Ok. I've just enabled automatic mirroring from the sourceforge cvs >back to the gimp cvs. FWIW, I think this should be used sparingly. It is my belief that we should try to move plugins into a separate package from the GIMP core; I would be quite happy to see the plugin directory go away _entirely_ from the main GIMP CVS. This really isn't that big a deal. Lots of applications require multiple packages to get "everything", and GIMP is a _large_ application. Kelly
Re: Edit Fille behaviour change?
On Fri, 4 Feb 2000 20:32:33 -0500, Federico Mena Quintero <[EMAIL PROTECTED]> said: >What does Photoshop do? What does that matter? Kelly
Re: Edit Fille behaviour change?
On Fri, 4 Feb 2000 19:07:37 -0500, Zach Beane - MINT <[EMAIL PROTECTED]> said: >>Fill (by default Ctrl-.) has filled using the background colour in >>the GIMP for as long as I can remember. I don't think it's a bug >[snip] >I agree. I have grown very accustomed to the existing behavior, and I >don't think it should be changed. >I know it hasn't been customary in the past, but I think such a >user-visible change should be discussed a little bit. I also concur and recommend a reversion. Kelly
Re: Performance
On Fri, 4 Feb 2000 09:52:30 +0100 (MET), [EMAIL PROTECTED] (Raphael Quinet) said: >I disagree. This would only encourage some users to re-compile their >own version of the Gimp in a private directory in order to get around >the hardcoded limits. Frankly, I disagree. Systems where admins are likely to impose such restrictions are going to be ones where users don't have enough space to compile private copies of Gimp. >Being a system administrator myself, I believe that an admin should >always suggest some limits (and maybe use some social engineering to >encourage users to respect these limits) but should avoid hard >limits. It depends on the kind of users you have and the hardware you're running. Imposing hard limits is sometimes the only way to deal with certain types of users. >On the other hand, if ulimits are used to limit the maximum file size >or CPU usage, there is not much that we could do about it. Same if >disk quotas are activated. The Gimp can have some control over its >memory usage, but many parts of the code assume that the disk space >is unlimited (or is not the main constraint). Yup. It might be nice to catch SIGXCPU and try to do an orderly shutdown before the SIGKILL does ya' in, though. :) Kelly
Re: Performance
On Thu, 3 Feb 2000 19:33:31 +0100 (CET), [EMAIL PROTECTED] said: > If you have a shared maschine the best would be to let the >administrator choose how much memory each user will get because >users'll ALWAYS try to get what they can even if it makes no >sense It might be a good idea to have a compile-time configuration option for maximum cache size, and it might also be a good idea for gimp to check its ulimits and adjust its cache size so as to avoid running over its data segment limit or maximum resident set size. Some admins use these as a way to prevent resource hogging. Kelly
Re: Print plug-in
On Wed, 2 Feb 2000 03:31:31 +0100, Marc Lehmann <[EMAIL PROTECTED]> said: >"gnome", just like "kde" are very much political terms nowadays, and >it's very nice to work on a projetc that just wants to be good, and >is not generally linked to some political term (even if the gnome&kde >communities themselves might feel the same). Did you miss all the screaming when there was initial talk of a Win32 port? :) Kelly
Re: Print plug-in
On Tue, 1 Feb 2000 17:24:35 -0600, "Shawn T . Amundson" <[EMAIL PROTECTED]> said: >But hasn't Mozilla basically given up on this idea and just used >their own toolkit? Mozilla certainly looks crappy on the Mac at any >rate. I was referring to the commercial Netscape product, rather than Mozilla. I can't speak to why Mozilla made the decision to use their own toolkit. Kelly
Re: Print plug-in
On Tue, 1 Feb 2000 20:10:51 +, "Steinar H. Gunderson" <[EMAIL PROTECTED]> said: >The point is not just KDE vs. GNOME, is it? Isn't BeOS doing their >own port of GIMP, using the native widget set? And I'm sure Windows >users would appreciate a more-or-less native Windows UI, too. The KDE v Gnome issue is somewhat specious, but the Windows issue is not. Using Windows native UI functionality would probably result in a stabler, faster program as well as a program that users will understand better. The folks at Netscape manage to make this more or less work. We should be able to as well. Kelly
Re: Print plug-in
On Tue, 1 Feb 2000 16:16:49 -0600, "Shawn T . Amundson" <[EMAIL PROTECTED]> said: >You are 100% incorrect. GIMP runs on Win32. GNOME gives no >consideration to this platforms, as far as I know. GIMP should be >kept as independant from GNOME as possible. This is my single biggest reason for opposing gnomification: we'd lose at least two architectures (Win32 and OS/2). Yeah, I know, Windows is Evil and OS/2 is dead. So what? We support them because people want them. Kelly
Re: Print plug-in
On Tue, 1 Feb 2000 15:11:13 -0500 (EST), Glyph Lefkowitz <[EMAIL PROTECTED]> said: >No, and it's their right not to. If you believe this should be a >requirement, it should be part of the license. GIMP is a part of Red >Hat Linux, why shouldn't it be a part of the GNOME office suite? >If I recall correctly, GIMP is licnsed under the GPL, which means as >long as the developers provide the source code changes that they >make, they can make the GIMP a part of anything they damn well >please. >Too many people use this license without understanding (or >considering fully) what it means... You're confusing legal rights with moral obligations. Since you raised legal nonsense, though, it's technically illegal for GNOME to use the GIMP trademark for promotional purposes without a license from the GIMP Development Team. The GPL grants a software license in copyright; it does NOT grant any rights to any other property, intellectual or otherwise. Kelly
Re: Print plug-in
On Tue, 1 Feb 2000 13:15:17 -0600 (CST), Tim Mooney <[EMAIL PROTECTED]> said: >I agree that would be the best solution, but I'm afraid it's not that >easy. I've submitted quite a few very small portability patches >against ORBit from as far back as the 0.3.X days, and virtually every >one of my patches has been rejected. I reported a "secret dependency" in ORBit on popt 1.4, and provided a simple patch. It has been ignored, and now Quartic is accusing me of "spreading FUD" even though I've clearly and publically documented that this dependency is NOT FUD. Nobody at GNOME appears even interested in pursuing this problem (which is quite subtle and evidence of very poor concern for portability); the only reason I can think of for this is that popt is universally present on Red Hat machines because it's part of RPM. Kelly
Re: Print plug-in
On Tue, 1 Feb 2000 19:09:14 +0100 (MET), [EMAIL PROTECTED] (Raphael Quinet) said: >This statement is ridiculous. They are not claiming that they wrote >the GIMP. They just state that it will be included as part of the >Gnome-Office suite. You'd think they talk to the GIMP developers before making that claim, no? >In case you did not know that, will this fact make you stop using the >GIMP completely just because you think that some of the people on >this list have GNOME stamped on their forehead? No, but I will stop using the GIMP if it begins to require Gnome libraries (or, actually, I will split development). >My personal opinion: I'm all for using some of the GNOME things >(especially gnome-font, gtk-pixbuf and gnome-canvas) as long as they >do not have any dependencies on ORBit or other stuff that is >difficult to compile on non-Linux systems or stuff that is simply not >needed. If Gnome gets its act together and properly cleans up their library offerings so it's not as monolithic and pointlessly dependent on ORBit I'll consider using some of their utility libraries. (GIMP really should use libart, but until libart is easily available separately from gnome-libs, we can't.) Kelly
Re: Print plug-in
On Tue, 01 Feb 2000 13:19:03 +0100, Torsten Rahn <[EMAIL PROTECTED]> said: >Of course I read on the >Gnome-Office-site that Gimp would be part of Gnome-Office. Well I was >quite surprised to read that as I didn't see any discussions about >this topic here. GNOME claims GIMP as part of GNOME because GIMP is better than any of the existing GNOME apps. They're trying to piggyback on our success. Personally, I think this is odious, but hey... Kelly
Re: Print plug-in
On Mon, 31 Jan 2000 21:30:48 -0500, Robert L Krawitz <[EMAIL PROTECTED]> said: >I'd argue that except for gconf and MAYBE gnome-canvas none of this >stuff belongs in GNOME at all; these are all very generic facilities >that shouldn't depend on any of the IPC, desktop, etc. stuff. >Otherwise we wind up with the same kind of confusion and versioning >problems that Windows has suffered with for so long. THis is one of my big annoyances with GNOME currently: there's a lot of useful libraries that really have nothing to do with GNOME but which are not separately exported, forcing you to install all the junk you don't want to get the stuff you do. Kelly
Re: Print plug-in
On Tue, 1 Feb 2000 01:18:54 +, Nick Lamb <[EMAIL PROTECTED]> said: >From the user's perspective The Gimp is part of GNOME. There's no good reason for users to have this perception, though, since the only relation GIMP has with GNOME is that GNOME uses GIMP's custom-developed widget set, and some of GNOME's developers are/were GIMP developers. Perhaps it is time for GIMP to move out of GNOME CVS. Kelly
Re: Print plug-in
On Mon, 31 Jan 2000 16:33:53 -0500, Federico Mena Quintero <[EMAIL PROTECTED]> said: >Kelly, please don't spread FUD. People build gnome-libs on Debian >boxes, old broken Slackware boxes, FreeBSD, Solaris, and other >beasts. What library are you talking about? popt. If you read gnome-hackers you'd already know about it since I posted there about this problem. ORBit would NOT build on my old slackware box until I installed this undocumented library. GNOME has a _lot_ of problems that it needs to clean up before it's ready for prime time on anything other than relatively vanilla RH or Debian box. Kelly
Re: Plugins at Sourceforge
On Mon, 31 Jan 2000 08:57:59 +0100 (CET), [EMAIL PROTECTED] said: >>>additional plug-ins. Some things, like translations, must be part >>>of the distribution currently. >>This needs to be fixed. :) > Do you volunteer? I don't understand translations at all. :) Kelly
Re: Colormanagement
On Sun, 30 Jan 2000 21:53:25 +0100, Marc Lehmann <[EMAIL PROTECTED]> said: >As long as they do not claim that their code is ANSI-C. I can >remember my first (and last) patch to the KDE developers that >converted their code to real C++, and they told me "F*ck off! Get a >real c++ compiler!". Ever since I became sensitive with such claims >;) That's KDE for ya. :) Kelly
Re: Colormanagement
On Sun, 30 Jan 2000 11:51:37 +0200 (FLE Standard Time), Tor Lillqvist <[EMAIL PROTECTED]> said: >Another thing is the licensing. The webpage says: "lcms is free and >source code is also provided, with only one limitation: you can do >whatsever you want with the code, except to sell it." However, it >also says: "I have now released lcms under GNU Lesser license >agreement" (and the actual source files also refer to the LGPL), >which seeems a bit confusing. Just a note: ambiguities in the terms or scope of a license are resolved in favor of the licensee. Kelly
Re: feature requests?
On Sun, 30 Jan 2000 01:31:52 +, Nick Lamb <[EMAIL PROTECTED]> said: >Gimp palettes are files :) Yes, but when you have LOTS of custom palettes, having "Reload" as the only way to get a new palette into the GIMP is NOT pleasant. (I have hundreds of custom palettes and have had, at times, THOUSANDS of custom gradients.) I'm not even sure that the PDB exports the reload option, either. >We shouldn't add more PDB interfaces to 1.1.x unless they fix a bug Unexported functionality, IMO, is a bug. Kelly
Re: The Gimp: New Generation
On Sun, 30 Jan 2000 02:09:21 +0100, Michael Natterer <[EMAIL PROTECTED]> said: >The main part of this standard will be: "Use the libgimp >constructors" ;-) Are those documented anywhere? (yeah, right) Kelly
Re: feature requests?
On Sun, 30 Jan 2000 00:11:47 +0100, Marc Lehmann <[EMAIL PROTECTED]> said: >If there were a way of adding a prominent notice like "DO NOT USE >THIS BUG-TRACKER TO REPORT GIMP BUGS, INSTEAD, GO TO http..."... Have you asked Sourceforge? Kelly
Re: feature requests?
On Sat, 29 Jan 2000 21:53:47 +, Nick Lamb <[EMAIL PROTECTED]> said: >All the existing plug-ins that work with palettes (INDEXED images >would be even more useless than they already are if no plug-ins could >work with them) use calls like: I guess it's GIMP palettes that are badly exposed. IIRC, there's no PDB call to create, modify, or destroy a palette. Indexed colormaps are obvously editable or the GIF plugin wouldn't work. :) Kelly
Re: feature requests?
On Sat, 29 Jan 2000 14:28:47 -0600 (CST), Dean Johnson <[EMAIL PROTECTED]> said: >Howdy, Is there a feature request database for Gimp? If not, I would >like to request that a bug group for feature requests (preferrably >with some level of urgency) be added to the bugtracker on >sourceforge. It would be nice to have an exhaustive list of what >people wanted and not depend on "institutional knowledge". GIMP feature requests should be submitted as "severity: wishlist" to the GNOME bug tracker. However, requests to _write plug-ins_ can be submitted as low-priority "bugs" on the Sourceforge page. >My request is a "sort color table" option so that I can more easily >reduce the color table by hand. If by "color table" you mean the indexed color palette, that will require core modifications (I believe) because I don't think palettes are exposed to plug-ins well enough to do operations on them. Kelly
Re: The Gimp: New Generation
On Sat, 29 Jan 2000 11:27:16 -0600 (CST), Dean Johnson <[EMAIL PROTECTED]> said: >EVERY gui developer (casual or not) should be required to read >Tufte's design books before being allowed to code. Heh. Send me copies and I'll gladly read them. :) Kelly
Re: The Gimp: New Generation
On Sat, 29 Jan 2000 10:59:23 +0100, Sven Neumann <[EMAIL PROTECTED]> said: >This is handled much better after Mitch overworked most plug-ins UI >once again. If you still find places that should be changed, please >provide a patch. If Mitch has gone to the effort to normalize existing plug-ins, I think would be nice of him to write up exactly what standards he followed so we can have a nice document on plug-in UI standards. :) Kelly
Re: The Gimp: New Generation
On Sat, 29 Jan 2000 10:53:54 +0200 (FLE Standard Time), Tor Lillqvist <[EMAIL PROTECTED]> said: >Drag small circles clockwise to increase V, counter-clockwise to >decrease V, for instance. It's hard to say without experimenting... Ew! What an evil idea! Kelly
Re: Plugins at Sourceforge
On Fri, 28 Jan 2000 19:18:53 -0500, Robert L Krawitz <[EMAIL PROTECTED]> said: >And yes, I agree with Michael also that 2002 is not a reasonable >target for the next stable release of the Gimp. Target dates are impossible to stick to. I offered 2002 because it took two years to go from 1.0 to 1.2. :) Kelly
Re: Plugins at Sourceforge
On Fri, 28 Jan 2000 23:47:25 +0100, Marc Lehmann <[EMAIL PROTECTED]> said: >Most (but of course not all) of the problems are related to the fact >that the menus are too full and can'T be changed, not necessarily >that too many plug-ins are installed (which is mostly a diskspace >problem). One of the things I would change is allow the user to specify where in the menu system a plug-in goes, when it is installed. The plug-in would provide a default. (Actually, I have a more progressive concept than this, but it's not fully fleshed out.) Kelly
Re: Print plug-in
On Fri, 28 Jan 2000 18:03:32 -0500, Federico Mena Quintero <[EMAIL PROTECTED]> said: >(As for footprint, well, the GIMP is not terribly lightweight either) >:-) GIMP's a lot lighter than gnome-libs. I would substantially oppose any serious dependence on gnome-libs in GIMP. Especially since gnome-libs appears to depend on a library that is only available if you have RPM installed. Kelly
Re: Plugins at Sourceforge
On Fri, 28 Jan 2000 21:40:56 +0100, Marc Lehmann <[EMAIL PROTECTED]> said: >One possible reason is that it is a pain in the ass to install >additional plug-ins. Some things, like translations, must be part of >the distribution currently. This needs to be fixed. :) Kelly
Re: important: automatic mirroring to the gimp cvs
On Fri, 28 Jan 2000 18:49:29 +0100, Marc Lehmann <[EMAIL PROTECTED]> said: >I am determined to branch the gimp-plug-ins tree at the same moment >the original gimp-cvs tree creates a stable branch. I guess that >might be the right moment to enable mirroring (to the main trunk, not >the stable branch)? No mirroring at all is my recommendation. Plug-ins should be out of the main branch altogether starting with 1.3. Kelly
Re: Plugins at Sourceforge
On Fri, 28 Jan 2000 11:55:20 -0700 (MST), "Michael J. Hammel" <[EMAIL PROTECTED]> said: >I'm curious why any new plug-ins should be added to the core *at >all*. Gimp's distribution is fairly large as it is. Isn't it >getting time to limit additional plug-ins to the core distribution to >plug-ins which are considered "vital" in some way? Even some estoric >file plug-ins need not necessarily be included with the core package. >Throwing in the kitchen sink is what's starting to bloat some Linux >distros. I agree entirely. It is my considered position that the first thing we should with 1.3 is remove all, or virtually all, of the plug-ins from the standard distribution. Moving them to the gimp-plug-in repository on sourceforge seems practical. All we need to do is develop a good installer tool before 1.4 rolls, which will probably be sometime in 2002. Kelly
Re: Plugins at Sourceforge
On Fri, 28 Jan 2000 12:40:32 -0500, Zach Beane - MINT <[EMAIL PROTECTED]> said: >Count this as a cry out against it. I suggest waiting for a logical >pause in development, such as the release of GIMP 1.2, to begin >making these not-insubstantial changes in source management. My position is sourceforge should be used at this time only for plug-ins which are not already in the source tree. Such plug-ins will not be a part of 1.2 anyway because 1.2 is frozen at this time. When 1.3 development begins, we can decide what to do with the plug-ins currently in the distribution. Kelly
Re: Plugins at Sourceforge
On Fri, 28 Jan 2000 17:29:48 +0100, Marc Lehmann <[EMAIL PROTECTED]> said: >As it is now there is the slight danger that the "self-management" >can cause _more_ work for the maintainers. If Sven has to od a >one-line change in every plug-in he would be force to use two >different cvs servers. Well, hopefully this sort of thing shouldn't have to happen; that would occur because of a noncompatible interface change and I'd like to think we can avoid that. (If the interfance needs to be changed, we should offer a "legacy mode" so unadapted plug-ins continue to function.) Kelly
PDB_PASS_THROUGH
I can find no evidence that this is actually used anywhere in the GIMP. Anybody know what it's for and whether it even works? Kelly
Re: important: automatic mirroring to the gimp cvs
On Fri, 28 Jan 2000 01:38:32 +0100, Marc Lehmann <[EMAIL PROTECTED]> said: >Ok. I've just enabled automatic mirroring from the sourceforge cvs >back to the gimp cvs. FWIW, I think this should be used sparingly. It is my belief that we should try to move plugins into a separate package from the GIMP core; I would be quite happy to see the plugin directory go away _entirely_ from the main GIMP CVS. This really isn't that big a deal. Lots of applications require multiple packages to get "everything", and GIMP is a _large_ application. Kelly
Re: Speaking of additional plug-ins
On Wed, 26 Jan 2000 14:31:52 +, "Steinar H. Gunderson" <[EMAIL PROTECTED]> said: >Better yet, a GIMP interface. If we are to change the entire plug-in >architecture anyway, we should make a single way of compiling and installing >them. I've thought about this somewhat. I had a vague idea in mind for how to redo the UI for 1.4/2.0, which included a considerably different way of handling plugins. Plugins would be installed w/i the Gimp interactively (a noninteractive installation procedure would be offered for system administrators) with the user being asked where to install the plugin in the menu tree and so forth. I've never gotten back to it, though. Kelly
gimp-developer@scam.xcf.berkeley.edu
On Wed, 26 Jan 2000 05:12:43 -0500, "Garry R. Osgood" <[EMAIL PROTECTED]> said: >It is a disservice to individuals on the periphery of the Gimp support >effort who, finding themselves with a spare weekend and a permissive >spouse, then have to trek through message lists to see what's up. I read this list infrequently; I have been known to go months without looking at it. (I got unsubscribed once and didn't realize it for five months.) On the other hand, the bug list I check frequently and I at least look at bug reports whenever they come in. I don't gate them automatically to their own folder, unlike this list, which means they get at least trivial immediate attention. PLEASE file bug reports, even if the matter seems trivial. Just try to ensure that the report has enough information that a developer can figure out what is going wrong. Thanks, Kelly
Re: [gimp-devel] Re: End-user feedback: Perl logulator & innerbevel
On Tue, 25 Jan 2000 20:53:30 +0100, Marc Lehmann <[EMAIL PROTECTED]> said: >As a matter of fact, I couldn't. Why do you think I could? Anybody can do anything, with enough effort. :) Kelly
Re: [gimp-devel] Re: End-user feedback: Perl logulator & innerbevel
On Tue, 25 Jan 2000 13:54:33 +0100, Marc Lehmann <[EMAIL PROTECTED]> said: >PLUGIN_MAINTAINERS is just a file... fatc is that bugs _do_ _not_ _get_ >_fixed_, so script-fu is basically unmaintained. You could, of course, fix them yourself. :) Kelly
bug #2355
Anybody understand what the guy in #2355 is asking for? It looks like he wants DynText layers to rerender on layer scale, which would be a major architectural change (not impossible, just not something that should be squeezed in under a freeze). Is this just a user misunderstanding? Kelly
Re: Addition of new plug-ins
On Fri, 21 Jan 2000 00:44:36 +0100, Sven Neumann <[EMAIL PROTECTED]> said: >Hi, >tonight two new plug-ins were checked into the tree. I now that we have not >officially declared a plug-in freeze, but I think it was somehow clear that >it is too late to add new plug-ins. The CVS ChangeLog claims: >Thu Jan 20 23:28:35 CET 2000 Stanislav Brabec <[EMAIL PROTECTED]> >Added new plug-ins from Martin Weber <[EMAIL PROTECTED]>: >* plug-ins/common/kaleidoscope.c: New file. I haven't looked but I assume this is my kaleidoscope plugin. I haven't approved it being added to CVS, and if nobody removes it before I get around to it I'll do so myself. If nothing else, the UI needs a lot of work before it should go in a production version. Somebody please kick Martin in the butt for me. Kelly
Re: gimp SWF plugin
On Sat, 15 Jan 2000 22:22:05 +0100, Marc Lehmann <[EMAIL PROTECTED]> said: >I don't see the problem (yet)? Plug-ins do not need to be GPL'ed (at >least not when the last rmeaining license bits have been resolved >;->) They do, however, have to be compatible with LGPL. That's not saying very much. :) Kelly
Re: Thanks (Re: Gimp splash images)
On Mon, 10 Jan 2000 18:43:23 +, alex <[EMAIL PROTECTED]> said: >Maybe the earlier splash images were only distributed in GIF format, >but then they moved to PPM after Burn All GIFs? Just a guess. The splash images have always been PPMs. You can retrieve all of them (at least since 1.00) from CVS by requesting specific versions of the splash file. Kelly
Re: Thanks (Re: Gimp splash images)
On Thu, 13 Jan 2000 09:45:50 -0800 (PST), Arcterex <[EMAIL PROTECTED]> said: >I personally like both the balloon and brush image. Maybe both can >fit in somewhere? I understand I'm just a lurker here and have no >real clout, but maybe one can be the splash (I'm thinking balloon) >and the brush one could be modified for the About image? We could be really evil and have multiple splash images, randomly selected at startup. :) Kelly
Re: [ANNOUNCE] GimpMill - A Sawmill Theme Tool
On Tue, 11 Jan 2000 00:55:10 +0800, Ian McKellar <[EMAIL PROTECTED]> said: >For each of the frame parts create a separate layer in the way >described above, but call each of these "PART: name" where name will >be used in the image name. To set frame part attributes append "name >= value" pairs to the frame part's layer's name (e.g. "PART: >closebutton class=close-button"). Finally to specify the difference >between the default frame decoration and the focussed, mouseover, etc >decoration you can optionally create layers called NORMAL, FOCUSED, >HIGHLIGHTED and CLICKED. These are merged with frame part layers >before they're saved. Often a black layer with 50% opacity in >"Multiply" mode will be what you're after, but if nececarry you can >provide complete replacement images. A convenient user-accessible parasite editor would make this sort of thing MUCH friendlier -- instead of having to use magic cookie layer names you'd just click on a button on the layer dialog and edit the layer's externally-defined properties Kelly
Re: [gimpwin-users] PNG blank display bug
On Sat, 08 Jan 2000 13:21:44 +0100, Sven Neumann <[EMAIL PROTECTED]> said: >I have changed the core so that it does not accept zero resolutions. >Additionally I have changed all plug-ins that try to set the resolution >to check the value and simply don't set it at all if it is invalid. Gimp >will then use the default set up by the user. Please make sure that XCF loading is not exempt from these checks. (XCF loads seem to bypass core sanity checking sometimes..) Kelly
Re: New plug-in
On Fri, 7 Jan 2000 23:40:02 +1100 (EST), Paul F Harrison <[EMAIL PROTECTED]> said: >I have made a plug-in that does some interesting things, like applying >a theme taken from one image and applying it to another, or making an >image tilable. More details at >http://yoyo.cc.monash.edu.au/~pfh/fixer/ >This is my first plug-in (and my first post to this list). Any comments >would be appreciated, especially about any GIMP conventions i may have >inadvertantly missed. It's incredibly slow, probably because you did a naive iteration across the image instead of using pixel regions. Doing direct iterations across a gimp image thrashes the system badly and is an evil thing to do. Please rewrite your code to use pixel regions and rerelease. (I'd do it myself but I'm on other tasks ATM.) Kelly
Re: New plug-in
On Fri, 07 Jan 2000 17:03:59 +0100, [EMAIL PROTECTED] (Guillermo S. Romero / Familia Romero) said: >>A question about patents. Is putting something on the web enough to >>prevent someone patenting it, or could someone download my plug-in and >>then patent the algorithm? >Your plugin is prior art so patents can not be taken. But web is still a >weird place, so you will have to convice lawyers that it is your and since >day X. >What I would do is to register your plugin (copyright office) or get an >official stamp (notary? I hope that is the correct word for the guy who does >that). In other words, an official doc that says that since day X your app >exists, and is yours. The best thing I can think of is to have a copy of the source code notarized and stored in a safe-deposit box. You could mail it to yourself, but a notarization is probably stronger legally (because the notary can testify). A copyright registration might not be sufficient since you're not required to deposit the full source code for a TX Unpub registration. It would provide evidence of prior art, at least; whether it would be sufficient, I can't say. Ask a patent lawyer. Kelly
Re: New plug-in
On Fri, 7 Jan 2000 11:16:54 -0500 (EST), Glyph Lefkowitz <[EMAIL PROTECTED]> said: >IANAL either, but the "quick and dirty" solution to this is just to print >out the code to your plugin, stick it in an envelope, and mail it to >yourself. This is archaic advice, and virtually useless. All doing that does is provide proof of date of authorship. It ceased to be legally meritorious in 1978 when the Copyright Act of 1976 took effect. Kelly
Alpha developer needed: Bugs #2223 and #3414
Could someone with an Alpha look at bugs #2223 and #3414? Something odd is going on here and I can't for the life of me figure out what. Thanks, Kelly
Re: high dynamic range images
On Mon, 25 Oct 1999 15:15:48 -0400, Gregory McLean <[EMAIL PROTECTED]> said: -> This would require substantial changes to the GIMP core to support. >Wasn't this something the 'HOLLYWOOD' branch in cvs was fiddling >with? Or did that branch wither and die? It's alive and well, but rather seriously divergent from the head branch. Merging the two would be a substantial effort. Kelly
Re: high dynamic range images
On Thu, 21 Oct 1999 17:04:52 -0400, "Byong Mok Oh" <[EMAIL PROTECTED]> said: >Sorry about that. High dynamic range image can be thought of as >having 3 floating point values for RGB instead of 8 or 16 bits per >channel (usually expressed in 4 unsigned chars as RGB and an >exponent). It is pretty hot in computer graphics since raytracing >algorithms can output not just color but actual "brightness" values >of the scene. This would require substantial changes to the GIMP core to support. It might be possible to load such an image, but it would have to be converted to standard 8-bit RGB (with concomitant information loss) to be manipulated. Kelly
Re: high dynamic range images
On Thu, 21 Oct 1999 15:28:48 -0400, "Byong Mok Oh" <[EMAIL PROTECTED]> said: >Hi, Has anyone written a plug-in that reads in a high dynamic range >images? You'll have to define what you mean by "high dynamic range image". Kelly
Re: Plugins
On Tue, 19 Oct 1999 02:29:52 +0200, Marc Lehmann <[EMAIL PROTECTED]> said: >>IMO, something akin to Perl's CPAN module would be a good idea for >>GIMP plugins. Don't look at me to write it, though >I volunteer, if I am allowed to use perl ;) I have no problem with using perl. People who don't have perl installed (are there really such people anymore?) can manually install things. :) Kelly
Re: Plugins
On Sat, 16 Oct 1999 22:31:09 +0200, Marc Lehmann <[EMAIL PROTECTED]> said: >So lets talk about alternative and sensible ways to solve this. ACE >is definitely more useful for the average gimp user than gap or >mosaic (although these are highly useful to some). IMO, something akin to Perl's CPAN module would be a good idea for GIMP plugins. Don't look at me to write it, though Kelly
Re: Plugins
On Thu, 14 Oct 1999 01:23:47 -0700, [EMAIL PROTECTED] said: >Hi everyone, can anyone add Kevin Turner's plugins Adaptive Contrast >Enhancement and AntiAlias and also the kaleidoscope plugin to GIMP >cvs. NO! There are already too many plugins in the main CVS package as it is. Adding more is just making a bad situation even worse. Kelly
Re: TS2KSendInfo: One question...
I am aware of the alternative to make a written offer. I didn't tell them about that option because I would MUCH prefer that they distribute the source. They can read the license for themselves if they want to find out about the other option. Kelly
Re: TS2KSendInfo: One question...
On Tue, 05 Oct 1999 09:40:21 +1000, Total Software 2000 <[EMAIL PROTECTED]> said: >At 02:07 PM 4/10/1999 -0500, you wrote: >>Do you include the source to the Gimp with this CD? >No the source code is not included. You are hereby requested and required to cease all distribution of this product. Failure to comply may result in substantial civil penalties for copyright infringement. I am a co-owner of the copyright in the Gimp. The GPL, which is the license which you are required to comply with if you wish to distribute the Gimp, requires that you distribute the source along with it. Please immediately reply indicating that you intend to comply with the license. Failure to comply may result in legal action being taken against you. Thank you for your cooperation in this matter. Kelly Martin
