Re: [Gimp-developer] digested: printing presses, cmyk, tiff + pdf...
Robert Krawitz wrote: From: peter sikking pe...@mmiworks.net this whole pdf/cmyk discussion has been a nice exercise for me in getting to know the activity as Don Norman calls it. this is what I digest from all that has been said here: rule #1: the topic we are talking all the time about here is not cmyk, tiff or pdf. the topic we are talking about is mastering for the printing press everything evolves around that. I think the case of text black is a partial, qualified exception -- I have a hard time spotting what you mean. this is troubling because I will have to understand the everything to be able to drive the Ui side of the solution. Perhaps prepress tasks would better be implemented as a plugin (or set of plugins)? technically or user experience? it is essential to me that all this mastering for the printing press is in the document window of GIMP, with all the monochrome GIMP functionality available to optimise the plates. --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] digested: printing presses, cmyk, tiff + pdf...
On Thu, 26 Mar 2009, Robert Krawitz wrote: I think the case of text black is a partial, qualified exception -- but it's arguable that it has any bearing on RGB vs. CMYK. It really means the darkest, sharpest black that can be produced regardless of rendering device. It could just as well be represented as RGB+K, or simply as a separate layer. I'd argue that it's actually a creative choice, though. It doesn't necessarily mean the darkest, but it does mean the sharpest. And you're right that it could essentially be represented as RGB+K. Perhaps prepress tasks would better be implemented as a plugin (or set of plugins)? It's hard for me to see how trapping (for example) would make any sense at all as part of the core, but as a plugin it would make perfect sense. I know Adobe at least used to sell a product called TrapWise whose purpose in life was to do nothing but trapping. Automatic trapping is actually not a bad idea for a plugin. You could have things like trap along path or edge detection trapping (which I used as an example of something that would be prohibitively expensive in an interactive mode, but in one-time mode wouldn't be an issue). It would, in general, be a very dumb plugin, but some simple jobs don't need intelligent algorithms to determine that we don't need the red eye effect trapped but that the magenta hankerchief in the suit pocket does need to be, just to trap the edge of the photo that got torn and you're outlining with a black border. I don't know if it had a Photoshop plugin component or not. TrapWise began with Aldus and was subsequently acquired by Adobe. TrapWise is now owned by Kodak, who describe it thus[*]: ``TRAPWISE's streamlined workflow, intelligent trapping engine and flexible productivity tools combine to give you precision trapping whenever and wherever you need it.'' As I suggested in the other message, sophisticated automated trapping is probably going to be more difficult than simply implementing CMYK editing, since you're going to have to implement many of the same features--CMYK editing (batch, not interactive, granted), colorspace conversion, alterations to the XCF file format--plus a bunch of other features like advanced edge detection and an evaluation system to determine what needs to be trapped and what does not. There's a reason why TrapWise was pulling in $7000 a copy in 2001 when CS2 Premium was only $1200. [*] http://graphics1.kodak.com/us/product/workflow_data_storage/production_planning/trapwise/default.htm -- | Andrew A. Gill To ensure continued quality of service, | |this e-mail is being monitored by the NSA | | superlu...@frontiernet.net http://www.needsfoodbadly.com | -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] digested: printing presses, cmyk, tiff + pdf...
Andrew A. Gill wrote: I think I agree with 99% of what you wrote. Clarifications/quibbles: (wait. Nevermind. Probably about 75%) I better explain some things before that drops even further ^} 4) tiff or pdf? it is just a transport method. it is a strategic choice what to do first/better/at all. PDF isn't really appropriate for raster images, but printers know how to deal with them and some expect it. there seemed to be (simply better specified) benefits to pdf. but I am sort of neutral on this file type issue. 1) all creative work in GIMP is in rgb. Is currently? Or should be? I can agree that it is currently, but it should allow CMYK editing. currently and will be. hold it one moment with the cmyk editing. 2) when it is one of those times (plural) to work on the printing press mastering of this file, then pull the press projection over the image window. now you can see the plates (similar to layers) and work on each or combinations. This would make a very useful feature, but it must accompany full CMYK editing. you see, IF you set up your separation as standard (default) cmyk, the plates are c, m, y and k and you are editing within the press projection cymk. with the full awareness that this is totally geared towards that printing press, which is a user requirement. now the benefit of not hardwiring a cmyk mode in GIMP is that it will be just as easy to set up a spot(candy apple red) + black + spot(metallic silver) + spot(matt lacquer) separation, and work just as freely on it, with true preview. and that is progress. CMKYGO can easily be also a default. Probably not, for a few reasons. Hexachrome(R) is patent- encumbered, for starters. ouch. sorry to have mentioned it then. 4) flip the press projection up again and continue to work on the creative part. flip the press projection down again and the plates are updated from the image changes. with previous plate modifications applied on top. Ah. This is needlessly complicated and would require two versions of the same image. I think you can see from the above that you can work then however you choose. you will never have to touch the rgb side to get things exactly how you want to if you simply keep working with the press projection (in cmyk, no doubt in your case). Remember--rich black is a necessary CMYK color and cannot be represented in RGB. Trapping images requires CMYK and the trapped image cannot be represented in RGB. Changes to one image cannot be automatically transferred to the other without complicated transforms. This is far more than just RGB CMYK. This would involve things like edge detection and intelligent algorithms to determine when a boundary between two colors in one version of the image has shifted and thus requires a change to the other version. ah, forgot to mention that, sorry. 7) all the advanced press functionality (like trapping) will be build in, previewed and user-controlled in press projection. --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] digested: printing presses, cmyk, tiff + pdf...
On Fri, 27 Mar 2009, peter sikking wrote: I think the case of text black is a partial, qualified exception -- I have a hard time spotting what you mean. this is troubling because I will have to understand the everything to be able to drive the Ui side of the solution. Here, this may help: http://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=0001OR Specifically, the comparison of 4-color and single color here: http://www.edwardtufte.com/bboard/images/0001OS-1068.jpg To ensure that text is readable, it must be printed as a single color, otherwise the grit may render the text unreadable. -- | Andrew A. Gill To ensure continued quality of service, | |this e-mail is being monitored by the NSA | | superlu...@frontiernet.net http://www.needsfoodbadly.com | -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP PDF export plugin
Hi all, my previous posting does not stand a quality test, to put it mildly. To save the list from multiple nearly indentical follow-ups, i thinks it's best to bundle my replies here. My apologies for the noise. yahvuu schrieb: Thanks to GEGL's dynamic nature, the sRGB-CMYK separation will be live, so the resulting CMYK can be cross-checked immediately, like read-after-write with good old audio tapes. that's my personal wishful thinking. I have to take the blame for misguiding user interface speculations. Yet AFAIKS none of the examples has shown a requirement for doing actual image processing in CMYK space this is plain wrong. Already the levels curves example shuts me up. greetings, peter ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] digested: printing presses, cmyk, tiff + pdf...
Andrew A. Gill wrote: On Fri, 27 Mar 2009, peter sikking wrote: I think the case of text black is a partial, qualified exception -- I have a hard time spotting what you mean. this is troubling because I will have to understand the everything to be able to drive the Ui side of the solution. Here, this may help: http://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=0001OR Specifically, the comparison of 4-color and single color here: http://www.edwardtufte.com/bboard/images/0001OS-1068.jpg To ensure that text is readable, it must be printed as a single color, otherwise the grit may render the text unreadable. OK, that part I already got before I wrote my digest. But Robert points this out to show that there is a (minor) spanner in the works. where's the spanner? --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] digested: printing presses, cmyk, tiff + pdf...
On Fri, 27 Mar 2009, peter sikking wrote: OK, that part I already got before I wrote my digest. But Robert points this out to show that there is a (minor) spanner in the works. where's the spanner? There are two spanners: one in favor of CMYK and one against. I'm not sure which Robert means, since he alludes to both in his message. In favor of CMYK, text black must be implemented as a single color and can only appear on a single plate. Against CMYK, regardless of what system you use, text black is going to be a spot color, so it could just as easily be RGB+K, CMYK+K, LAB+K, or even YIQ+K. Does this answer your question or should I respond when I've had more sleep? -- | Andrew A. Gill To ensure continued quality of service, | |this e-mail is being monitored by the NSA | | superlu...@frontiernet.net http://www.needsfoodbadly.com | -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] digested: printing presses, cmyk, tiff + pdf...
Date: Fri, 27 Mar 2009 09:48:04 -0400 (EDT) From: Andrew A. Gill superlu...@frontiernet.net On Fri, 27 Mar 2009, peter sikking wrote: OK, that part I already got before I wrote my digest. But Robert points this out to show that there is a (minor) spanner in the works. where's the spanner? There are two spanners: one in favor of CMYK and one against. I'm not sure which Robert means, since he alludes to both in his message. In favor of CMYK, text black must be implemented as a single color and can only appear on a single plate. Against CMYK, regardless of what system you use, text black is going to be a spot color, so it could just as easily be RGB+K, CMYK+K, LAB+K, or even YIQ+K. Does this answer your question or should I respond when I've had more sleep? I meant the latter. I remember that on some older monitors and graphics devices there was a color whiter than white -- a special overlay color that was brighter than the standard white. Text black is the same kind of thing. It's conceptually distinct from other colors. I think it really argues for spot color layers more than CMYK per se. With a CMYK output device, it's implemented by printing only black ink (and it's an interesting problem, quite outside of GIMP, what to do if there are multiple levels of black or the black ink isn't truly black -- I've seen some printers where the black ink has a very warm tone and isn't all that dark, and mixing some cyan is necessary to achieve the densest black). But the choice of text black (or conversely whiter than white) for a particular graphical element is IMHO a *creative* choice. -- Robert Krawitz r...@alum.mit.edu Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail l...@uunet.uu.net Project lead for Gutenprint --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] GSOC 2009: GEGL-based file loaders for GIMP
I am also interesting in this project: GEGL-based file loaders for GIMP. I'm preparing the proposal, and it says in the introduction that The exact approach at this is still to be decided but will only require a small set of discussions and agreements between core developers. Where can I discuss this topic with core developers? -- Name: Yong Li E-mail: liyon...@gmail.com Address: Room 3-523, FIT Building, Tsinghua University, Beijing, China. 100084. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Dockable Dialogs Should be Dockable Everywhere
On Fri, Mar 27, 2009 at 5:13 AM, David Marrs wrote: As for customisability? I think that it's probably underestimated. Take the example of me spending half an hour or more on google this evening trying to work out how to enable menu tear-offs in Gnome. As far as I can tell, the feature just isn't there any more gconf-editor, /desktop/gnome/interface/menus_have_tearoff And it's on 1st page of google searhc result for gtkrc tear-off for me Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] digested: printing presses, cmyk, tiff + pdf...
Robert Krawitz wrote: where's the spanner? Against CMYK, regardless of what system you use, text black is going to be a spot color, so it could just as easily be RGB+K, CMYK+K, LAB+K, or even YIQ+K. I meant the latter. I remember that on some older monitors and graphics devices there was a color whiter than white -- a special overlay color that was brighter than the standard white. Text black is the same kind of thing. It's conceptually distinct from other colors. I think it really argues for spot color layers more than CMYK per se. the plan as you can see in my conclusions does not hardwire a cmyk system, it uses (stolen from pippin) an everything is spot aka a-plate-is-a-plate system where the separation is free configurable, and cmyk and cmy+k are standard configurations. so we are not snookered by this. --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] digested: printing presses, cmyk, tiff + pdf...
On Fri, 27 Mar 2009, peter sikking wrote: the plan as you can see in my conclusions does not hardwire a cmyk system, it uses (stolen from pippin) an everything is spot aka a-plate-is-a-plate system where the separation is free configurable, and cmyk and cmy+k are standard configurations. so we are not snookered by this. That's good. Some other solutions might not work that way, so clarifying this point they way we just did is probably a Good Thing. I was also thinking about CMYKOG, and I may have been a little glib in my dismissal of it. CMYKOG is essentially a special type of 6-color, which is not patent-encumbered, to the best of my knowledge. There's certainly no reason why the user can't have Hexachrome(R) if they install proper add-ons, but it couldn't ship with GIMP as long as it has a libre license. After all, there's a way to get PMS to work with Scribus (and I believe you can use this to get approximations in GIMP as well): http://wiki.scribus.net/index.php/Scribus_and_Pantone_colors -- | Andrew A. Gill To ensure continued quality of service, | |this e-mail is being monitored by the NSA | | superlu...@frontiernet.net http://www.needsfoodbadly.com | -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] digested: printing presses, cmyk, tiff + pdf...
On Fri, Mar 27, 2009 at 7:23 PM, Andrew A. Gill wrote: After all, there's a way to get PMS to work with Scribus (and I believe you can use this to get approximations in GIMP as well): http://wiki.scribus.net/index.php/Scribus_and_Pantone_colors You mean http://wiki.scribus.net/index.php/How_to_legally_obtain_spot_colour_palettes_for_use_in_Scribus ? Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Gsoc 2009
Dear Nicolas Robidoux I am Amit Kumar from India,an undergraduate engineering student(Electronics communication engineering) of IIT Guwahati. I went through Ideas list of GNU Image Manipulation Program for Gsoc 2009. I found More Flexible Abyss Policies (including Nearest Neighbour, a.k.a. clamp) and Consistent Image Size for GEGL Resamplers .I would like to work on this. I have enough experience in this field. Kindly reply to this mail so that next time we discuss this. Sincerely yours Amit ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Dockable Dialogs Should be Dockable Everywhere
Hi, On Wed, 2009-03-25 at 14:52 -0700, drizzt wrote: Just think of the most used piece of code on a GNU/Linux system: the Linux kernel. Didn't you know that the user interface is stable ? How would you feel if between releases the behavior of interfaces changed, and when asking the kernel developers you were told just keep using the old kernel you used to. Obviously you have no idea of what you are talking about here. The Linux kernel APIs are changing faster than anything else in the software world. If you had ever maintained a device driver outside the main kernel tree, you wouldn't have chosen the Linux kernel as an example of something that doesn't change its interface between releases. GIMP is very conservative compared to the Linux kernel. Our plug-in API has not seen an incompatible change for five years now. You also probably do not realize how much work an optional change is. Every option that is added doubles the complexity of the code. It is already impossible for us to test all possible configurations that GIMP offers. If we tried to make major interface changes optional, the code would become completely unmaintainable very soon. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Gegl-developer] babl portability patches, and a test failure
Hi, On Thu, 2009-03-26 at 17:03 -0400, Kevin Cozens wrote: Gary V. Vaughan wrote: Has anyone been able to find time to look at my patch queue for babl? One minor thing I noticed is the patch which adds and include of config.h so it is done in all(?) files. Is it really necessary to include the header even if it isn't currently needed by some of the files? Yes, definitely. The config.h header file has defines that affect how code is compiled. Including it in one place and not in another may result in bugs that are very hard to track down. It is common practice to include the config.h header always and always first. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP PDF export plugin
Hi, On Wed, 2009-03-25 at 23:21 -0400, Louis Desjardins wrote: At this point in the discussion, it would be great to hear if the quality of the information provided so far in terms of explanations and examples is enough to lead someone or a group of developers in the GIMP team to envision how this CMYK capability would be implemented into GIMP and into what kind of developing frame (time, resource, GSoC, etc.)? Without CMYK support in GEGL/babl, there will be no direct editing of CMYK in GIMP. So whoever wants to see CMYK editing in GIMP should help to - change GIMP to do all editing using GEGL - make sure that babl/GEGL gains first-class CMYK support Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Dockable Dialogs Should be Dockable Everywhere
Alexandre wrote: On Fri, Mar 27, 2009 at 5:13 AM, David Marrs wrote: As for customisability? I think that it's probably underestimated. Take the example of me spending half an hour or more on google this evening trying to work out how to enable menu tear-offs in Gnome. As far as I can tell, the feature just isn't there any more gconf-editor, /desktop/gnome/interface/menus_have_tearoff And it's on 1st page of google searhc result for gtkrc tear-off for me Did you test that? Because it doesn't work for me. ---AV Spam Filtering by M+Guardian - Risk Free Email (TM)--- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Please restore removed crop tool functionality
Hi, I'm leaving the Gimp list now as I'm not actively intrested in the internals of Gimp's development. I just hope that my suggestion from December of restoring the non-destructive crop functionality (which sparked quite some discussion) will not be forgotton - this is a simple feature that I have been missing for several Gimp releases now. Once I got used to working with the non-destructive crop, it is really painful trying to get by without it. (Below is my original mail for context, the discussion can be found in the archives.) Thanks overall for the amazing development of Gimp! I'm now off to continue on an open source project of my own... Best regards, Sampo On Sun, 21 Dec 2008, Sampo Niskanen wrote: Hi, In previous versions of Gimp, the crop tool had the option to resize the canvas, but not to crop the layers. This functionality has been removed in recent versions (or at least I can't find it). This totally disrupted my regular workflow with all photos. Though the highlighting feature in the crop tool gives a better view on the result, it never was exactly to my liking the first time. Therefore I always only shrank the canvas, and then used the move tool and canvas resizing to fine-tune the positioning, and finally flattened the image. With newer versions I have to use the crop tool to get an idea of the size, write down the dimensions, cancel the crop operation, manually change the canvas size and re-position the image - and then start the fine-tuning. This is extremely frustrating. AFAIK none of the modifier keys are currently used by the crop tool, so could this feature be reinstated to the tool? I recall that a shift-click was used to shrink the canvas instead of performing regular cropping. If this feature is available otherwise, please tell me. Sincerely, -- __ /\ Sampo Niskanen = sampo.niska...@iki.fi \ \ http://www.iki.fi/sampo.niskanen/ \ \ \___ \___/___/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Dockable Dialogs Should be Dockable Everywhere
On Fri, Mar 27, 2009 at 08:02:13PM +0100, Sven Neumann wrote: Hi, On Wed, 2009-03-25 at 14:52 -0700, drizzt wrote: Just think of the most used piece of code on a GNU/Linux system: the Linux kernel. Didn't you know that the user interface is stable ? How would you feel if between releases the behavior of interfaces changed, and when asking the kernel developers you were told just keep using the old kernel you used to. Obviously you have no idea of what you are talking about here. The Linux kernel APIs are changing faster than anything else in the software world. If you had ever maintained a device driver outside the main kernel tree, you wouldn't have chosen the Linux kernel as an example of something that doesn't change its interface between releases. GIMP is very conservative compared to the Linux kernel. Our plug-in API has not seen an incompatible change for five years now. Still that narrow minded? You obviously didn't read the drizzt's post at all! Drizzt was comparing the linux kernel _user_ interface with the gimp's _user_ interface. As a matter of fact, I personnaly know drizzt and an I can assure you he really knows what he is talking about regarding kernel developping as he does exactly that for a living. You also probably do not realize how much work an optional change is. Every option that is added doubles the complexity of the code. It is already impossible for us to test all possible configurations that GIMP offers. If we tried to make major interface changes optional, the code would become completely unmaintainable very soon. Well, of course, everything could be better if more people would be even allowed to work on gimp. But I guess this won't happen since even confirmed former contributors aren't even allowed to commit trivial patches without having to explain many times what these patches do, and pass many many controls. You did everything to discourage people to contribute, so now, please, don't tell people you need ressources to maintain the whole mess. Cheers, DindinX -- da...@dindinx.net ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Dockable Dialogs Should be Dockable Everywhere
Hi, On Fri, 2009-03-27 at 20:29 +0100, David Odin wrote: Still that narrow minded? You obviously didn't read the drizzt's post at all! Drizzt was comparing the linux kernel _user_ interface with the gimp's _user_ interface. As far as I know the kernel doesn't have a user interface in the sense the term is used for a graphical user application such as GIMP. It does provide a lot of interfaces to device drivers and to the higher levels of the operating system though. And these interfaces are changing quite frequently. Perhaps this was a misunderstanding. I don't really understand the purpose of the Linux kernel example. Well, of course, everything could be better if more people would be even allowed to work on gimp. But I guess this won't happen since even confirmed former contributors aren't even allowed to commit trivial patches without having to explain many times what these patches do, and pass many many controls. No idea what you are referring to here. Can you explain to me what you are talking about? Of course there is a patch review process. It would be insane not to have one. But we are trying hard to review patches very fast. Did you really have to wait an unreasonable time to have your patches reviewed? Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Dockable Dialogs Should be Dockable Everywhere
David Odin wrote: Drizzt was comparing the linux kernel _user_ interface with the gimp's _user_ interface. Comparing a kernel user interface with an image editor user interface is just plain silly. [...] Well, of course, everything could be better if more people would be even allowed to work on gimp. But I guess this won't happen since even confirmed former contributors aren't even allowed to commit trivial patches without having to explain many times what these patches do, and pass many many controls. You did everything to discourage people to contribute, so now, please, don't tell people you need ressources to maintain the whole mess. I can't let you attack Sven like this without commenting on it. If you are talking about the patch I think you are talking about it was not a trivial patch. And there is nothing wrong with requiring changes to be of high quality. Getting commit access in open source projects is all about trust and the way you are acting is not very strategic if you want to regain trust to commit non-trivial stuff. But then that is of course not what you want. You announced a few months back that you officially quit the GIMP project. All you want to do is taking some kind of revenge by talking shit about Sven. It is pathetic. - Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Dockable Dialogs Should be Dockable Everywhere
On Fri, Mar 27, 2009 at 08:51:10PM +0100, Sven Neumann wrote: Hi, On Fri, 2009-03-27 at 20:29 +0100, David Odin wrote: Still that narrow minded? You obviously didn't read the drizzt's post at all! Drizzt was comparing the linux kernel _user_ interface with the gimp's _user_ interface. As far as I know the kernel doesn't have a user interface in the sense the term is used for a graphical user application such as GIMP. It does provide a lot of interfaces to device drivers and to the higher levels of the operating system though. And these interfaces are changing quite frequently. I won't say that the syscalls or the /proc interfaces are changing that frequently. And when they change, the older behaviour is still available as an option. A device driver isn't really a user of the kernel, but a part of it. Whatever. Perhaps this was a misunderstanding. I don't really understand the purpose of the Linux kernel example. Well, of course, everything could be better if more people would be even allowed to work on gimp. But I guess this won't happen since even confirmed former contributors aren't even allowed to commit trivial patches without having to explain many times what these patches do, and pass many many controls. No idea what you are referring to here. Can you explain to me what you are talking about? Of course there is a patch review process. It would be insane not to have one. But we are trying hard to review patches very fast. Did you really have to wait an unreasonable time to have your patches reviewed? No. I won't explain all that once more since having to explain the same thing over and over instead of doing the real work is precisely why I have quit the gimp development. And it is also why the gimp development is so slow. I now prefer to give my time to some more attractive projects. I'm still a gimp user, though and I'm very desapointed to see which directions it takes. At least, I'm still able to maintain my own private tree when I want a special feature that won't get in because it would just take years to explain to every one why it is useful to me. -- da...@dindinx.net ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Please restore removed crop tool functionality
Samp, I didn't look at the archive -- but the functionality you are seeking appears to be in the rectangle selection tool. Select a rectangle, move your cursor within the selected rectangle. If it's close to an edge, you can move the edge. If it's not, you can move the rectangle. Actually, if this is what you want, I'm surprised you didn't already find it. If it's not, then I guess I don't know what you want. Sampo Niskanen wrote: Hi, I'm leaving the Gimp list now as I'm not actively intrested in the internals of Gimp's development. I just hope that my suggestion from December of restoring the non-destructive crop functionality (which sparked quite some discussion) will not be forgotton - this is a simple feature that I have been missing for several Gimp releases now. Once I got used to working with the non-destructive crop, it is really painful trying to get by without it. (Below is my original mail for context, the discussion can be found in the archives.) Thanks overall for the amazing development of Gimp! I'm now off to continue on an open source project of my own... Best regards, Sampo On Sun, 21 Dec 2008, Sampo Niskanen wrote: Hi, In previous versions of Gimp, the crop tool had the option to resize the canvas, but not to crop the layers. This functionality has been removed in recent versions (or at least I can't find it). This totally disrupted my regular workflow with all photos. Though the highlighting feature in the crop tool gives a better view on the result, it never was exactly to my liking the first time. Therefore I always only shrank the canvas, and then used the move tool and canvas resizing to fine-tune the positioning, and finally flattened the image. With newer versions I have to use the crop tool to get an idea of the size, write down the dimensions, cancel the crop operation, manually change the canvas size and re-position the image - and then start the fine-tuning. This is extremely frustrating. AFAIK none of the modifier keys are currently used by the crop tool, so could this feature be reinstated to the tool? I recall that a shift-click was used to shrink the canvas instead of performing regular cropping. If this feature is available otherwise, please tell me. Sincerely, ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Please restore removed crop tool functionality
Hi, On Fri, 27 Mar 2009, bgw wrote: Samp, I didn't look at the archive -- but the functionality you are seeking appears to be in the rectangle selection tool. Select a rectangle, move your cursor within the selected rectangle. If it's close to an edge, you can move the edge. If it's not, you can move the rectangle. The point is changing the canvas size, but leaving the layers uncropped. The current crop tool always crops the layers to the selected area, so you cannot fine-tune the position afterwards - previously there was the option of cropping only the canvas, and the layers still stretched beyond the canvas. This is what I always do so that I can fine-tune the position later on, and since there is no interactive way of doing it in Gimp anymore, it becomes a painful trial-and-error cycle (as I described in my original post). Martin Nordholts provided very quickly a one-liner patch for the issue, but there came a lot of discussion about how the option should be visible from the UI. I hope that this will come to some conclusion, instead of forgetting that feature altogether. Thanks. -- __ /\ Sampo Niskanen = sampo.niska...@iki.fi \ \ http://www.iki.fi/sampo.niskanen/ \ \ \___ \___/___/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Dockable Dialogs Should be Dockable Everywhere
Once again, I reply to many posts, and with a long message, but it seems that people are interested in the discussion, so I wont deceive them. Martin Nordholts a écrit : Comparing a kernel user interface with an image editor user interface is just plain silly. I don't think so, but maybe some people have difficulties seeing the parallel, so read ahead please. Sven Neumann a écrit : Hi, On Fri, 2009-03-27 at 20:29 +0100, David Odin wrote: Still that narrow minded? You obviously didn't read the drizzt's post at all! Drizzt was comparing the linux kernel _user_ interface with the gimp's _user_ interface. As far as I know the kernel doesn't have a user interface in the sense the term is used for a graphical user application such as GIMP. So for you a user interface is a GUI ? It does provide a lot of interfaces to device drivers and to the higher levels of the operating system though. And these interfaces are changing quite frequently. I feel like there's a need for some technical information in here. Have you ever heard of kernel space and user space ? The linux kernel code, and all module code, is running in kernel space, while all the remaining parts are in user space. On a linux system, you can take any 2.6 kernel, and still have your system up and running. Even using a 2.4 kernel will be possible, with only a few changes to some administrative tools (modutils and the like). Why ? Because the USER interface is stable. So much that when there is a need for a change, kernel programmers don't do it, they find another way, whatever it costs. The kernel internals are moving, and a lot, but this the user don't care about. you can rewrite gimp every day if you want, nobody (or no user at least) will care, if the user interface is stable. Perhaps this was a misunderstanding. I don't really understand the purpose of the Linux kernel example. It is an example I used on IRC when someone told me to use the old GIMP version if I did not like the new one. And chosed because everybody is using new kernels because of the improvements and the new drivers, which are added but still using the same user interface. If you cannot see the parallel, sorry. Then from your previous email: Obviously you have no idea of what you are talking about here. From what you say, I would say I have much more idea than you have. The Linux kernel APIs are changing faster than anything else in the software world. If you had ever maintained a device driver outside the main kernel tree, you wouldn't have chosen the Linux kernel as an example of something that doesn't change its interface between releases. I would say only one thing: Why bother !!! Commit your driver to the kernel, and you'll have no more to do out of the tree !!! Keeping drivers out of the tree is nonsense. GIMP is very conservative compared to the Linux kernel. Our plug-in API has not seen an incompatible change for five years now. So the few developpers have nothing to do, but users have to learn the tool once again after every release ? Am I the only one feeling that there's a problem in this point of view ? You also probably do not realize how much work an optional change is. Every option that is added doubles the complexity of the code. It is already impossible for us to test all possible configurations that GIMP offers. If we tried to make major interface changes optional, the code would become completely unmaintainable very soon. No. Not at all. As I said, being a free software, The GIMP project may have some of the best programmers at hand. Once again, there are more options in the kernel than you can think about, and the code is maintained, maintainable, and often tested. If it's done correctly and early, everything can be tested using test tools. Once again you are saying implicitly that GIMP developers are newbies. Please don't. And making major changes is not required if you spent more time thinking. For example, for the menu, making it dockable with it's docking position being a saved configuration setting, would prevent an option. And it's already done for dialogs, so it's not more work, it should even be less work. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Please restore removed crop tool functionality
Sampo Niskanen (spnis...@cc.hut.fi) wrote: The point is changing the canvas size, but leaving the layers uncropped. The current crop tool always crops the layers to the selected area, so you cannot fine-tune the position afterwards - previously there was the option of cropping only the canvas, and the layers still stretched beyond the canvas. The current development branch has the menu entry Image - Fit Canvas to Selection, which - together with the rectangle select tool - does provide exactly this functionality. I hope this helps, Simon -- si...@budig.de http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
