I gave feedback and was told to "...put up or shut up...". Which indicates a really dumb developer base that doesn't want to hear what people really want, they only want to provide what they decide people need.

Good luck with that...

Robert L Cochran wrote:

As another person said, if you are interested in having a specific feature implemented in Gimp why not offer feedback to the developers and request it? That will give you a better product and it is still free.

Bob

On 1/18/10, Ken Warner wrote:

I gave feedback and was told to "...put up or shut up...". Which indicates a really dumb developer base that ...

... you imagined yourself, because the person who said that isn't GIMP developer.

Alexandre

On Sun, 2010-01-17 at 13:07 -0800, Ken Warner wrote:

I gave feedback and was told to "...put up or shut up...". Which indicates a really dumb developer base that doesn't want to hear what people really want, they only want to provide what they decide people need.

Actually, you posted that to a user list, not the developer list. So there is nothing that says that response is associated with either the developers intent or behavior. They are, in fact, usually very open to feature requests though there are some they've heard many times already (like 16bit support, which is in development). For example, they've responded to requests for a single window mode from the Windows user community by adding it to development for 2.8. We Linux users don't need this so the developers are making this configurable. They do listen to users needs.

That said, requests for feature enhancement belong in the bugzilla database which you can find linked from the http://developer.gimp.org/bugs.html. "Bugs" is a generic developer term and is meant to encompass problems in the system as well as feature requests. To prevent duplication you should do a few searches to make sure your request hasn't already been made before posting.

When making feature requests it is important to be very clear what you need the feature to do. Your "batch processing" request, for example, isn't very clear. GIMP can already run in batch mode so you'd need to clarify what your interpretation of batch processing should be.

On 18.01.2010 00:23, Michael J. Hammel wrote:

That said, requests for feature enhancement belong in the bugzilla database which you can find linked from the http://developer.gimp.org/bugs.html.

No. Feature requests should always be discussed on the developer mailing list first: http://lists.xcf.berkeley.edu/lists/gimp-developer/

The audience reached via Bugzilla is much smaller than through the mailing list, and this medium is more suited for discussions.

Michael

Quote from Michael J. Hammel

Your "batch processing" request, for example, isn't very clear. GIMP can already run in batch >mode so you'd need to clarify what your interpretation of batch processing should be.

I bet i may clarify what he asked

It is called macro recorder and is the equivalent of what in PS is called "Actions" more exactly with the ability to record and replay actions(sequences of menu calls)

Batch script are not at all a equivalent because scripts has to be coded,the difference is as that between record a song or have to wrote down all the notes for all instruments with ink and paper

Let say before duplicate a layer,desaturate the layer, invert, apply gaussian blur and set the dup mode in overlay, you start to record

And Wow..you get a Contrast Mask action in less then a minute

Anybody that tried to create a Contrast mask script know well that much more time and effort is needed to get same result.

But most action are much more complex and convert them in a script will require much more time and effort, even knowing scheme or python

And here i must fully agree for me a macro recorder is what most professional really need, the only reason why is not much requested here, is that very seldom Professional user of Photoshop go here on in Bugzilla to make enhancement request for Gimp

Hmmm...wonder if someone couldn't write a plugin that would work as a macro recorder.  I also vaguely rememmber something like that in conjunction with GAP, perhaps.  I never used it, so can't remember much about it.

--- On Sun, 1/17/10, photocomix wrote:

From: photocomix Subject: [Gimp-user] Fwd: Re: GIMP vs Photoshop To: gimp-user@lists.XCF.Berkeley.EDU Date: Sunday, January 17, 2010, 10:05 PM

Quote from Michael J. Hammel

Your "batch processing" request, for example, isn't very clear.  GIMP can already run in batch >mode so you'd need to clarify what your interpretation of batch processing should be.

I bet i may clarify what he asked

It is called macro recorder and is the equivalent of what in PS is called "Actions" more exactly with the ability to record and replay actions(sequences of menu calls)

Batch script are not at all a equivalent because scripts has to be coded,the difference is as that between  record a song or have to wrote down all the notes for all instruments with ink and paper

Let say before  duplicate a layer,desaturate the layer, invert, apply gaussian blur and set the dup mode in overlay, you start to record

And Wow..you get a Contrast Mask action in less then a minute

Anybody that tried to create a Contrast mask script know well that much more time and effort is needed to get same  result.

But most action are much more complex and convert them in a script will require much more time and effort, even knowing scheme or python

And here i must fully agree for me a macro recorder is what most professional really need, the only reason why is not much requested here, is that very seldom Professional user of Photoshop go here on in Bugzilla to make enhancement request for Gimp

Michael J. Hammel wrote:

For example, they've
responded to requests for a single window mode from the Windows user community by adding it to development for 2.8. We Linux users don't need this so the developers are making this configurable.

This is a common misconception. The single-window mode is just as much for Linux users as it is for Windows users. It is in many ways my own itch I am scratching: I run Linux but hate to manage windows and/or workspaces, and single-window mode will fix this for me.

Regards, Martin

This is a common misconception. The single-window mode is just as much for Linux users as it is for Windows users. It is in many ways my own itch I am scratching: I run Linux but hate to manage windows and/or workspaces, and single-window mode will fix this for me.

Same with me, on Kubuntu and I cannot stand the multiple-window Gimp. One Mac user I know actually prefers Gimp but uses something else (forgot what, but it's not Photoshop) because of the Gimp's multiple-windows.

Dotan Cohen wrote:

This is a common misconception. The single-window mode is just as much for Linux users as it is for Windows users. It is in many ways my own itch I am scratching: I run Linux but hate to manage windows and/or workspaces, and single-window mode will fix this for me.

Same with me, on Kubuntu and I cannot stand the multiple-window Gimp. One Mac user I know actually prefers Gimp but uses something else (forgot what, but it's not Photoshop) because of the Gimp's multiple-windows.

I don't like multiple windows too. In my opinion Blender (ver. 2.49 and earlier) is the program with the best interface in this regard.

Greetings, Peter

On 1/19/2010 1:12 PM, Martin Nordholts wrote:

Michael J. Hammel wrote:

For example, they've
responded to requests for a single window mode from the Windows user community by adding it to development for 2.8. We Linux users don't need this so the developers are making this configurable.

This is a common misconception. The single-window mode is just as much for Linux users as it is for Windows users. It is in many ways my own

Really?

itch I am scratching: I run Linux but hate to manage windows and/or workspaces, and single-window mode will fix this for me.

I absolutely /hate/ the single window mode. I loved being able to float toolboxes and have the image editing area closable separate of the main program when I'm not using it (but will go back to using GIMP soon). It's one of the features (aside from being free) that first attracted me to The GIMP. Losing that flexibility is a pain in my rear.

I generally give GIMP it's own desktop. Solves that problem rather well.

On 1/20/10, Programmer In Training wrote:

itch I am scratching: I run Linux but hate to manage windows and/or workspaces, and single-window mode will fix this for me.

I absolutely /hate/ the single window mode.

You don't have to like single image node either. It'll be optional.

Alexandre

On 1/19/2010 6:43 PM, Alexandre Prokoudine wrote:

On 1/20/10, Programmer In Training wrote:

itch I am scratching: I run Linux but hate to manage windows and/or workspaces, and single-window mode will fix this for me.

I absolutely /hate/ the single window mode.

You don't have to like single image node either. It'll be optional.

So the next update will see the ability to revert back to the old behavior? That will be nice. (:

On Wed, Jan 20, 2010 at 11:22 AM, Programmer In Training wrote:

On 1/19/2010 6:43 PM, Alexandre Prokoudine wrote:

On 1/20/10, Programmer In Training wrote:

itch I am scratching: I run Linux but hate to manage windows and/or workspaces, and single-window mode will fix this for me.

I absolutely /hate/ the single window mode.

You don't have to like single image node either. It'll be optional.

So the next update will see the ability to revert back to the old behavior? That will be nice. (:

What version are you using?
GIT HEAD (dd8b867852efccc00eda94244ef1f27dc1a145b7 as of this writing) already has this option working, I just checked. I think commit db2221c97d0532b2a558ba44fb80f2b4e39c2c0a (25 or so commits earlier) was the first commit in which this switching was non-buggy, but don't quote me on that.

On 1/20/2010 7:04 AM, David Gowers wrote:

On Wed, Jan 20, 2010 at 11:22 AM, Programmer In Training

So the next update will see the ability to revert back to the old behavior? That will be nice. (:

What version are you using?
GIT HEAD (dd8b867852efccc00eda94244ef1f27dc1a145b7 as of this writing) already has this option working, I just checked. I think commit db2221c97d0532b2a558ba44fb80f2b4e39c2c0a (25 or so commits earlier) was the first commit in which this switching was non-buggy, but don't quote me on that.

2.6.8 and as far as I can tell, there is no way to revert to old behavior.

This is the behavior I'm currently having to deal with. http://www.joseph-a-nagy-jr.us/images/screen-caps/gimp.png (458KB, don't ask me how it's that large)

On Wed, Jan 20, 2010 at 5:42 PM, Programmer In Training wrote:

2.6.8 and as far as I can tell, there is no way to revert to old behavior.

This is the behavior I'm currently having to deal with. http://www.joseph-a-nagy-jr.us/images/screen-caps/gimp.png (458KB, don't ask me how it's that large)

Running GIMP on Windows and hating single-window mode is bloody unique :)

You are talking about different things, as a matter of fact. There is no way you can revert to GIMP 2.4 behaviour. There never will be.

Alexandre

Programmer In Training wrote:

On 1/20/2010 7:04 AM, David Gowers wrote:

On Wed, Jan 20, 2010 at 11:22 AM, Programmer In Training

So the next update will see the ability to revert back to the old behavior? That will be nice. (:

What version are you using?
GIT HEAD (dd8b867852efccc00eda94244ef1f27dc1a145b7 as of this writing) already has this option working, I just checked. I think commit db2221c97d0532b2a558ba44fb80f2b4e39c2c0a (25 or so commits earlier) was the first commit in which this switching was non-buggy, but don't quote me on that.

2.6.8 and as far as I can tell, there is no way to revert to old behavior.

This is the behavior I'm currently having to deal with. http://www.joseph-a-nagy-jr.us/images/screen-caps/gimp.png (458KB, don't ask me how it's that large)

Why do you need a 'Minimize' button for the toolbox? For 2.8, there will be an optional singe-window mode available (the link to the respective article was already posted in this thread).

Claus

------------------------------------------------------------------------

_______________________________________________ Gimp-user mailing list
Gimp-user@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user

On 1/20/2010 8:46 AM, Alexandre Prokoudine wrote:

Running GIMP on Windows and hating single-window mode is bloody unique :)

I've ran some flavor of Linux almost as long as I've run some version of Windows.

You are talking about different things, as a matter of fact. There is no way you can revert to GIMP 2.4 behaviour. There never will be.

That is rather unfortunate. I'll have to find a new image editor than. I do not want to be using a PS clone. That's not why I use The GIMP. I used it because of flexibility. It's becoming less and less flexible, in my opinion.

On 1/20/2010 9:23 AM, Claus Cyrny wrote:

Why do you need a 'Minimize' button for the toolbox? For 2.8, there will be an optional singe-window mode available (the link to the respective article was already posted in this thread).

Claus

The toolbox should not be linked to the image editing window (especially when it is always on TOP of the image editing window) for starters. Once I pick a tool, I don't need to see the tool box. I need to see the image I'm working on, whether it's 1600x1200 (as any of the full size images here:

http://adragonstale.joseph-a-nagy-jr.us/art/digital/

or 250x250. I should be able to float the tool dialogs when I just need that dialog and not require the entire toolbox. It's much easier to work around one small window then one large window (I am not going to constantly resize the entire toolbox, that's a waste of time). The way GIMP worked in 2.4 was PERFECT. I was hoping only for bug fixes and security updates past that. I guess if I'm going to continue using The GIMP I'm going to have to revert back to that version.

What about GEGL and babl you might ask? I really don't give a flip about either since their website has been down for Lord knows how long and I have no clue what they are supposed to do (I've tried experimenting with the GEGL options and was not pleased). At this point I don't care.

Well, I've experienced the same. When I close the tool window, GIMP exits. Really a pisser....

Alexandre Prokoudine wrote:

On Wed, Jan 20, 2010 at 5:42 PM, Programmer In Training wrote:

2.6.8 and as far as I can tell, there is no way to revert to old behavior.

This is the behavior I'm currently having to deal with. http://www.joseph-a-nagy-jr.us/images/screen-caps/gimp.png (458KB, don't ask me how it's that large)

Running GIMP on Windows and hating single-window mode is bloody unique :)

You are talking about different things, as a matter of fact. There is no way you can revert to GIMP 2.4 behaviour. There never will be.

Alexandre

Ken Warner wrote:

Well, I've experienced the same. When I close the tool window, GIMP exits. Really a pisser....

This is fixed in git master and will be further polished for GIMP 2.8

/ Martin

Yeah, I hate that too. What's the point of having a floating window if you can never bring it to the top of the stack?

Programmer In Training wrote:

The toolbox should not be linked to the image editing window (especially when it is always on TOP of the image editing window) for starters. Once I pick a tool, I don't need to see the tool box. I need to see the image I'm working on, whether it's 1600x1200 (as any of the full size images here:

Ken Warner wrote:

Yeah, I hate that too. What's the point of having a floating window if you can never bring it to the top of the stack?

Edit -> Preferences -> Window Management, change the toolbox and dock hints to 'Normal window'

/ Martin

Thanks... Much better. Why didn't I think of that? Maybe because I didn't think there was three different kinds of windows. Do we really need three different kinds of windows? I'm just asking....

Martin Nordholts wrote:

Ken Warner wrote:

Yeah, I hate that too. What's the point of having a floating window if you can never bring it to the top of the stack?

Edit -> Preferences -> Window Management, change the toolbox and dock hints to 'Normal window'

/ Martin

Ken Warner wrote:

Thanks... Much better. Why didn't I think of that? Maybe because I didn't think there was three different kinds of windows. Do we really need three different kinds of windows? I'm just asking....

Since we removed the menu from the toolbox for GIMP 2.6, we don't. In git master this is fixed, the setting is not separate for the toolbox and other docks, it's a single setting shared for both the dock window with the toolbox and the other dock windows.

But I think we need to keep the setting we have. Some people prefer it the way you do, they want their image windows to hide docks, while others don't want the docks to be hidden.

/ Martin

On 1/20/2010 12:08 PM, Martin Nordholts wrote:

But I think we need to keep the setting we have. Some people prefer it the way you do, they want their image windows to hide docks, while others don't want the docks to be hidden.

/ Martin

Then the old behavior from 2.4 should be made optional, or at least a reasonable facsimile.

Programmer In Training wrote:

Then the old behavior from 2.4 should be made optional, or at least a reasonable facsimile.

Most people thinks having two different menubars in one application is insane. The small amount of people that thinks it is a good idea will have to maintain code for that themselves, sorry.

Regards, Martin

On 01/20/2010 06:42 AM, Programmer In Training wrote:

2.6.8 and as far as I can tell, there is no way to revert to old behavior.

This is the behavior I'm currently having to deal with. http://www.joseph-a-nagy-jr.us/images/screen-caps/gimp.png (458KB, don't ask me how it's that large)

Somewhat off-topic - but I found that an interesting question. So I opened the file, clipped out the residue of the wallpaper, cleared the checkmarks for save background color and save color values from transparent pixels, and wound up with a file of 54.6 KB. Still has the same resolution, comments, and creation (whatever they were).

Martin Nordholts writes:

Ken Warner wrote:

Yeah, I hate that too. What's the point of having a floating window if you can never bring it to the top of the stack?

Edit -> Preferences -> Window Management, change the toolbox and dock hints to 'Normal window'

Except that you can't use that in GIMP 2.7 on a lot of window managers, due to GIMP's bug 556896. With "Normal window", if you ever change desktops, the toolbox and all docks disappear, and it's not easy to get them back.

So the "Normal window" setting really isn't usable any more, and the only choice is to put up with the Toolbox covering part of the image window.

...Akkana

Programmer In Training wrote:

On 1/20/2010 12:08 PM, Martin Nordholts wrote:

But I think we need to keep the setting we have. Some people prefer it the way you do, they want their image windows to hide docks, while others don't want the docks to be hidden.

/ Martin

Then the old behavior from 2.4 should be made optional, or at least a reasonable facsimile.

I have the impression that this is only an issue under Windows. Under Ubuntu, I'm really fine with the way it is now.

Claus

On Sunday 17 January 2010 15:54:20 Robert L Cochran wrote:

My suggestion is to use Gimp for what you need, and work with

a higher

end camera that produces raw format images. Get Akkana

Peck's book and

start with that. Post emails to this list when you need some

help. It

also doesn't hurt to have a website where you can post your

photos to.

I take technical photos (as a not very good amateur!) and edit

them in

the Gimp. I feel no need for Photoshop. The choice of either

software

title is really a personal preference.

I myself have not seen a photographer using film in quite some

time.

They all seem to be digital now. For example, the photographer

for my

daughter's wedding is a professional and he used a Nikon

digital.

* GIMP: May be used for 'serious' work if that means showing

a photo

on a web page. Otherwise forget it because:

** Is has no color management (I don't know what this is); ** Just 8 bit/channel;
** No CMYK.

Even though answers on this list may be biased, I have to ear

them.

So, are this statements true?

TIA!

Can't let this one go by. Those of us who work with print books have been asking for CMYK output from Gimp for many years. Scribus, a much newer product, already has it, along with ICC profiles and pdf x/1-a output and so on. Krita, a not very well- known drawing program that is part of KDE, has had CMYK color model for years.

The developers of Gimp have never given the needs of print media a high priority. As a result most people in the world of print media don't use Gimp. The usual response from the developers of Gimp is that there is little demand for CMYK. But the facts are that those of us who work in print media don't use Gimp very much precisely because it won't deal in CMYK. So it becomes a self-fulfilling prophecy.

When Gimp is used on images intended for print then another program such as Scribus or ImageMagick is used after the Gimp work is complete to do the conversion.

Inkscape, an Illustrator-like product also lacks the internal CMYK model. Its base output is svg, which is inherently RGB. But it is making moves toward CMYK output. Colors can be defined in (limited) CMYK terms. The problem with RGB to CMYK output is the difference between the gamuts of the two models. So it is possible in Inkscape to define a color that falls in the CMYK gamut.

Bitmap images such as photos are a different matter. Krita will use the CMYK model and also import specific "raw" formats for various cameras. So it has potential for being both a frontend and/or a backend to Gimp in a workflow without resorting to plugins etc. The feature set of Krita is nowhere near as complete as that of Gimp, so it is not a full replacement. And it is limited to machines that have the KDE software available. I use it on my Slackware 13.0 Linux box even though I use XFCE instead of KDE 4 for my user interface.

On Mon, Jun 21, 2010 at 7:02 PM, John Culleton wrote:

Can't let this one go by.

Surely you could. But you just didn't :)

The usual response from the developers of Gimp is that there is little demand for CMYK.

Is it usual? Really? I have never heard any GIMP developer stating that.

Alexandre Prokoudine http://libregraphicsworld.org

On Mon, Jun 21, 2010 at 11:02:42AM -0400, John Culleton wrote:

The developers of Gimp have never given the needs of print media a high priority. As a result most people in the world of print media don't use Gimp. The usual response from the developers of Gimp is that there is little demand for CMYK. But the facts are that those of us who work in print media don't use Gimp very much precisely because it won't deal in CMYK. So it becomes a self-fulfilling prophecy.

I think that this is not true.

GIMP has had an historical lack of developers but those that work on it (BTW: THANKS!) are working hard to do it "the right way" (TM) i.e. using a specialized library (GEGL: http://gegl.org/, http://en.wikipedia.org/wiki/GEGL) that will permit GIMP in the (near I hope...) future to work with different color models like CMYK natively. GEGL in already in GIMP but the work is not finished yet so to have that feature in GIMP it will be necessary to wait until completed the GEGL port of all functions on GIMP.

Sorry for my bad english.

On Mon, Jun 21, 2010 at 5:02 PM, John Culleton wrote:

I've cut your message since it's been said over and over (and over) again. Lots of people complaining. I've just two things to say to all of you who do:

1. Get real.
2. DTP with open-source software: It's been done. Successfully. Repeatedly. Period.

Good luck.

On Monday 21 June 2010 13:12:19 Branko Vukelic wrote:

On Mon, Jun 21, 2010 at 5:02 PM, John Culleton

wrote:

I've cut your message since it's been said over and over (and

over)

again. Lots of people complaining. I've just two things to say to

all

of you who do:

1. Get real. 2. DTP with open-source software: It's been done. Successfully. Repeatedly. Period.

Good luck.

Yes I do DTP with TeX and Scribus. But my question is about CMYK on Gimp. When?

On Mon, Jun 21, 2010 at 8:04 PM, John Culleton wrote:

Yes I do DTP with TeX and Scribus. But my question is about CMYK on Gimp. When?

Well, if you insist. I must ask you this: why? Forgive me if I err, but this sounds like one of those "You can't be a fancy designer if you can't do CMYK in your image editing app!" arguments. Do you have some valid reason why you cannot do a decent job with separate+ and need direct editing capabilities in CMYK mode?

On Mon, 2010-06-21 at 20:13 +0200, Branko Vukelic wrote:

Well, if you insist. I must ask you this: why? Forgive me if I err, but this sounds like one of those "You can't be a fancy designer if you can't do CMYK in your image editing app!" arguments. Do you have some valid reason why you cannot do a decent job with separate+ and need direct editing capabilities in CMYK mode?

The problem may be that when working in the Gimp it may be required to refer to something that was done using CMYK. The major issue that The Gimp has is that it's CMYK interpertation is not accurate. Whereas photoshop is very accurate. I have several times attempted to get the same results of pulling in images that were created in Photoshop using CMYK into The Gimp but not getting an accurate color representation.

Once you have the image imported correctly CMYK doesn't really matter at that point, unless you want to export it for print again. But the import procedure is where the problem would most likely stem. I'm just guessing as to the original posters issue, but I do know that this is the problem that I have seen.

On 6/21/10, Branko Vukelic wrote:

Do you have some valid reason why you cannot do a decent job with separate+ and need direct editing capabilities in CMYK mode?

In some cases you need direct access to curves. Besides, separate+ has neither GCR nor UCR.

Alexandre Prokoudine http://libregraphicsworld.org

On Mon, Jun 21, 2010 at 9:55 PM, Alexandre Prokoudine wrote:

On 6/21/10, Branko Vukelic wrote:

Do you have some valid reason why you cannot do a decent job with separate+ and need direct editing capabilities in CMYK mode?

In some cases you need direct access to curves. Besides, separate+ has neither GCR nor UCR.

Um, good point. I keep forgetting that I mostly do content creation, rather than old-school image processing. Are there any tools that provide those features?

On 6/22/10, Branko Vukelic wrote:

In some cases you need direct access to curves. Besides, separate+ has neither GCR nor UCR.

Um, good point. I keep forgetting that I mostly do content creation, rather than old-school image processing. Are there any tools that provide those features?

Krita provides access to CMYK curves, but that's about it. And the only free libre tool that knows of UCR is Scribus. No free tool I know of handles GCR except Argyll.

Alexandre Prokoudine http://libregraphicsworld.org

On Mon, Jun 21, 2010 at 10:21 PM, Alexandre Prokoudine wrote:

On 6/22/10, Branko Vukelic wrote:

In some cases you need direct access to curves. Besides, separate+ has neither GCR nor UCR.

Um, good point. I keep forgetting that I mostly do content creation, rather than old-school image processing. Are there any tools that provide those features?

Krita provides access to CMYK curves, but that's about it. And the only free libre tool that knows of UCR is Scribus. No free tool I know of handles GCR except Argyll.

And I assume Argyll will do all of above?

On 6/22/10, Branko Vukelic wrote:

Krita provides access to CMYK curves, but that's about it. And the only free libre tool that knows of UCR is Scribus. No free tool I know of handles GCR except Argyll.

And I assume Argyll will do all of above?

Argyl is a color management module with a bunch of console apps :)

Alexandre Prokoudine http://libregraphicsworld.org

On Tue, Jun 22, 2010 at 12:18 AM, Alexandre Prokoudine wrote:

On 6/22/10, Branko Vukelic wrote:

Krita provides access to CMYK curves, but that's about it. And the only free libre tool that knows of UCR is Scribus. No free tool I know of handles GCR except Argyll.

And I assume Argyll will do all of above?

Argyl is a color management module with a bunch of console apps :)

I know what it is. And I've read it had some tools to actually manipulate TIFFs or something. Just haven't really carefully looked at its functionality.