Re: [Gimp-developer] Bug Bug 568150 With 'Resize window on zoom', zoom focus does not work when window is of maximum size
Hi, great. I trust that the solution is the right thing because Martin pointed out in the bug what should happen and where to repair it. Then what I need to do to get this patch applied to the git version of GIMP. Thanks, lxh ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Bug Bug 568150 With 'Resize window on zoom', zoom focus does not work when window is of maximum size
xianghang liu wrote: I think this bug can be fixed by the attached patch. great. I trust that the solution is the right thing because Martin pointed out in the bug what should happen and where to repair it. I have checked Photoshop CS5 and found it has a similar behavior. uhm, can I (without drama) say that that proves exactly nothing for us? in general, a the right UI solution for us is: - good UI design in general - fits the context of GIMP (metaphors, models, legacy) on both counts ps can be pointing in exactly the wrong direction. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Discussion - Bug 61499: GIMP deletes IPTC and other metadata
On 05/26/2010 02:23 AM, Jon E. Pearkins wrote: What is the best way to ask the GIMP Development team to consider dividing Bug 61499 into two separate tracks: serious bug (loss of metadata) and enhancement (view/edit metadata)? Hi, I agree loss of metadata is a serious issue, but I don't think there is a point in open up a separate catch all bug report for that unless there are patches to be attached. BR, Martin -- My GIMP Blog: http://www.chromecode.com/ GIMP 2.8 development still under control ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] On bug 373060 - allow to easily switch to last used tool
Damien wrote: I started working on bug 373060 - allow to easily switch to last used tool and ran into design problems, so am I taking this here. I already have a strong idea on what the feature should be https://bugzilla.gnome.org/show_bug.cgi?id=373060 I think what needs to be filtered out of that bug is that users' need to have a small ad-hoc arsenal of tools + tools settings + resources (colors, brushes, etc.) to quickly switch between to complete their current task. the context swapping solution is both too simple with two (current/ previous) tools + tools settings slots, and too opaque in how it works UI-wise with only one shortcut to do two things: store and recall. so actually two shortcuts are needed to do things. and those are only shortcuts, where is the primary UI that it is a shortcut for? another plan, long-term per-tool presets, are not the answer to this too, because the ad-hoc nature of the users' needs is not covered by it. it is all to static and targeted at persisting user's favourite tool settings over time. looking at the nature of the small ad-hoc arsenal of tools + tools settings + resources requirement, I think that a brainstormed mix of something I proposed ages ago, 'blobs of paint' or file palette, see: http://www.mmiworks.net/eng/publications/2007/05/lgm-top-gimp-user-requests_25.html under 4. better painting tools and something yahvuu has been brainstorming: http://gimp-brainstorm.blogspot.com/2009/05/palettes-smoking-carrots.html so a file specific working palette where any tool+settings (one thing), resource, plugin+parameters, color can be dragged in, dragged out and recalled to be the thing to use. this would form that small ad-hoc arsenal. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] On bug 373060 - allow to easily switch to last used tool
On 09.01.2010 14:27, peter sikking wrote: Damien wrote: I started working on bug 373060 - allow to easily switch to last used tool and ran into design problems, so am I taking this here. I already have a strong idea on what the feature should be https://bugzilla.gnome.org/show_bug.cgi?id=373060 I think what needs to be filtered out of that bug is that users' need to have a small ad-hoc arsenal of tools + tools settings + resources (colors, brushes, etc.) to quickly switch between to complete their current task. the context swapping solution is both too simple with two (current/ previous) tools + tools settings slots, and too opaque in how it works UI-wise with only one shortcut to do two things: store and recall. so actually two shortcuts are needed to do things. and those are only shortcuts, where is the primary UI that it is a shortcut for? Just an idea I had reading this: I could imagine that a good solution would be some kind of registers, where the actual tool and setting can be stored with a shortcut. For example (I don't know if these shortcuts are already used by gimp, it's only to show the idea) I have my brush with the settings and store it with Strg+Shit+1 to register 1. Then I can switch to another tool (or change the settings) and store it with Strg+Shift+2 to register 2. Now I can switch with Strg+1 and Strg+2 between the both registers. So I have up to 10 registers with tools and settings that I can easily switch between. The UI could be a register (sub)menu with store and load options for each register or even better an own dialog where all 10 (or only the used) registers are shown. Each with a small description of the tool that is stored there. Marcel ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] On bug 373060 - allow to easily switch to last used tool
2010/1/9 peter sikking pe...@mmiworks.net looking at the nature of the small ad-hoc arsenal of tools + tools settings + resources requirement, I think that a brainstormed mix of something I proposed ages ago, 'blobs of paint' or file palette, see: http://www.mmiworks.net/eng/publications/2007/05/lgm-top-gimp-user-requests_25.html under 4. better painting tools and something yahvuu has been brainstorming: http://gimp-brainstorm.blogspot.com/2009/05/palettes-smoking-carrots.html so a file specific working palette where any tool+settings (one thing), resource, plugin+parameters, color can be dragged in, dragged out and recalled to be the thing to use. this would form that small ad-hoc arsenal. I particularly like the idea of file specific paint blobs, though I think there can be a set of user/app-wide blobs that can share the same ui. Regarding the implementation, such a file specific set of tool presets would require to have them - gradients, brushes, palettes and fonts included - embedded in the xcf file. Is this currently possible ? If not, can this be afforded without breaking too much things ? I would love to work on such a feature but I think I can't play it by ear. This would require a lot more work than what I did. Damien. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] On bug 373060 - allow to easily switch to last used tool
On Sat, 2010-01-09 at 15:59 +0100, Damien de Lemeny-Makedone wrote: [...] Regarding the implementation, such a file specific set of tool presets would require to have them - gradients, brushes, palettes and fonts included - embedded in the xcf file. Is this currently possible ? If not, can this be afforded without breaking too much things ? They could also be in an external user preferences file, or even in a per-folder file, and be more like recent images... Another little usage scenario: For my part I've always wanted something like this with dodge/burn, because whenever I switch from dodge to burn on a grayscale engraving scan, I need to change the mode from highlights to shadows - the only combinations that really make much sense are dodge/highlights and burn/shadows, as otherwise you end up lightening the black stroke or leaving visible brush-strokes on the white background. I've never asked for it (Peter would say I was projecting my own really unusual workflow on other users :-) ) but the ability to save and switch between some combinations might be very useful. Years ago you used to see people with masking tape on the top of their keyboard, so they could write down the settings they'd bound to function keys... you still do in banks or a lot of offices. A nicer way to do this might be the ability to drag an icon from Tool Options onto the toolbox to make a new tool that's really a combination of default settings for an existing tool? Liam -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ Ankh: irc.sorcery.net irc.gnome.org www.advogato.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] On bug 373060 - allow to easily switch to last used tool
hi all, Liam R E Quin wrote: A nicer way to do this might be the ability to drag an icon from Tool Options onto the toolbox to make a new tool that's really a combination of default settings for an existing tool? in my mind, it's quite the other way round: An icon in the tool box represent a tool type and a Blob-o-Paint represents a fully setup tool. Ennobling Blobs-o-Paint to be 'proxy' paint contexts, i.e. you can apply tools and filters to BoPs just like you do on a layer, seems to open up a host of IxD options: - Wanna paint with saturation? Create a new BoP to specify the shape (i.e. spatial setup), then make it the current paint context and use Colors-Saturation on it. Eh voila, your 'magic paint' brush is ready. BoPs could also be split to represent 'double action' settings - then users can build their own dodge/burn, blur/sharpen, grain merge/extract tools etc. regards, yahvuu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] On bug 373060 - allow to easily switch to last used tool
Liam wrote: Another little usage scenario: For my part I've always wanted something like this with dodge/burn, because whenever I switch from dodge to burn on a grayscale engraving scan, I need to change the mode from highlights to shadows - the only combinations that really make much sense are dodge/highlights and burn/shadows, as otherwise you end up lightening the black stroke or leaving visible brush-strokes on the white background. I've never asked for it (Peter would say I was projecting my own really unusual workflow on other users :-) ) but the ability to save and switch between some combinations might be very useful. would you not be helped with 2 user presets for the dodge/burn tool, which you would choose alternating during using the tool? so per-tool presets would be the solution for your case (and, yes, millions of other cases where users _always_ use a couple of options setups alternatingly with a single tool) --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] On bug 373060 - allow to easily switch to last used tool
On Sat, Jan 9, 2010 at 8:21 PM, peter sikking pe...@mmiworks.net wrote: would you not be helped with 2 user presets for the dodge/burn tool, which you would choose alternating during using the tool? so per-tool presets would be the solution for your case (and, yes, millions of other cases where users _always_ use a couple of options setups alternatingly with a single tool) May it be noted that the tool presets of this nature already exist. they are just terrible to use. those little buttons and menus in tool options suck. So perhaps we could just start with making those tool presets usable? -- --Alexia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] On bug 373060 - allow to easily switch to last used tool
2010/1/9 Alexia Death alexiade...@gmail.com On Sat, Jan 9, 2010 at 8:21 PM, peter sikking pe...@mmiworks.net wrote: would you not be helped with 2 user presets for the dodge/burn tool, which you would choose alternating during using the tool? so per-tool presets would be the solution for your case (and, yes, millions of other cases where users _always_ use a couple of options setups alternatingly with a single tool) May it be noted that the tool presets of this nature already exist. they are just terrible to use. those little buttons and menus in tool options suck. So perhaps we could just start with making those tool presets usable? Hah, I just didn't think about those, but you're right : they do the per-tool-presets job quite well. Tool presets ui sucks a lot, but I'd say that all presets ui suck. I mean : if you want to quickly switch between presets and tune them, you have to keep a _lot_ of dockables on screen. Otherwise it is all switching between dockables, not to mention that you can't create a new brush/gradient/dynamics/foo from the foo-editor : you have to go back to the selector and click the new button, which will bring you back to the editor. The two available options are either a waste of space or a waste of time, that sucks. IMO, selectors and editors should really get merged, or editors should have a selector widget at least. I feel I'm going way off topic, but every presets UI enhancement seems related to this bug. Damien. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] On bug 373060 - allow to easily switch to last used tool
On Sat, 2010-01-09 at 19:21 +0100, peter sikking wrote: would you not be helped with 2 user presets for the dodge/burn tool, which you would choose alternating during using the tool? Yes, especially if I could bind keystrokes to switch to them. Liam -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ Ankh: irc.sorcery.net irc.gnome.org www.advogato.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] On bug 373060 - allow to easily switch to last used tool
Furthermore, Mitch pointed out that gimp has had that kind of feature ages ago, and I dug up a related commit from ChangeLog.pre-2-0 : - 2003-02-25 Sven Neumann s...@gimp.org * app/gui/tools-commands.[ch]: removed Swap Contexts functionality. -- Sven, may you remember what was the reason of this removal ? (7 years ago) If I remember correctly, we discussed this change on the mailing-list back then. You might be able to find more in the archives. As far as I can see the reason to remove this feature was that no one found it useful. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Solving Bug 356716 – GimpZo omPreview is broken in some plug-ins
Hi, On Thu, 2007-07-19 at 11:52 +0300, Aurimas Juška wrote: * jigsaw -- looks like lot of code would have to be changed to make it work with GimpZoomPreview correctly. However, I don't understand why this plug-in would need zoom preview at all. It doesn't do anything that someone would like to check at high zoom level. My suggestion: use GimpPreview instead. You probably mean GimpDrawablePreview as GimpPreview is abstract. I agree that it is probably best to go back to a simple scrollable preview for this plug-in. * polar, whirlpinch -- both need fetching pixels. Of course, it's possible to ask core to scale down some part, but I don't think we would like to do that for each pixel. Efficient solution would be to scale small regions (tiles) and cache them. For example, lens is doing that. However, it is not very easy to implement (or copy paste from somewhere) such functionality and I think such functionality should be provided by core. The core does the scaling quite efficiently. So unless it turns out to be a performance problem, I don't see any need to add complex caching to the plug-ins. If at all, this should be done in the GimpZoomPreview itself and we can leave that to be done for the time after 2.4. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] text bug [?]
Hi, Gezim Hoxha [EMAIL PROTECTED] writes: I'm using gimp2-pre2, when I do the following, something unwanted happens: 1.)Create a new image 2.)Click on the T (text tool) 3.)Go to the image 4.)Click and type away. All this works fine. 5.) Now you want to type something else in the same image, so you move the cursur to the place, click, and start typing, but this type nothing shows up on the image. Is this a bug or what? Is it fixed in pre3? It's about time to update to 2.0pre4 then: http://bugzilla.gnome.org/show_bug.cgi?id=124969 Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Bug 132698 - Script-Fu constants vs DB Browser
Hi, Kevin Cozens [EMAIL PROTECTED] writes: Another way to look at this is from he point of view of help/documentation. Someone has to create information somewhere that documents the constants used for plug-ins (whether they be C-based, Script-Fu, or Perl). Are you talking about the API docs at developer.gimp.org? Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Bug 132698 - Script-Fu constants vs DB Browser
On Thu, Jan 29, 2004 at 12:27:44PM -0500, Kevin Cozens [EMAIL PROTECTED] wrote: Is the - vs _ use in function names by C vs. Script-Fu historical (as in typical of the respective languages)? Yupp. values for plug-ins based on different languages? DB Browser shows GIMP_RGB_IMAGE for an image type (for C) but its only RGB-IMAGE for Script-Fu scripts and I have no idea off-hand what it would be for Perl plug-ins (a third set of enums?). Just FYI, perl uses the enums.pl from the gimp core which lists all the enums. It does, however, do this: $const =~ s/^GIMP_//; i.e.., strip the GIMP_-prefix, so the contants are the names with _ (easier to type in perl than -), but withouth the prefixes. Looks like a third set to me. (Also, perl isn't updated automatically, you have to run a script, so it might be sightly out of sync). -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Bug 132698 - Script-Fu constants vs DB Browser
At 09:01 AM 01/30/2004, Marc Lehmann wrote: Just FYI, perl uses the enums.pl from the gimp core which lists all the enums. It does, however, do this: $const =~ s/^GIMP_//; i.e.., strip the GIMP_-prefix, so the contants are the names with _ (easier to type in perl than -), but withouth the prefixes. Looks like a third set to me. A third set? I was afraid that might be the case. (Also, perl isn't updated automatically, you have to run a script, so it might be sightly out of sync). I will take a look at the way gimp-perl does things. The script should be invoked during a build process as it is for the core part of GIMP. Sven isn't sold on the idea of deprecating some of the constants yet. We already have deprecated constants as you can see in the comments in the siod-wrapper.c file. Another way to look at this is from he point of view of help/documentation. Someone has to create information somewhere that documents the constants used for plug-ins (whether they be C-based, Script-Fu, or Perl). If we have one set of constants for use in all plug-in languages the constants only need be documented once for C. For other languages you would need a one liner explaining whether they are the same as for C or whether you need to change _ to - and you are done. Otherwise, you need to have two or three lists all of which need to be updated if/when the API changes. Cheers! Kevin. (http://www.interlog.com/~kcozens/) Owner of Elecraft K2 #2172|What are we going to do today, Borg? E-mail:kcozens at interlog dot com|Same thing we always do, Pinkutus: Packet:[EMAIL PROTECTED]| Try to assimilate the world! #include disclaimer/favourite | -Pinkutus the Borg ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Bug 132698 - Script-Fu constants vs DB Browser
On Fri, Jan 30, 2004 at 11:57:32AM -0500, Kevin Cozens [EMAIL PROTECTED] wrote: i.e.., strip the GIMP_-prefix, so the contants are the names with _ (easier to type in perl than -), but withouth the prefixes. Looks like a third set to me. A third set? I was afraid that might be the case. Well, a set extremely similar and in-sync (at least loosely) to the C contants, so while technically different constant names, there is a very easy rule to convert from C to Perl: drop the GIMP_. The gimpdoc program already converts between C and Perl method syntax, so it could just be extended to drop DIMP_ for Contants, too. The pdb documentation is almost parseable nowadays (or at leats when I last looked). I will take a look at the way gimp-perl does things. Constants are hardcoded in Gimp.pm, and there is a program named insenums which will replace these in-place. The script should be invoked during a build process as it is for the core part of GIMP. Not so quickly ;) Changes in these enums will immediately break existing scripts, which is a very bad thing. Also, some wild renaming during the 1.3 era resulted in duplicated constants that had to be resolved differently, so this usually involves some manual work, which is why the script has to be run manually, too. Another way to look at this is from he point of view of help/documentation. Someone has to create information somewhere that documents the constants used for plug-ins (whether they be C-based, Script-Fu, or Perl). If we have one set of constants for use in all plug-in languages the constants only need be documented once for C. I am not sure wether I understand your concept of sameness. To me, GIMP_RGB_IMAGE, RGB-IMAGE and RGB_IMAGE is exactly the same constant, just as gimp-drawable-add-layer is the same as gimp_drawable_add_layer and $drawable-add_layer. For other languages you would need a one liner explaining whether they are the same as for C or whether you need to change _ to - and you are done. This is the situation with perl right now, although that line is probably hard to find, but people don't read this type of documentation anyway, they just look at other scripts, and then consistency really pays off. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Bug 132698 - Script-Fu constants vs DB Browser
On Fri, 2004-01-30 at 13:06, [EMAIL PROTECTED] wrote: On Fri, Jan 30, 2004 at 11:57:32AM -0500, Kevin Cozens [EMAIL PROTECTED] wrote: A third set? I was afraid that might be the case. Well, a set extremely similar and in-sync (at least loosely) to the C contants, so while technically different constant names, there is a very easy rule to convert from C to Perl: drop the GIMP_. The gimpdoc program already converts between C and Perl method syntax, so it could just be extended to drop DIMP_ for Contants, too. I will take a look at the way gimp-perl does things. Constants are hardcoded in Gimp.pm, and there is a program named insenums which will replace these in-place. For Script-Fu, the leading GIMP- part was being dropped. I will leave the gimp-perl stuff alone for now but for consistancy, it should be updated to accept the new versions of the enums as well as the existing (backwards compatible) ones. I am not sure wether I understand your concept of sameness. To me, GIMP_RGB_IMAGE, RGB-IMAGE and RGB_IMAGE is exactly the same constant, just as gimp-drawable-add-layer is the same as gimp_drawable_add_layer and $drawable-add_layer. It is a case of a rose by any other name or in this case a constant by any other name to paraphrase Shakespeare. Yes, GIMP_RGB_IMAGE, RGB-IMAGE, and RGB_IMAGE are numerically the same. If you use numerical values for function call arguments, then you use the same numbers regardless of plug-in language. On the other hand, if you want to create a new image using an indexed palette its easier to remember to use GIMP_INDEXED_IMAGE rather than 4 or was that INDEXED_IMAGE, or INDEXED-IMAGE? What type of plug-in am I writing again? :-) You get the idea. For other languages you would need a one liner explaining whether they are the same as for C or whether you need to change _ to - and you are done. This is the situation with perl right now, although that line is probably hard to find, but people don't read this type of documentation anyway, they just look at other scripts, and then consistency really pays off. Thats right. People often don't RTFM apart from the difficulty one often has finding relevant documentation. If you go to http://www.gimp.org/, click on documentation, scroll down to the PDB section, then click on the Procedural Data-Base link you get a page called pdb.html. Under Browsing the PDB, it states the following: Because the PDB includes info about plugins, scripts, and extensions, it is very dynamic. The easiest way to search and browse the PDB is to use the DB Browser extension included with the gimp. This is located under the Xtns menu on the main toolbar and allows you to browse and search through the PDB. Very handy. Followed a bit further down with: A typical use of the PDB is to write scripts or plugins. Very handy indeed, and no reference to differences in the named constants based on whether you are writing a script or a (C-based) plug-in. Another reason to keep things close to what is listed under the DB Browser. People are told to use the DB Browser information and yet, it provides misleading information that could frustrate the budding new script writer out there. And finally, on line 263 of plug-ins/script-fu/siod-wrapper.c is a comment which reads: These are for backwards compatibility; they should be removed sometime Following that comment are statements which allow the parser to understand the older constants (ie. the ones not starting with GIMP-). I ran a CVS annotate on this file and that comment and the start of the code below to which allows the accepting of the older forms of constants was in the file since the 1.1 version entered by user mathieu and dated July 17, 2001. It appears in the end that I have merely finished something that was started a long time ago. My patch to accept both old and new forms of the constants is attached to the bug report. I also have the patch and my script to convert from the 1.2 API to the 2.0 API on my web page at: http://pages.interlog.com/~kcozens/software/gimp/updates.html If you want to include the conversion script as part of the GIMP source (as a replacement for plug-ins/script-fu/convert-script) feel free to do so. I have made my case for making the change and provided a patch (sorry I forgot to include a ChangeLog entry), and script to update things to the 2.0 API. I now leave it in the hands of the judges...er...core GIMP developers to decide what they want to do with this. At least I will have a patch I can apply to my own copy of the GIMP should the patch not become part of the official GIMP source. -- Cheers! Kevin. (http://www.interlog.com/~kcozens/) Owner of Elecraft K2 #2172|What are we going to do today, Borg? E-mail:kcozens at interlog dot com|Same thing we always do, Pinkutus: Packet:[EMAIL PROTECTED]| Try to assimilate the world! #include disclaimer/favourite |
Re: [Gimp-developer] Re: Bug 132698 - Script-Fu constants vs DB Browser
On Fri, Jan 30, 2004 at 02:19:56PM -0500, Kevin Cozens [EMAIL PROTECTED] wrote:
regardless of plug-in language. On the other hand, if you want to create
a new image using an indexed palette its easier to remember to use
GIMP_INDEXED_IMAGE rather than 4 or was that INDEXED_IMAGE, or
INDEXED-IMAGE?
In perl, INDEXED-IMAGE needs to be quoted rather unnaturally
({'INDEXED-IMAGE'}), so perl users won't bother thinking about
this. Also, perl, unlike C, has mostly working namespaces, so prefixing
each and everything with an application/module name like GIMP_ is not
necessary.
Things are similar for script-fu (there are no namespace issues in
script-fu because it's self-contained and _ looks rather unnatural, I
think).
If somebody wants to write a plug-in in perl who only ever had written
plug-ins in C will have to think twice (at least), there is no doubt.
But a user having used perl before will look at some existing script
anyways (nobody writes plug-ins from scratch).
Think about the GIMP_ prefix as C's way to handle namespaces. As such,
it's part of the C calling convention only. This is handled different in
perl (Gimp::INDEXED_IMAGE or just INDEXED_IMAGE) and script-fu (script-fu
does not have a module or library concept to my knowledge, the the problem
of namespaces does not apply).
What type of plug-in am I writing again? :-) You get the idea.
Frankly, people forgetting which type of plug-in (in which language) they
are currently writing need professional help *g*.
I am rather convinced that the number of people who can't remember that
they are currently writing C as opposed to scheme is rather low compared
to people that are aware of this.
DB Browser. People are told to use the DB Browser information and yet,
it provides misleading information that could frustrate the budding new
script writer out there.
The DB Browser information should be consistent (i.e. for C _or_
scheme). The information in the DB Browser will never apply to perl
(python...) unless it would have a perl mode, as perl simply is a
different language with different calling conventions.
Constant names are a much smaller difference than calling conventions
between languages. It is, in general, impossible to use an API for one
language in another without adapting it to the target language.
And finally, on line 263 of plug-ins/script-fu/siod-wrapper.c is a
comment which reads:
These are for backwards compatibility; they should be removed sometime
It appears in the end that I have merely finished something that was
Cleaning up things by removing cruft like this is very useful, and often
being overlooked. Thanks for doing this :=
I'd also find it cool if you looked into the DB Browser and made it fully
scheme or fully C, i.e. consistent at least to one language. However,
the idea of having the same API, character-for-character, in all languages
is futile. Don't bother with it.
Changing script-fu to comply with this sounds ok, changing the Browser to
comply with script-fu is better, but more difficult (right now it's a mix
of both, or maybe the abstract PDB language?).
Perl specifically has a tool named gimpdoc, which shows calling
conventions in perl, e.g.:
layer = gimp_layer_new (image,width,height,type,name,opacity,mode)
layer = $image-layer_new (width,height,type,name,opacity,mode)
Which is close to actual perl, and should give developers the right
idea. It should convert constant names to perl form, too (it currently
doesn't, AFAICR). Having this info in the DB Browser might be useful, but
making the interface support all languages is quite difficult.
One could also argue that the DB Browser does things the abstract PDB
way, and is fine this way, although a bit unspecified, as long as rules
exist to convert them to specific implementations. In the case of perl,
these rules are stated in the Gimp manpage, which is a must-read if you
want to develop plug-ins from scratch.
--
-==- |
==-- _ |
---==---(_)__ __ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e|
-=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Bug 132698 - Script-Fu constants vs DB Browser
Hi, Kevin Cozens [EMAIL PROTECTED] writes: I'm also raising issue also because I thought that one of the goals for the 2.0 release is to simplify/tidy-up some things. Having more consistency in the enums used (regardless of language used for a plug-in/script and ignore - vs _ issues) makes sense (to me at least). Trying to get DB Browser to display different information based on you telling it which type of plug-in one wants to create is probably not a good alternative. I think it would add too much complexity and be hard to maintain. What are you advocating instead? Perhaps I just missed something but I have not been able to figure out what change you are proposing. The issue you raise has been around forever and it seems that so far you are the first one to find it disturbing enough to talk about it. Perhaps something should be done about this but I don't think it's a severe problem that would justify an incompatible change to any of the language bindings. IMO any language should be free to use the GIMP enum values in the way that is typical for the particular language. Script-Fu uses hyphens traditionally; why should we force it to using the (uglier) underscores that have to be used in the C language? Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Bug 132698 - Script-Fu constants vs DB Browser
At 12:45 PM 01/29/2004, Sven wrote: What are you advocating instead? Perhaps I just missed something but I have not been able to figure out what change you are proposing. The issue you raise has been around forever and it seems that so far you are the first one to find it disturbing enough to talk about it. I thought I had explained it in the bug report I filed but I will me try to make it clearer. In regards to the second point, perhaps it has disturbed other people but not enough to have mentioned it. you said yourself, Sven, in a comment to a bugzilla entry something to the effect that no one has expressed an interest in Script-Fu. I am still interested in Script-Fu. I am involved in a number of other projects so I haven't made the time to learn how to do a C-based plug-in. I find it easier to use Script-Fu to make a script that automates a set of steps I came up with to automate a procedure. In regards to the first point, I am advocating that the enum values shown in DB Browser (for C) be the same as the ones used in Script-Fu scripts (and other language bindings) to provide a better level of consistency across all plug-ins. That way, something you learned to use in one plug-in language doesn't have to be unlearned when you use a different language for plug-ins. For example, if I look in DB Browser for creating a new image, one of the enums shown for argument type is GIMP_RGB_IMAGE. So, since I know for Script-Fu scripts I use - in place of _, I would use GIMP-RGB-IMAGE. When I try running a script with this as things stand now, I will get an error message and be left scratching my head wondering what is wrong with the script since I followed the information shown in DB Browser. You, I, and many people on this list may have the source code available on their machines to figure out what the Script-Fu constants are as compared to what is shown in DB Browser but how many others will? Lately, I only update the collection of scripts on my web page to work with the latest GIMP when API changes. This means it can be a long time from one session of working with Script-Fu to another at my end. The handiest reference I have to refresh me on Script-Fu functions and their arguments is the DB Browser. An alternative would be to have a section of the help system explain that the information in DB Browser is for C plug-ins and provide a list showing the mapping between C enums to those of Script-Fu. This would still mean I have to dig through the help system when the DB Browser is still the quickest help system to access. Also, the help system can lag behind the state of the code at times too so it is not the best method during times of big changes. It would be easier if I could use GIMP-RGB-IMAGE in Script-Fu scripts as I would be led to believe from DB Browser. The only change needed to DB Browser would be adding the display of a comment before (or after) the functions entry information stating something like For Script-Fu scripts, change the _ in function names and arguments to -. Perhaps something should be done about this but I don't think it's a severe problem that would justify an incompatible change to any of the language bindings. If we are to make such a change, now is the time to do it. After all, we are going from a 1.2 release to a 2.0 release so it is to be expected that changes would need to be made to plug-ins from 1.2 to make them work in the new 2.0 version. The next opportunity to make a change would be for 2.2 which might be another year or two down the road but one wouldn't expect such incompatibilities in a minor bump in version (2.0 to 2.2). Changing enums (if one doesn't add new ones and make the old ones deprecated for a while) would mean most (or all) supplied scripts would need to be updated. I have a perl script which updates Script-Fu scripts from the 1.2 to 2.0 versions of the GIMP (except for three functions which have different argument lists). If enums were to change for Script-Fu it would be relatively easy to enhance my script to handle changes to enums as well. BTW, I will make the script available soon for others to try in case there are others out there who find old scripts they want to use with the 2.0 version of GIMP. PS. To all, please don't reply to messages I post to the list AND CC: me as well. Doing so gives me two copies of your message and I get enough e-mail already. I have been a subscriber to this list, and made my small contributions to the GIMP, since the days of the 0.9 series of the GIMP. I have been on gimp-announce too since late 1997. Cheers! Kevin. (http://www.interlog.com/~kcozens/) Owner of Elecraft K2 #2172|What are we going to do today, Borg? E-mail:kcozens at interlog dot com|Same thing we always do, Pinkutus: Packet:[EMAIL PROTECTED]| Try to assimilate the world! #include disclaimer/favourite | -Pinkutus the Borg ___
Re: [Gimp-developer] Re: Bug 132698 - Script-Fu constants vs DB Browser
Hi, Kevin Cozens [EMAIL PROTECTED] writes: For example, if I look in DB Browser for creating a new image, one of the enums shown for argument type is GIMP_RGB_IMAGE. So, since I know for Script-Fu scripts I use - in place of _, I would use GIMP-RGB-IMAGE. When I try running a script with this as things stand now, I will get an error message and be left scratching my head wondering what is wrong with the script since I followed the information shown in DB Browser. So the easiest solution would be to make script-fu accept the enums with or without prefix. If we are to make such a change, now is the time to do it. The point is that it is already way too late to do any major incompatible change. Our API was frozen from the moment we did the first 2.0pre release. However I don't see any problem in accepting a patch for Script-Fu that makes it accept enums prefixed with GIMP-. Should be a trivial change. The next opportunity to make a change would be for 2.2 which might be another year or two down the road but one wouldn't expect such incompatibilities in a minor bump in version (2.0 to 2.2). Since we want 2.2 to be API compatible with 2.0, we couldn't do an incompatible change for 2.2. On the other hand 2.2 is scheduled for this summer, not in a year or two. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Bug 132698 - Script-Fu constants vs DB Browser
At 04:06 PM 01/29/2004, you wrote: So the easiest solution would be to make script-fu accept the enums with or without prefix. That would be the easiest solution and maintains compatibility with existing scripts. The point is that it is already way too late to do any major incompatible change. Our API was frozen from the moment we did the first 2.0pre release. I realize that. I had no intention of suggesting a change to the API. Just a change to the enums/constants used by Script-Fu. However I don't see any problem in accepting a patch for Script-Fu that makes it accept enums prefixed with GIMP-. Should be a trivial change. Since it was my suggestion, I suppose that falls in my lap. :-) I'm fairly certain it is trivial. It is more a matter of ensuring that the additions to what is accepted match against what is shown in the DB Browser. If all internal enums/constants start with GIMP- then no problem. The only remaining question is whether the old (non GIMP- prefixed) enums for Script-Fu should be deprecated for later removal and how that should be indicated (or just documented). I will check the help documentation to see if there is any information about Script-Fu scripts that would need to be updated/changed. Cheers! Kevin. (http://www.interlog.com/~kcozens/) Owner of Elecraft K2 #2172|What are we going to do today, Borg? E-mail:kcozens at interlog dot com|Same thing we always do, Pinkutus: Packet:[EMAIL PROTECTED]| Try to assimilate the world! #include disclaimer/favourite | -Pinkutus the Borg ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Fwd: [Bug 123647] Changed - Allow attaching additional (hidden) keybindings (accelerators) to menu entries]
Hi, If this is an almost-concensus (only myself, Alan Horkan and Raphael seem to like the change), it seems reasonable to revert the redo shortcut to Ctrl-R. Cheers, Dave. Tom Mraz wrote: FYI (multiple keybindings per menu action in GTK+). As I see it will be implemented in GTK+ 2.4 I vote for leaving the current redo keybinding as is and wait for GTK+ 2.4 with the change. Tom Mraz Original Message Subject: [Bug 123647] Changed - Allow attaching additional (hidden) keybindings (accelerators) to menu entries http://bugzilla.gnome.org/show_bug.cgi?id=123647 Changed by [EMAIL PROTECTED] --- shadow/123647 Wed Oct 1 13:49:47 2003 +++ shadow/123647.tmp.32485 Wed Oct 1 17:09:22 2003 @@ -1,13 +1,13 @@ Bug#: 123647 Product: gtk+ Version: 2.2.x OS: Linux OS Details: -Status: NEW -Resolution: +Status: RESOLVED +Resolution: FIXED Severity: enhancement Priority: Normal Component: gtk AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] TargetMilestone: --- @@ -16,6 +16,10 @@ It should be possible to attach additional (hidden) keybindings (accelerators) to menu entries. It would be a very useful functionality for backward (or another app) compatibility. + +--- Additional Comments From [EMAIL PROTECTED] 2003-10-01 17:09 --- +This will be possible in 2.4 using accelerator elements with the new +GtkUIManager. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Fwd: [Bug 123647] Changed - Allow attaching additional (hidden) keybindings (accelerators) to menu entries]
On Thu, 2 Oct 2003 08:34:25 +0200, David Neary [EMAIL PROTECTED] wrote: If this is an almost-concensus (only myself, Alan Horkan and Raphael seem to like the change), it seems reasonable to revert the redo shortcut to Ctrl-R. Please don't. If you replace the current Ctrl-Shift-Z by something else, try to replace it by something that is used by some other applications, such as Ctrl-Y. Do not bring back the old Ctrl-R. By the way, I just noticed that the nice GTK+ mail reader that I am using (sylpheed) uses Ctrl-Y as a Redo shortcut. ;-) -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Fwd: [Bug 123647] Changed - Allow attaching additional (hidden) keybindings (accelerators) to menu entries]
Raphaël Quinet ([EMAIL PROTECTED]) wrote: On Thu, 2 Oct 2003 08:34:25 +0200, David Neary [EMAIL PROTECTED] wrote: If this is an almost-concensus (only myself, Alan Horkan and Raphael seem to like the change), it seems reasonable to revert the redo shortcut to Ctrl-R. Please don't. If you replace the current Ctrl-Shift-Z by something else, try to replace it by something that is used by some other applications, such as Ctrl-Y. Do not bring back the old Ctrl-R. Please do. There is an overwhelming precedence of the usage of CTRL-R for Undo. It has a large Userbase and is quite popular. It is The GIMP 1.2. Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Fwd: [Bug 123647] Changed - Allow attaching additional (hidden) keybindings (accelerators) to menu entries]
On Thu, Oct 02, 2003 at 11:03:02AM +0200, Simon Budig wrote: If this is an almost-concensus (only myself, Alan Horkan and Raphael seem to like the change), it seems reasonable to revert the redo shortcut to Ctrl-R. Please don't. If you replace the current Ctrl-Shift-Z by something else, try to replace it by something that is used by some other applications, such as Ctrl-Y. Do not bring back the old Ctrl-R. Please do. There is an overwhelming precedence of the usage of CTRL-R for Undo. It has a large Userbase and is quite popular. It is The GIMP 1.2. I would not change the shortcut if it will be changed with GTK 2.4 anyway. Just stick with CTRL-R. This way, we can later provide an alternative more sane extra shortcut using GTK 2.4. Bye, Tino -- * LINUX - Where do you want to be tomorrow? * http://www.tu-chemnitz.de/linux/tag/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Fwd: [Bug 123647] Changed - Allow attaching additional (hidden) keybindings (accelerators) to menu entries]
Hi, Raphal Quinet [EMAIL PROTECTED] writes: On Thu, 2 Oct 2003 08:34:25 +0200, David Neary [EMAIL PROTECTED] wrote: If this is an almost-concensus (only myself, Alan Horkan and Raphael seem to like the change), it seems reasonable to revert the redo shortcut to Ctrl-R. Please don't. If you replace the current Ctrl-Shift-Z by something else, try to replace it by something that is used by some other applications, such as Ctrl-Y. Do not bring back the old Ctrl-R. Unless Ctrl-Y collides with another suggested shortcut in the HIG, it seems like a reasonable choice then. We should ask the HIG people to make this the suggested Redo shortcut. BTW, as Guillermo already pointed out, there are some more shortcuts, like for example the one for Duplicate, where the HIG differs from our defaults. We should consider to change these. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Fwd: [Bug 123647] Changed - Allow attaching additional (hidden) keybindings (accelerators) to menu entries]
Hi, [EMAIL PROTECTED] (Tino Schwarze) writes: I would not change the shortcut if it will be changed with GTK 2.4 anyway. Just stick with CTRL-R. This way, we can later provide an alternative more sane extra shortcut using GTK 2.4. I don't think we ever want a second shortcut for anything. We should settle on a good default now. Since the HIG people seem willing to change their mind on Shift-Ctrl-Z because of the obvious ergonomic problems of this keybinding, we can decide now if we want Ctrl-R or Ctrl-Y. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Fwd: [Bug 123647] Changed - Allow attaching additional (hidden) keybindings (accelerators) to menu entries]
Hi, Sven Neumann wrote: Raphaël Quinet [EMAIL PROTECTED] writes: try to replace it by something that is used by some other applications, such as Ctrl-Y. Do not bring back the old Ctrl-R. Unless Ctrl-Y collides with another suggested shortcut in the HIG, it seems like a reasonable choice then. We should ask the HIG people to make this the suggested Redo shortcut. Agreed. BTW, as Guillermo already pointed out, there are some more shortcuts, like for example the one for Duplicate, where the HIG differs from our defaults. We should consider to change these. Also agreed :) Does anyone have a complete list of these other clashing shortcuts, or does someone need to draw it up? Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Fwd: [Bug 123647] Changed - Allow attaching additional (hidden) keybindings (accelerators) to menu entries]
Will you excuse me...but ..what CTRL-Y has to with REDO alltogether? CTRL + R - R is the first letter in REDO. SHIFT + CTRl + Z - Shift acts as amodifier to the CTRL + Z UNDO. CTRl + X - Stays next to Z and allows for fat toggling as has been argued. But... CTRL-Y? Why not just stick with CTRL+R? Maybe to pick the worst of both worlds? (Non standard shortcut + non mnemonic + change from GIMP 1.2 + Have to use both hands to press) Please CTRL+R for REDO, and for California Gov.! Sven Neumann wrote: Hi, Raphal Quinet [EMAIL PROTECTED] writes: On Thu, 2 Oct 2003 08:34:25 +0200, David Neary [EMAIL PROTECTED] wrote: If this is an almost-concensus (only myself, Alan Horkan and Raphael seem to like the change), it seems reasonable to revert the redo shortcut to Ctrl-R. Please don't. If you replace the current Ctrl-Shift-Z by something else, try to replace it by something that is used by some other applications, such as Ctrl-Y. Do not bring back the old Ctrl-R. Unless Ctrl-Y collides with another suggested shortcut in the HIG, it seems like a reasonable choice then. We should ask the HIG people to make this the suggested Redo shortcut. BTW, as Guillermo already pointed out, there are some more shortcuts, like for example the one for Duplicate, where the HIG differs from our defaults. We should consider to change these. Sven ___ 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
Re: [Gimp-developer] [Fwd: [Bug 123647] Changed - Allow attaching additional (hidden) keybindings (accelerators) to menu entries]
On Thu, 02 Oct 2003 09:19:11 -0300, Joao S. O. Bueno [EMAIL PROTECTED] wrote: Will you excuse me...but ..what CTRL-Y has to with REDO alltogether? For better or worse, Ctrl-Y is the most frequently used shortcut for Redo. CTRL-Y? Why not just stick with CTRL+R? Maybe to pick the worst of both worlds? (Non standard shortcut + non mnemonic + change from GIMP 1.2 + Have to use both hands to press) Ctrl-Y is the shortcut used by most Windows applications (except for Photoshop and Paint Shop Pro, using Ctrl-Shift-Z and Ctrl-Alt-Z) so it is likely that most users will already be know it. If we consider the applications for Linux or UNIX-like systems, then we find Mozilla that is also using Ctrl-Y. I discovered several others in the meantime, such as the mail client that I am using right now (sylpheed). As I have argued earlier, we should try to promote consistency with other applications whenever possible, because the majority of GIMP users are not using the GIMP frequently and it will be easier for them to remember shortcuts (or any other way to perform a given task) if they can re-use their knowledge from other applications. This is more important than trying to keep the same shortcuts as in previous versions of the GIMP, especially because the experienced users like you and me can rebind them easily. -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Fwd: [Bug 123647] Changed - Allow attaching additional (hidden) keybindings (accelerators) to menu entries]
Hi, Raphal Quinet [EMAIL PROTECTED] writes: Ctrl-Y is the shortcut used by most Windows applications (except for Photoshop and Paint Shop Pro, using Ctrl-Shift-Z and Ctrl-Alt-Z) As far as I understood, Photoshop uses Ctrl-Z for redo. Actually a redo in PS is just an undo of the previous undo step. Ctrl-Shift-Z gives access to earlier Undo steps but it's not actually a Redo action. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Fwd: [Bug 123647] Changed - Allow attaching additional (hidden) keybindings (accelerators) to menu entries]
Hi, Tom Mraz [EMAIL PROTECTED] writes: FYI (multiple keybindings per menu action in GTK+). As I see it will be implemented in GTK+ 2.4 I vote for leaving the current redo keybinding as is and wait for GTK+ 2.4 with the change. The new menu API in GTK+-2.4 will solve quite a few of our problems. I am really looking forward to have the GIMP HEAD branch depend on 2.4 after the GIMP-2.0 release is out. Then we can finally clean up this menu mess. The new GTK+ menu API really looks very promising. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Fwd: Bug#148412: gimp1.2: Gimp is not consistently licensed]
OK, so the big problem is Script-Fu because it's fairly embedded and it's somewhat hairy. The ordinary plugins aren't much of a problem, in the very worst case they can be removed from the distribution temporarily. Surely the #1 thing someone should be doing (preferably someone who actually knows about Script-Fu) is to contact the copyright holders for the obnoxiously licensed Script-Fu code and ask them very politely if they would let us include that code in some GPL software, with proper credits of course, but without the unacceptable license terms ? Please someone figure out who to contact, mail them and CC the list. Nick. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Fwd: Bug#148412: gimp1.2: Gimp is not consistently licensed]
On 07 Jun 2002 16:35:46 +0200, Sven Neumann [EMAIL PROTECTED] wrote: RaphaXl Quinet [EMAIL PROTECTED] writes: ./plug-ins/common/gif.c (David Koblas) ./plug-ins/common/tiff.c(Patrick J. Naughton) We already knew about at least these and I was told (on #gimp I think) that it was not a problem. Whoever told you that was wrong. The text of both licenses includes: provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation. This is the advertising clause that is not compatible with the GPL. As a result, these files cannot be distributed with the GIMP as they are now. I don't see the problem. The code has the copyright notice as is required by the original license. We explicitely state the original authors. Where the heck is the problem?? Same applies for gimp-remote and the webbrowser plug-in. Unfortunately, the license used in these files contains the advertising clause that is incompatible with the GPL. The copyright notice and the permission notice must appear not only in the code, but also in the supporting documentation (help pages, GIMP manual, whatever). This extends to any derivative works, so this is not compatible with the GPL because anyone re-using this code for any purpose would be required to add these notices in the code and in the documentation. The GPL does not allow that kind of restrictions: You may not impose any further restrictions on the recipients' exercise of the rights granted herein. Another problem is that the GIMP (the whole package, not only the core) is usually advertised as being released under the GPL (or GPL + LGPL). This is what is mentioned on our home page (www.gimp.org) and this is what appears in most binary distributions. This is stated for example in gimp.spec.in, which creates gimp.spec for RPM distros. The GPL cannot be applied to the whole package, because of the problems mentioned above. So we have to change the license for the source tarball and try to inform those who build binary packages, or stop distributing the files that are not GPL-compatible. Reminder: the corresponding report in our Bugzilla is: http://bugzilla.gnome.org/show_bug.cgi?id=83362 -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Fwd: Bug#148412: gimp1.2: Gimp is not consistently licensed]
Hi, RaphaXl Quinet [EMAIL PROTECTED] writes: Unfortunately, the license used in these files contains the advertising clause that is incompatible with the GPL. The copyright notice and the permission notice must appear not only in the code, but also in the supporting documentation (help pages, GIMP manual, whatever). This extends to any derivative works, so this is not compatible with the GPL because anyone re-using this code for any purpose would be required to add these notices in the code and in the documentation. The GPL does not allow that kind of restrictions: You may not impose any further restrictions on the recipients' exercise of the rights granted herein. I don't see any problem in adding the necessary info to the documentation that comes with the respective plug-ins. IMO it should be sufficient to change the gimp-remote man-page and add the info to the help-pages for the affected plug-ins. We could also mention the facts in our README but then we have IMO advertized the facts well enough to satisfy everyone. But, of course, IANAL. Perhaps we should ask the FSF for legal advice? Another problem is that the GIMP (the whole package, not only the core) is usually advertised as being released under the GPL (or GPL + LGPL). This is what is mentioned on our home page (www.gimp.org) and this is what appears in most binary distributions. This is stated for example in gimp.spec.in, which creates gimp.spec for RPM distros. The GPL cannot be applied to the whole package, because of the problems mentioned above. So we have to change the license for the source tarball and try to inform those who build binary packages, or stop distributing the files that are not GPL-compatible. I don't agree. The core and libgimp is GPL and LGPL and should be advertized as such. Noone will ever link against one of the affected plug-ins and calling them through the PDB shouldn't be an issue. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Fwd: Bug#148412: gimp1.2: Gimp is not consistently licensed]
Hi, RaphaXl Quinet [EMAIL PROTECTED] writes: ./gimp-1.2.1.in (Spencer Kimball, Peter Mattis) ./gimptool-1.2.1.in (Owen Taylor, Manish Singh) This is gibberish. Someone bolted on some boiler plate which claims that the whole of the GIMP is covered by an obnoxious advertising clause. Most likely this happened because they copied an existing manual page source from another project. AFAIK, that license refers to the manual pages, not to the whole program. It was certainly added there by mistake, considering who the authors of these manual pages are. So in that case it is probably safe to fix the license immediately. ack. I'll leave this up to Yosh since he's one of the authors and may change these lines. Note that Ben was not the one complaining. He simply forwarded the Debian bug report from Anthony DeRobertis. And the license is wrong anyway, regardless of who wrote the manual pages. ./plug-ins/common/gif.c (David Koblas) ./plug-ins/common/tiff.c(Patrick J. Naughton) We already knew about at least these and I was told (on #gimp I think) that it was not a problem. Whoever told you that was wrong. The text of both licenses includes: provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation. This is the advertising clause that is not compatible with the GPL. As a result, these files cannot be distributed with the GIMP as they are now. I don't see the problem. The code has the copyright notice as is required by the original license. We explicitely state the original authors. Where the heck is the problem?? Same applies for gimp-remote and the webbrowser plug-in. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Fwd: Bug#148412: gimp1.2: Gimp is not consistently licensed]
On Wed, 29 May 2002 18:30:43 +0100, Nick Lamb [EMAIL PROTECTED] wrote: On Wed, May 29, 2002 at 01:26:07PM +0200, Raphaël Quinet wrote: ./gimp-1.2.1.in (Spencer Kimball, Peter Mattis) ./gimptool-1.2.1.in (Owen Taylor, Manish Singh) This is gibberish. Someone bolted on some boiler plate which claims that the whole of the GIMP is covered by an obnoxious advertising clause. Most likely this happened because they copied an existing manual page source from another project. AFAIK, that license refers to the manual pages, not to the whole program. It was certainly added there by mistake, considering who the authors of these manual pages are. So in that case it is probably safe to fix the license immediately. The presence of this boilerplate is a documentation bug, and can be fixed by removing the boilerplate or replacing it with a statement about the GNU GPL. The GPL is not really appropriate for the manual pages. Instead, we should use a BSD-like license without the advertising clause. So we can keep what is already there and just remove that requirement from the license. We could also switch to the FDL, but that would be a significant change that must be discussed with the authors first. Ben is even complaining about a manual page that he himself wrote, claiming that it is copyrighted software written by other people. Please don't substitute 'grep' for a working brain. Note that Ben was not the one complaining. He simply forwarded the Debian bug report from Anthony DeRobertis. And the license is wrong anyway, regardless of who wrote the manual pages. ./plug-ins/common/gif.c (David Koblas) ./plug-ins/common/tiff.c(Patrick J. Naughton) We already knew about at least these and I was told (on #gimp I think) that it was not a problem. Whoever told you that was wrong. The text of both licenses includes: provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation. This is the advertising clause that is not compatible with the GPL. As a result, these files cannot be distributed with the GIMP as they are now. The other files are more annoying. The first thing to do would be to remove the GPL statement at the top of theses files because it is incompatible with the advertising clause. That's nice but you can't redistribute my code under this alternative license. So you must rewind to a Gimp 0.6x era tiff.c plugin if that's the preferred solution. This is a serious problem. If we cannot contact the authors of the code that was borrowed for various plug-ins and ask them for permission to re-license their code under the GPL, then the only other option is to use a different license than the GPL for these plug-ins. If this is not possible (as in your case), then we must remove the plug-ins from the distribution until someone finds the time to re-write the code. -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Fwd: Bug#148412: gimp1.2: Gimp is not consistentlylicensed]
On Fri, 31 May 2002, Raphaël Quinet wrote: ./plug-ins/common/gif.c (David Koblas) ./plug-ins/common/tiff.c(Patrick J. Naughton) We already knew about at least these and I was told (on #gimp I think) that it was not a problem. Whoever told you that was wrong. The text of both licenses includes: provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation. This is the advertising clause that is not compatible with the GPL. As a result, these files cannot be distributed with the GIMP as they are now. Wouldn't it only have to appear in documentatoin supporting *the gif and tiff plugins themselves*, not GIMP in general? They are, after all, separate programs. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Fwd: Bug#148412: gimp1.2: Gimp is notconsistently licensed]
On Wed, 2002-05-29 at 10:36, Raphaël Quinet wrote: The libraries used by the plug-ins use the LGPL, not the GPL. I'm glad to hear that! Since the LGPL allows you to link proprietary code, I imagine that old-style BSD is just fine. So those just need splitting out at most. The only plug-in that contains a significant amount of GPL code and GPL-incompatible code is the Script-Fu interpreter. That will be a mess to clean up. But for most plug-ins, it should not be too difficult to contact the authors and ask for an exception. It'd certainly be easiest if they were willing to license under the GPL. I don't believe it is. See GPL clause 7: [...] Well, I'm not sure. If the GIMP tarball is considered to be a mere aggregate of independent software packages (the main application and its plug-ins), I'm not sure how the plugins are used by GIMP. The FSF says http://www.fsf.org/licenses/gpl-faq.html#GPLAndPlugins also: http://www.fsf.org/licenses/gpl-faq.html#TOCMereAggregation It's very arguable that GIMP and its plugins are effectively one program. Especially since GIMP plugins can only be used from GIMP, integrate into the mnus of GIMP, etc. signature.asc Description: This is a digitally signed message part
Re: [Gimp-developer] [Fwd: Bug#148412: gimp1.2: Gimp is not consistentlylicensed]
On 30 May 2002, Anthony DeRobertis wrote: On Wed, 2002-05-29 at 10:36, Raphaël Quinet wrote: I'm not sure how the plugins are used by GIMP. gimp opens a pipe, spawns the child plugin process, and communicates using a relatively simple protocol. The FSF says http://www.fsf.org/licenses/gpl-faq.html#GPLAndPlugins also: http://www.fsf.org/licenses/gpl-faq.html#TOCMereAggregation It's very arguable that GIMP and its plugins are effectively one program. Especially since GIMP plugins can only be used from GIMP, integrate into the mnus of GIMP, etc. There are other programs that can run gimp plugins. (well, gimp 1.0 plugins at least) Of course, the question of plugins is almost academic, becuase the copyright holders of GIMP have explicitly stated that they don't consider propriatary plugins to be infringing. If they won't sue over it, who can? (Note that I am NOT suggesting that we shouldn't make GIMP's licensing kosher) Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Fwd: Bug#148412: gimp1.2: Gimp is not consistently licensed]
On Tue, 28 May 2002 14:52:53 -0700, Ben Gertzfield [EMAIL PROTECTED] wrote: Howdy GIMP folks. Here are some points in the licensing of GIMP that need to be addressed. Specifically, there's a lot of code that requires that the authors be mentioned in the documentation, but there is no mention of them anywhere. Hmmm... This is bad, because this is not compatible with the GPL. So we must either stop distributing these files or distribute them in a separate package that is not GPL'ed. I'm not really up to speed with these issues, so if discussion is needed, please bring it up with Anthony DeRobertis [EMAIL PROTECTED], the originator of this bug report. I don't know if you want to get a copy of the messages and if I should also CC them to the debian bug tracker. If not, please mention it on the gimp-developer mailing list before others do the same mistake as I am doing right now. ;-) Here is a sorted list of files that have copyright notices that are not compatible with the GPL (derivatives of the BSD license with the so-called advertising clause): ./gimp-1.2.1.in (Spencer Kimball, Peter Mattis) ./gimptool-1.2.1.in (Owen Taylor, Manish Singh) ./install-sh(M.I.T.) ./plug-ins/common/edge.c(Jef Poskanzer) ./plug-ins/common/gif.c (David Koblas) ./plug-ins/common/mail.c(CMU and Bellcore) ./plug-ins/common/nlfilt.c (Graeme W. Gill) ./plug-ins/common/tiff.c(Patrick J. Naughton) ./plug-ins/webbrowser/webbrowser.c (Netscape, Jamie Zawinski, Andreas Stolcke, Solbourne Computer) ./plug-ins/script-fu/interp_slib.c (Paradigm Associates, Inc.) ./tools/gimp-remote.c (Netscape, Jamie Zawinski) The first two files in the list are manual pages copyrighted by Spencer Kimball and Peter Mattis and by Owen Taylor and Manish Singh. I think that the advertising clause is an accident and they did not intend to have a license that is not compatible with the GPL, but we should ask them to be sure (the copyright holders are the only ones who are allowed to change the terms of the license). The install-sh file is part of automake. It should not be too hard to replace it by a similar file that is compatible with the GPL, because this is a relatively short shell script. I thought that the automake developers had already changed this file, but apparently not. The other files are more annoying. The first thing to do would be to remove the GPL statement at the top of theses files because it is incompatible with the advertising clause. From a legal point of view, these files cannot be distributed as they are now, so we must at least change their license immediately and then think about what we can do with these non-GPL files. We cannot simply remove them, because Script-Fu is an important part of the GIMP and gimp-remote is required for some desktop environments. Even if gimp-remote should be replaced sooner or later (see http://bugzilla.gnome.org/show_bug.cgi?id=52866), it would be too hard to do it before the 1.2.4 release. It would also be too hard to rewrite the other plug-ins now (except maybe for the edge filter, which uses well-known algorithms). The two remaining options are to split the GIMP distribution in two packages or to change the license of the distribution: - If we split the distribution, we could have one tar archive with GPL files (or GPL-compatible files) and another one with the files mentioned above. This would also cover some patent problems for the GIF and TIFF plug-ins. However, it would not like to move Script-Fu out of the main GIMP distribution. - The other option is to change the license for the distribution and to add the required copyright notices in the GIMP help files. For the license of the package, we could state the the GIMP distribution is simply aggregating several independent packages that have their own license. We would also have to notify those who build binary packages about the license change. However, I am not sure that it is even possible to have a valid license for the aggregate, while still respecting the GPL and the old-style BSD-ish licenses. I have created a GIMP bug report for this issue. You can get it from Bugzilla: http://bugzilla.gnome.org/show_bug.cgi?id=83362 -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Fwd: Bug#148412: gimp1.2: Gimp is notconsistently licensed]
On Wed, 2002-05-29 at 07:26, Raphaël Quinet wrote: Hmmm... This is bad, because this is not compatible with the GPL. So we must either stop distributing these files or distribute them in a separate package that is not GPL'ed. Yep. And a lot of people are depending on the package being GPLd (most GNU/Linux distros, for example). I don't know if you want to get a copy of the messages and if I should also CC them to the debian bug tracker. Please at least CC [EMAIL PROTECTED] or [EMAIL PROTECTED] Also, you might want to set a CC on the bugzilla bug to [EMAIL PROTECTED] Shouldn't result in an ack war. Here is a sorted list of files that have copyright notices that are not compatible with the GPL (derivatives of the BSD license with the so-called advertising clause): If that's just from sorting my list, then beware that I just did some greps. I didn't actually read the licenses at the top of every file. I just grepped for 'supporting'. The two remaining options are to split the GIMP distribution in two packages or to change the license of the distribution: - If we split the distribution, we could have one tar archive with GPL files (or GPL-compatible files) and another one with the files mentioned above. This would also cover some patent problems for the GIF and TIFF plug-ins. However, it would not like to move Script-Fu out of the main GIMP distribution. This isn't really an option, at least for Debian. Debian couldn't distribute the split-out files because it'd violate the GPL on the rest of gimp(!). Same as how Debian doesn't distribute things that link GPL'd code to OpenSSL. GIMP would need an exception to the GPL saying this is OK. Probably not to practical to change the GIMP license. - The other option is to change the license for the distribution [...] However, I am not sure that it is even possible to have a valid license for the aggregate, while still respecting the GPL and the old-style BSD-ish licenses. I don't believe it is. See GPL clause 7: 7. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. [...] The 'any other reason' in this case would be the old BSD license. signature.asc Description: This is a digitally signed message part
Re: [Gimp-developer] [Fwd: Bug#148412: gimp1.2: Gimp is not consistently licensed]
Raphaël Quinet wrote: On Tue, 28 May 2002 14:52:53 -0700, Ben Gertzfield [EMAIL PROTECTED] wrote: Howdy GIMP folks. Here are some points in the licensing of GIMP that need to be addressed. Specifically, there's a lot of code that requires that the authors be mentioned in the documentation, but there is no mention of them anywhere. Hmmm... This is bad, because this is not compatible with the GPL. So we must either stop distributing these files or distribute them in a separate package that is not GPL'ed. Why is giving credit to an author incompatible with the GPL? I see no reason why an advertising clause need cause an issue... could someone explain it to me? Dave. -- David Neary, Marseille, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Fwd: Bug#148412: gimp1.2: Gimp is not consistentlylicensed]
On Wed, 29 May 2002, David Neary wrote: Raphaël Quinet wrote: On Tue, 28 May 2002 14:52:53 -0700, Ben Gertzfield [EMAIL PROTECTED] wrote: Howdy GIMP folks. Here are some points in the licensing of GIMP that need to be addressed. Specifically, there's a lot of code that requires that the authors be mentioned in the documentation, but there is no mention of them anywhere. Hmmm... This is bad, because this is not compatible with the GPL. So we must either stop distributing these files or distribute them in a separate package that is not GPL'ed. Why is giving credit to an author incompatible with the GPL? Because GPL gives the end users the free right to modify and redistribute so long as they obey the GPL license. They can't freely modify it if some of the comments or parts of the documentation can't be deleted or changed because they are required as adverts. Admittedly, it's hard to imagine why you'd urgently need to delete such a thing - but GPL doesn't go into reasons, it just grants users blanket rights to modify. For reasons not to start subtly modifying the GPL, read about all of the horrible things that are happening to Wine, WineX and ReWind! If they'd used an unmodified GPL from start to finish, none of that would have happened. Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation Training (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.link.com Home: [EMAIL PROTECTED] http://www.sjbaker.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Fwd: Bug#148412: gimp1.2: Gimp is not consistentlylicensed]
On Wed, 29 May 2002, David Neary wrote: Hmmm... This is bad, because this is not compatible with the GPL. So we must either stop distributing these files or distribute them in a separate package that is not GPL'ed. Why is giving credit to an author incompatible with the GPL? It's not the credit-giving (typically, authors usually credit themselves in the file header) but the requirement of prominent advertizing. I'm not a license guru, but I think the GPL explicitly forbids extra license requirements above those specified in the GPL itself. So if you want an advertizing clause, you have to use a modified version of the GPL or combine the code with a modified version of the GPL, thus non-GPL. In fact, when I now searched gnu.org, I found this: http://www.gnu.org/licenses/gpl-faq.html#TOCOrigBSD I see no reason why an advertising clause need cause an issue... could someone explain it to me? This is most likely not the proper list for general licensing discussions or questions. I'm sure there are better suited lists for that. Christian ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Fwd: Bug#148412: gimp1.2: Gimp is not consistently licensed]
On 29 May 2002 08:17:16 -0400, Anthony DeRobertis [EMAIL PROTECTED] wrote: Also, you might want to set a CC on the bugzilla bug to [EMAIL PROTECTED] Shouldn't result in an ack war. Unfortunately, this is not possible because [EMAIL PROTECTED] is not a valid Bugzilla account. It's a pity that Bugzilla accepts only valid Bugzilla accounts in the CC field, but I suppose that it makes sense in some cases. Here is a sorted list of files that have copyright notices that are not compatible with the GPL (derivatives of the BSD license with the so-called advertising clause): If that's just from sorting my list, then beware that I just did some greps. I didn't actually read the licenses at the top of every file. I just grepped for 'supporting'. I also did a couple of greps for several variations of copyright notice and documentation. I think that your list was correct. I only added a note about ./plug-ins/common/gifload.c to Bugzilla #83362. The two remaining options are to split the GIMP distribution in two packages or to change the license of the distribution: - If we split the distribution, we could have one tar archive with GPL files (or GPL-compatible files) and another one with the files mentioned above. This would also cover some patent problems for the GIF and TIFF plug-ins. However, it would not like to move Script-Fu out of the main GIMP distribution. This isn't really an option, at least for Debian. Debian couldn't distribute the split-out files because it'd violate the GPL on the rest of gimp(!). Same as how Debian doesn't distribute things that link GPL'd code to OpenSSL. GIMP would need an exception to the GPL saying this is OK. Probably not to practical to change the GIMP license. The files that are affected by this problem are independent plug-ins and one standalone tool (gimp-remote.c), so they are not linked with the other parts of the program. The libraries used by the plug-ins use the LGPL, not the GPL. The only plug-in that contains a significant amount of GPL code and GPL-incompatible code is the Script-Fu interpreter. But for most plug-ins, it should not be too difficult to contact the authors and ask for an exception. This exception would make it possible to distribute the plug-ins without license conflicts, even if they would still have to be distributed separately from the main GIMP package. - The other option is to change the license for the distribution [...] However, I am not sure that it is even possible to have a valid license for the aggregate, while still respecting the GPL and the old-style BSD-ish licenses. I don't believe it is. See GPL clause 7: [...] Well, I'm not sure. If the GIMP tarball is considered to be a mere aggregate of independent software packages (the main application and its plug-ins), it may be possible to have a license for the tarball that allows it to be distributed without violating the GPL or the old-style BSD licenses. Something like this may work (this is a quick draft and it is probably incorrect, but hopefully you will get the general idea): This archive of source files is an aggregate of several independent software packages, each one covered by its own license. The code in the plug-ins directory is not part of the main GIMP application. Most of the code is covered by the General Public License (GPL) or Lesser GPL but some plug-ins require a copyright notice to be added to the documentation. Please check the individual licenses if you use, modify or distribute any files from the plug-ins directory. In any case, we have to resolve the license conflicts for the files that include both GPL and GPL-incompatible code. But once this is done, I believe that we could still proceed with both options: split the distribution in two packages, or state that the package is an aggregate of individual programs. -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Fwd: Bug#148412: gimp1.2: Gimp is not consistently licensed]
On Wed, May 29, 2002 at 01:26:07PM +0200, Raphaël Quinet wrote: ./gimp-1.2.1.in (Spencer Kimball, Peter Mattis) ./gimptool-1.2.1.in (Owen Taylor, Manish Singh) This is gibberish. Someone bolted on some boiler plate which claims that the whole of the GIMP is covered by an obnoxious advertising clause. Most likely this happened because they copied an existing manual page source from another project. The presence of this boilerplate is a documentation bug, and can be fixed by removing the boilerplate or replacing it with a statement about the GNU GPL. Ben is even complaining about a manual page that he himself wrote, claiming that it is copyrighted software written by other people. Please don't substitute 'grep' for a working brain. ./plug-ins/common/gif.c (David Koblas) ./plug-ins/common/tiff.c(Patrick J. Naughton) We already knew about at least these and I was told (on #gimp I think) that it was not a problem. The other files are more annoying. The first thing to do would be to remove the GPL statement at the top of theses files because it is incompatible with the advertising clause. That's nice but you can't redistribute my code under this alternative license. So you must rewind to a Gimp 0.6x era tiff.c plugin if that's the preferred solution. I may eventually find time to rewrite tiff.c without any code re-use and thus without license problems. I have no idea where I will find time to do this. Maybe Debian have some volunteers who can come and finish my PhD for me? Nick. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 1.2 Bug selection (swatters ready!)
On Friday, 30 Nov 2001, Dave Neary wrote: 63411 http://bugzilla.gnome.org/show_bug.cgi?id=63411 NEW Eraser Tool behaves wrongly when toggling. Seems pretty accessible... 35489 http://bugzilla.gnome.org/show_bug.cgi?id=35489 NEW crop tool doesn't always change canvas size An odd one, this - another intermittent bug. Actually, it's every second time. And only on big images. Go figure. (I mean it, go figure :) These two might be related. See Raphael and my recent comments in Bug#35489. Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 1.2 Bug selection (swatters ready!)
On Fri, Nov 30, 2001 at 05:27:26PM +, Dave Neary wrote: 12582 http://bugzilla.gnome.org/show_bug.cgi?id=12582 NEW jpeg preview makes gimp's open layers dialog segfault This is a fairly long-running jpeg-based bug. Is this a libjpeg issue, or is there something we can do about it? libjpeg -- when we first discovered the bug, I was able to reproduce exactly the same bug with cjpeg. /* Steinar */ -- Homepage: http://www.sesse.net/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Bug week like thing for GIMP?
On 25 Nov 2001, at 17:53, Guillermo S. Romero / Familia Romero wrote: [EMAIL PROTECTED] (2001-11-25 at 1551.38 +0100): Are there any other such ideas that have been floating around? Intro (or task oriented) tutorials maybe, instead of the typical web page you create an publish, waiting feedback. IOW do a live class so people can ask questions, and then the final web page covers problems users had when trying the planed steps. I can see how that could be useful. You could have a Basic GIMP Stuff tutorial, for those who never looked further because they felt GIMP has a complicated UI, and then some advanced layerchannel juggling in another session. You could have a one hour session every 8 hours of one day, so that all users get a chance to join in. I remember from learning to use Adobe Illustrator that actually seeing somebody using the program (in this case on a video tape) helped a lot. There are all kinds of small things in complex programs like Illustrator or GIMP that get one small mention in the manual, but make life a lot easier. Of course, showing how to do stuff won't really be easy over the net. Have you got any experience with giving tutorials like this? -- branko collin [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Bug week like thing for GIMP?
On 25 Nov 2001, at 14:37, Carol Spears wrote: [EMAIL PROTECTED] (2001-11-25 at 1551.38 +0100): However, GIMP is not Mozilla and I was not trying to copy Bug Week from Mozilla, but rather was trying to see if more community involvement would be good for the GIMP (I think it may be) and how such community involvement could be given shape. What about a Wilberean Fest? Why do I smell beer all of a sudden? Are there any other such ideas that have been floating around? There is enough talent in the dusty halls of GIMP development for a brass band ... If was thinking more along the lines of something that will bring the members of the community _closer_ to us. ;-) -- branko collin [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [PATCH] [BUG] gtk_font_selector vs non scalable fonts
Austin Donnelly [EMAIL PROTECTED] writes: On , 22 Sep 2001, Thierry Vignaud wrote: we've patched gimp so that it looks only for scalable font (aka postscript and ttf) and everything just operates smoothly. Why do you need to patch the gimp to do this? If you click on the Filter pane of the text tool, you can de-select the Font Types Bitmap and Scaled Bitmap, leaving only Scalable selected. This should then show you only scalable fonts. of course, *but* the user will have a hard time understanding the error message and understanding that he needs to choose only scalable fonts. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 1.2 Bug Hunting
Dave Neary [EMAIL PROTECTED] writes: #51358 Acquire-screenshot not working with enlightenment http://bugzilla.gnome.org/show_bug.cgi?id=51358 I'm sure it's enlightenments fault ;-) Perhaps we can do something about it anyway... I've had this problem, and it appears to exist only with the version of xwd that's shipped with XFree86 4.0.x where x=2. I upgraded to 4.0.3 and the problem went away. Same problem (with same version of X) existed with WindowMaker too. Oh dear. Don't tell me that the GIMP uses xwd for getting screenshots. If so, please please *please* feel free to steal the code from gdk_pixbuf_get_from_drawable(). Federico ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 1.2 Bug Hunting
Hi, Federico Mena Quintero [EMAIL PROTECTED] writes: I've had this problem, and it appears to exist only with the version of xwd that's shipped with XFree86 4.0.x where x=2. I upgraded to 4.0.3 and the problem went away. Same problem (with same version of X) existed with WindowMaker too. Oh dear. Don't tell me that the GIMP uses xwd for getting screenshots. If so, please please *please* feel free to steal the code from gdk_pixbuf_get_from_drawable(). it does ;-) The screenshot plug-in is kind of old and has always been a quick hack. On the other hand it works pretty well for most users... Yes, we are considering another solution for the next version of Gimp. Since we will use GTK+-2.0, we will also use gdk-pixbuf and can thus use the functionality gdk-pixbuf provides. For Gimp-1.2 however things will not change. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 1.2 Bug Hunting
Larry Ewing [EMAIL PROTECTED] writes: hasn't timj complained loudly about how broken the code in gdk_pixbuf_get_from_drawable is? Of course the code he wrote for the desk guide likes to segfault, so who knows. Yeah, the function in the stable branch has a number of race conditions that will bite you if you are doing scary stuff on windows that you do not control :) I *think* it has been fixed in GTK+ 1.3, but I am not sure. Federico ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 1.2 Bug Hunting
Sven Neumann wrote: Hi, went out for some bug-hinting in the 1.2 wilderness tonight and came up with this list of beasts that are still alive and should be killed in 1.2 if possible: #51358 Acquire-screenshot not working with enlightenment http://bugzilla.gnome.org/show_bug.cgi?id=51358 I'm sure it's enlightenments fault ;-) Perhaps we can do something about it anyway... I've had this problem, and it appears to exist only with the version of xwd that's shipped with XFree86 4.0.x where x=2. I upgraded to 4.0.3 and the problem went away. Same problem (with same version of X) existed with WindowMaker too. #51164 Default image comment not set correctly http://bugzilla.gnome.org/show_bug.cgi?id=51164 I've added some comments on how one could be fixed to the report. Not sure what is the correct fix for this. Comments? The default Made with the GIMP comment is hard coded into plug-ins/common/xbm.c - and presumably into the others too. It seems to me that the easiest solution would be to include gtkrc in the relevant plug-ins, and do a read on the gimprc when loading the plug-ins. Cheers, Dave. -- David Neary, E-Mail [EMAIL PROTECTED] Palamon Technologies Ltd. Phone +353-1-634-5059 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 1.2 Bug Hunting
On Wednesday, 20 Jun 2001, Dave Neary wrote: The default Made with the GIMP comment is hard coded into plug-ins/common/xbm.c - and presumably into the others too. It seems to me that the easiest solution would be to include gtkrc in the relevant plug-ins, and do a read on the gimprc when loading the plug-ins. No. These plugins are sufficiently old that they pre-date parasites. The correct thing to do is ensure that images have the right gimp-comment parasite, and make all the plugins looks at it. In the same way as freshly created images are defaulted to 72 dpi, maybe they should also have a gimp-comment parasite added. File load plugins would then just override the parasite if the file format includes a more specific parasite. I believe current file load plugins than know about parasites wouldn't need modification. Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 1.2 Bug Hunting
On 20 Jun 2001, at 10:27, Dave Neary wrote: Sven Neumann wrote: #51164 Default image comment not set correctly http://bugzilla.gnome.org/show_bug.cgi?id=51164 I've added some comments on how one could be fixed to the report. Not sure what is the correct fix for this. Comments? The default Made with the GIMP comment is hard coded into plug-ins/common/xbm.c - and presumably into the others too. It seems to me that the easiest solution would be to include gtkrc in the relevant plug-ins, and do a read on the gimprc when loading the plug-ins. This is what I could find. I am not a programmer, however, and may be mistaken about which strings do get gettexted and which do not. Made with ... plug-ins/common/gtm.c Created with ... plug-ins/common/csource.c plug-ins/common/jpeg.c plug-ins/common/tiff.c xbm.c, however, does seem to use gettext: INIT_I18N_UI(); strncpy (xsvals.comment, _(Created with The GIMP), MAX_COMMENT); Also I noticed that when saving TIFFs, sometimes the 'hard coded' comment is used, sometimes the one I supplied in the preferences. The difference seems to be between images that I acquired from the Windows clipboard and images that I started with File/New. Is that at all possible? I will do some more testing. (HTH) -- branko collin [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 1.2 Bug Hunting
Sven Neumann wrote: Hi, went out for some bug-hinting in the 1.2 wilderness tonight and came up with this list of beasts that are still alive and should be killed in 1.2 if possible: Speaking of bug-hunting... I couldn't build gimp 1.2 (with gcc 2.96 - RedHat's 7.0 prerelease) for the first time recently because of the following line in app/histogram_tool.c: Line 230: gimp_option_menu_set_history (g_list_nth_data (gtk_container_children (GTK_CONTAINER (histogram_tool_dialog-channel_menu)), 1), GIMP_HISTOGRAM_VALUE); The prototype for gimp_option_menu_set_history is void gimp_option_menu_set_history (GtkOptionMenu *option_menu, gpointeruser_data); and GIMP_HISTOGRAM_VALUE is an enum value equal to 0. The problem is hidden with a cast to gpointer. My question is whether this is a compiler bug, or whether a constant 0 is valid as a gpointer value? Does this problem show up in the shiny new gcc 3.0? Is it a case of just upgrading the compiler? Cheers, Dave. -- David Neary, E-Mail [EMAIL PROTECTED] Palamon Technologies Ltd. Phone +353-1-634-5059 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 1.2 Bug Hunting
Hi, Branko Collin [EMAIL PROTECTED] writes: Also I noticed that when saving TIFFs, sometimes the 'hard coded' comment is used, sometimes the one I supplied in the preferences. The difference seems to be between images that I acquired from the Windows clipboard and images that I started with File/New. Is that at all possible? Yes, it's exactly the problem described in the bug-report. Gimp does only attach a gimp-comment parasite to an image if it is created using File-New. Other ways to create an image (Paste as New, Screenshot, Clipboard) do not attach the default comment. If you save an image that has no comment parasite attached, the save plug-ins use their hardcoded value. If we'd fix this by making gimp_image_new() attach a default comment parasite (just like it sets the default resolution), all images touched by The GIMP would get the default comment unless they already have a comment and the respective load plug-in takes care of setting it as a parasite. Another way to fix this is to change places like Paste as New, Screenshot, Clipboard etc. where images are created and let them take care of attaching the default comment. I don't consider this problem serious enough to insist on having it fixed in 1.2. If it turns out that there is no simple solution, we'll tackle this problem in the 1.3 tree. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 1.2 Bug Hunting
Sven Neumann wrote: Hi, I'll look into fixing this later or wait for a patch. Please report if you find more of these. Patch attached. If I find any more I'll let you know... I did think that an integer constant 0 could be used in a pointer context without a cast, though... Salut, Sven Cheers, Dave. PS. I forgot the patch the last time... -- David Neary, E-Mail [EMAIL PROTECTED] Palamon Technologies Ltd. Phone +353-1-634-5059 ? GINT_TO_POINTER.patch Index: app/histogram_tool.c === RCS file: /cvs/gnome/gimp/app/Attic/histogram_tool.c,v retrieving revision 1.40.2.1 diff -u -r1.40.2.1 histogram_tool.c --- app/histogram_tool.c2001/05/06 21:15:05 1.40.2.1 +++ app/histogram_tool.c2001/06/20 11:05:43 @@ -227,9 +227,15 @@ /* Channels can only have value histograms; reconfigure channel menu. */ /* Note: gimp_histogram_get_mean() in gimphistogram.c. garo 5/7/2001 */ histogram_tool_dialog-channel = GIMP_HISTOGRAM_VALUE; - gimp_option_menu_set_history (g_list_nth_data (gtk_container_children (GTK_CONTAINER (histogram_tool_dialog-channel_menu)), 1), GIMP_HISTOGRAM_VALUE); + gimp_option_menu_set_history (g_list_nth_data + (gtk_container_children +(GTK_CONTAINER + (histogram_tool_dialog-channel_menu)), +1), + GINT_TO_POINTER (GIMP_HISTOGRAM_VALUE)); gtk_widget_hide (histogram_tool_dialog-channel_menu); - histogram_tool_gradient_draw (histogram_tool_dialog-gradient, GIMP_HISTOGRAM_VALUE); + histogram_tool_gradient_draw (histogram_tool_dialog-gradient, + GIMP_HISTOGRAM_VALUE); } /* calculate the histogram */
Re: [Gimp-developer] 1.2 Bug Hunting
Dave Neary wrote: I did think that an integer constant 0 could be used in a pointer context without a cast, though... Hi all, I've confirmed that this code (for the case where the enum value passed is 0) should work in any ANSI conforming compiler (according to the impressarios of comp.lang.c anyway). Whether it's wise to do this is another matter, but in this case it's the compiler that's broken. Cheers, Dave. -- David Neary, E-Mail [EMAIL PROTECTED] Palamon Technologies Ltd. Phone +353-1-634-5059 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
