Re: [Gimp-developer] Question about bundled iBryte GIMP installer
On Thu, 14 Jul 2011 20:54:42 +0200, =?utf-8?Q?Jernej_Simon=C4=8Di=C4=8D?= wrote: On Thursday, July 14, 2011, 19:34:08, Andrew Brandt wrote: -- Are third parties permitted, according to your EULA, to bundle your product this way? GIMP is licensed under the GNU General Public License, version 2. The GPL only covers redistribution (not usage, which isn't limited in any way), which is allowed provided that certain criteria are met - specifically, anybody receiving the software has to get the same rights of redistribution, and at the same time also has to be able to get the source code from the same place where the binary was obtained (the source code has to match the binary exactly; it also has to be provided from the same place as the binary, unless the one providing the binary has an agreement with a 3rd party that's providing the source code). There's more to it than that; the GPL has to be passed through, allowing downstream recipients to modify, distribute, etc. it under the terms of the GPL. So if someone were to extract the GIMP package from the bundle and distribute that, I believe (IANAL) that that would be completely kosher. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] IMPORTANT: GIMP AND OPENSOURCE SCAM ON EBAY!
On Thu, 23 Sep 2010 09:56:45 +0200, g...@catking.net wrote: On 09/23/10 06:53, Konstantin Svist wrote: On 09/22/2010 09:05 PM, Abir Sadik wrote: This is some really serious violation going on, and i hope someone will do something about it. Some people who really dont know much about opensource are actually buying from that seller, check his feedback. Wrong. Selling most open source software is perfectly legal, according to the licenses @ Konstantin WRONG: selling the software is not allowed as you would see from the licence snip that you posted. A fee to cover the cost of distribution is permitted. Not the same thing. If this seller was showing a reasonable price for distribution of his CD that would seem ligit but it is hard to see how you can AUCTION a distribution fee. It has always been perfectly OK to sell a copy of GPL software (as long as the license is otherwise met). Otherwise, how could Linux distributors sell boxed sets for profit? And remember that the GNU project was selling tapes of Emacs for $150 in the 1980's. The GPL says nothing about the price for selling a physical copy: You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee. as opposed to providing the source, where it is restricted to the actual cost: b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Native RAW support
On Wed, 22 Sep 2010 22:35:49 +0200, Sven Neumann wrote: On Tue, 2010-09-21 at 07:53 +0200, Martin Nordholts wrote: I think the point here is that configure, make, make install on a GIMP tarball - with all dependencies met - should result in a GIMP installation with good support for working with RAW images. Oh come on. The ufraw plug-in is much better maintained outside the GIMP source tree. No one would benefit if we tried to include all third-party plug-ins in the GIMP source tree. That's just silly. Our product vision states that GIMP should be easily extendable. Instead of adding more plug-ins to the source tree, as you suggest, we should work on making it easier for users to install additional plug-ins. As the maintainer of one of those outside the tree plugins (the enhance Print plugin with Gutenprint), I have to agree with this. Keep in mind that one of the big reasons for Photoshop's success is the variety of externally available plugins available for it that offer functionality well beyond that of the core application. This is particularly important for things like non-standard file formats (such as RAW, which is camera-specific and new formats come along with each new camera release). It's simply not practical for GIMP to do a new release with every new RAW sub-format, while the ufraw team is well equipped to do so. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Lab conversion, GEGL, RGB space, Illuminant
Date: Thu, 12 Aug 2010 18:58:45 +0200 From: yahvuu yah...@gmail.com OK, here i'm silently presuming that GIMP is fed with absolute color data (meaning that the device color profile is known in case device dependend colors are given). In my regard, that is 'normal operation'. What is absolute color data? -- 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 -- http://ProgFree.org 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
Re: [Gimp-developer] Gimp printing future direction
Date: Mon, 17 Aug 2009 22:47:57 -0500 From: Erik Lotspeich e...@lotspeich.org The native printing does not appear to work properly either on Windows or Linux. Are there plans to improve this? Can Gutenprint be made to be a dependency? Are there efforts to add CUPS support directly to Gutenprint? As Sven said, it was decided to decouple GIMP and Gutenprint quite a while ago. I (as Gutenprint project lead) agree with that decision. It also gives us opportunities to do things that would be more difficult if we were tied to the GIMP release schedule. (I think that the GIMP native plugin needs to support full PPD functionality -- last I looked, it only handles a small set of options from the PPD file -- but that's a problem with GNOME Print, not GIMP per se.) In my opinion, taking the CUPS functionality of the current native Gimp printing and integrating that into Gutenprint would be the best option. This would work with any CUPS-configured printer since Gutenprint can be configured to print PostScript and CUPS provides the PPD. Once this is done, Gutenprint can be made a dependency of Gimp (as it was before with gimp-print). To what end? While Gutenprint can generate PostScript, that path loses functionality over the native drivers and is less efficient since there are more stages of conversion going on. Using native Gutenprint drivers, the plugin reconfigures its options appropriately depending upon other options that are set (e. g. when you set black and white mode, it removes all of the color controls). CUPS also doesn't have any notion of curve data types. I think that what you're really asking for is for the Gutenprint-based plugin to query CUPS for the attached printers. That would be a worthwhile RFE, if you're interested in helping out. I have used Gimp nearly since its inception and I'm quite a fan. As a software engineer, my motivation is to try to help to improve Gimp to make it better. Although I am quite busy, I may be able to make some time to donate to an improvement of printing under Gimp. Our mailing list is gimp-print-de...@lists.sourceforge.net. You can subscribe by going to http://gutenprint.org and clicking on Mailing Lists. -- 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
Re: [Gimp-developer] Gimp printing future direction
Date: Tue, 18 Aug 2009 11:26:55 -0500 From: Erik Lotspeich e...@lotspeich.org Thank you for the perspective. It seems that the printing part of Gimp is a second-class citizen that doesn't have the refinement of the rest of Gimp. I have always seen Gimp as a Photoshop competitor, so I'm thinking what if my mother-in-law (or any other non-expert computer user) were using Gimp. Would she be able to print? Would she use it instead of buying Photoshop? I would like that answer to be yes. Tor Lillqvist wrote: I have tried all possible permutations of paper size between Gimp and the Windows driver. Since this setup works great for all other applications (e.g. Word, IE, Firefox, etc.), I don't see how the problem could lie anywhere else than Gimp. (The problem is in GTK+ more likely, but that GTK+ is technically separate is mostly irrelevant to end-users.) Yes, it is well known that GTK+ printing (and thus GIMP printing) on Windows doesn't really work that well. My advice is always to use some other application to print images then instead, if GIMP isn't up to it. Opening an image file in another app and printing from there shouldn't take more than five seconds extra. In fact, I would even recommend that, if the situation really is as bad as it seems to be, the print plug-in is made optional (and not selected by default) in the GIMP installer for Windows... Sure, it would be nice if somebody fixed the problems. Volunteers welcome. What might be really nice is if PhotoPrint could be used as a print plugin for GIMP -- it supports everything in Gutenprint except curves, and the UI is much nicer in many ways than the Gutenprint plugin (which I've had to maintain over the years, and I'm not exactly much good at user interfaces). -- 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
Re: [Gimp-developer] Please help with a syntax error.
From: Brent Hawkins for...@gimpusers.com Date: Thu, 4 Jun 2009 01:46:20 +0200 (CEST) When i try to run this script in the console, it says Error: Bad syntax of binding spec in let* : (var-one 1) I already wrote a much bigger script using information from an old tutorial but without trying out this simple part of it first and now that doesn't work, except when you replace the variables with values. Using gimp 2.6.6 and Ubuntu 9.04 (let* (var-one 1) (var-two 2) (var-three 3) ) The syntax of let* is (let* bindings body body) The bindings are a single argument, so they have to be a list: (let* ((var-one 1) (var-two 2)) ...body...) -- 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
Re: [Gimp-developer] HSL Color Picker
From: Christian i...@zwahlendesign.ch Date: Sun, 31 May 2009 17:53:43 +0200 Hi Michael The HSL is one of the best color models. The colors are symmetrical ordered. Advantages 1. symmetrical 2. color values are not rounded (you have more colors than in the HEX model) 3. logical (no senselessly black axis) 4. equidistant colors in the color picker 5. the right color theory. In the middle is the neutral gray [1] Bad's in the HSV color picker 1. not symmetrical 2. color values are rounded (in HEX a base color can have only a value of 0 - 255) 3. not logical (a senselessly black axis) 4. not equidistant colors in the color picker, you can click too many colors in the black area. 5. the color circle is correct but in the middle is not the neutral gray. I favor HSL also, and it's what we use in Gutenprint to perform correction (actually, we perform parts of it in HL+G, but that amounts to the same thing). I also added HSL decomposition to GIMP several years ago, and find it very useful -- a simple manipulation of the L curve can have a dramatic and predictable effect on the image. L conforms much more closely to perception than V, which is a major advantage when lightening or darkening an image -- in HSV space, there's no simple way to do that. I'd ideally like to see an HSL-based correction pack in GIMP using the Gutenprint algorithm, where it's possible to correct all three channels as a single operation. The correction adjustments (+/- delta for H, multiplicative factors with soft clipping for S and L) are done with curves, where the X axis is the starting hue and the Y axis is the correction. This would allow selective hue shifting along with saturation and lightness adjustments in one shot, with only one loss of precision. -- 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
Re: [Gimp-developer] HSL Color Picker
Date: Sun, 31 May 2009 20:56:25 + From: Omari Stephens x...@csail.mit.edu Omari Stephens wrote: Mockup is here: http://ocaml.xvm.mit.edu/~xsdg/stuff/gimp/hsl-doublecone.png Note that when I mention HSL below, I mean HSL with its traditional coordinate system, as depicted in [1]. Also note that this is a quick transformation away from the RGB color cube, [2], so many nice properties of RGB are shared by this representation. The lightness axis is just one of the major diagonals of the cube. The lightness axis is indeed the major diagonal between black and white, but the rest of the transformation isn't particularly easy. The circle at the join of the cones represents the other 6 vertices of the cube and the 6 edges connecting them, but that doesn't seem like a simple transformation. - Similarly to the previous point, this representation matches our perception well. Consider any two points in this representation, in HSV, in HSL, and in RGB. This representation and RGB are the only ones where the length of that path MUST correspond to the ease with which we can differentiate between the two colors at the endpoints of the path. That is, the magnitude of a segment corresponds naturally to important aspects of our visual system. Agreed. Of course, there are always drawbacks: - This requires more computation to use because of the odd shape of the space of valid coordinates. That is, not all valid coordinates are valid colors. What I don't like about this is that it leaves a large fraction (well over half) of the color space unused and functionally meaningless. I agree that this representation is more accurate, but functionally it seems more difficult to work with. Think about the UI implications. - HSL and HSV are in wide use, and this is neither HSL nor HSV (though it's just a coordinate transformation away from both HSL and RGB) It's a simple coordinate transformation from HSL: H' = H S' = S * (1 - ((|L - .5|) * 2)) L' = L but it's not any simpler than RGB-HSL. Operationally, I suspect a problem with this is that transformations in this space that increase saturation will tend to amplify chroma noise (which is more prominent in dark areas) more than transformations in HSL space. In principle, this isn't true, but in practice I suspect it will be. I think this space has a lot in common with the HLK space Gutenprint uses for its HL transformations (for additive colors HLW would be used). HLK is computed as follows: K = min(C, M, Y) C' = C - K M' = M - K Y' = Y - K (H, L) = HSL(C', M', Y') Note that S is always 1 in this case, so it's ignored. I'm not sure what S transforms in this space would be. H transforms are the same as in HSL space, but L transforms that are based on hue yield better results (you don't want L transforms where L' = fn(H, L) to operate on the gray component). Also note that for K close to 0 or 1 there's a limit on the value of L similar to your S'. -- 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
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
Re: [Gimp-developer] GIMP PDF export plugin
Date: Thu, 26 Mar 2009 23:08:37 + From: =?ISO-8859-1?B?2Hl2aW5kIEtvbOVz?= islew...@gmail.com For CMYK the following ops need to be implemented: CMYK-from-RGB - takes a GeglBuffer as input, has options for black subtraction, ICC profile selection, gamut handling and similar, provides four gray scale GeglBuffers as output. CMYK-to-RGB - takes a four separate gray scale GeglBuffers as input and provides an RGB soft proof. CMYK-to-CMYK - which converts to a CMYK GeglBuffer (OK, GEGL and babl actually support very naive CMYK buffers, these buffers are fragile and should probably only be used as a prestep to passing the buffer to a TIFF or similar saving op. Similar duotone-from-RGB and a configurable duotone-to-RGB or special five channel ops for use with CMYK with additional spot colors, or perhaps even a generic configurable ink-mixer op could be implemented. If a person with interest in these things want to he could also add support for 1bit GeglBuffers and generate the final raster to be printed at the printers native DPI. FYI, most inkjet printers these days are actually 2 bits per physical channel. A lot of this already exists in Gutenprint; you may want to look at that. -- 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
Re: [Gimp-developer] digested: printing presses, cmyk, tiff + pdf...
From: peter sikking pe...@mmiworks.net Date: Fri, 27 Mar 2009 01:20:48 +0100 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 -- 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. So I'd say that it's really not at odds with what you're saying. 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. I don't know if it had a Photoshop plugin component or not. -- 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
Re: [Gimp-developer] CMYK editing (Was: GIMP PDF export plugin)
From: Sven Neumann s...@gimp.org Date: Mon, 23 Mar 2009 23:18:23 +0100 On Mon, 2009-03-23 at 17:51 -0400, Andrew A. Gill wrote: I do work in the printing industry, and I can tell you that output is still CMYK, and will remain CMYK for at least the next few years. Output, yes, of course. But where in this process do you actually edit an image in CMYK? I don't mean converting it to CMYK to get it printed. I mean actual editing after the conversion. Could you give us some examples of where that is needed? The most obvious example to me (and this has been discussed wrt Gutenprint and other printer drivers) is to allow printing text black -- text (or similar) that should be printed with black ink, which is usually more crisp than composite. This is essentially a special case of a spot color. An alternative would be RGB+K. My sense is that this should not be a very high priority for GIMP -- we never got around to implementing it and nobody has complained. But it is one possible use case for CMYK (although I think RGB+K would be a better input space for it, anyway -- and if you're going to do that, you might just as well generalize the spot color support). When people do send CMYK data to Gutenprint, the large majority of the time it's either because they don't really understand what CMYK is (it's very device and media specific) or because we have a problem with the GCR parameters (or some other parameter problem) for a particular printer and CUPS's default RGB-CMYK conversion happens to work better. Personally, I would *much* rather see development effort go into high bit depth support (which will do a lot of people a lot of good right away) than CMYK editing support. But, that's just my take. -- 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
Re: [Gimp-developer] CMYK editing (Was: GIMP PDF export plugin)
From: Guillermo Espertino gespert...@gmail.com Date: Mon, 23 Mar 2009 19:59:53 -0300 CMYK exists because, though is possible theoretically, it isn't possible to generate black from mixing CMY inks. As the C, M and Y inks aren't perfect and have some contaminants, mixing them ends up in a dirty brown instead of pure black. Or dirty green/cyan, or dirty magenta, depending upon the colorants... That's why CMYK exists, and that's why it isn't so simple to print an RGB image. The problem resides mostly in the generation of black and gray shades. Although there are systems that do a great job converting a photo to CMYK on the print side, it's still a problem to do a simple task as placing a pure black overprint on a solid color background without destroying some underlaying information on the separation. I'm a designer, not a photographer, and an image manipulation program is an essential part of my workflow. And placing some black text, or editing a large image with a black or gray background, adding black drop shadows, aren't rare at all. And it's a pain without the ability of editing the separated CMYK. It's not about if the printer will handle the file or not, is about creative control. Sometimes you NEED to control the black overprint. Sometimes you need to use spot colors and you need to control the channels and how they overprint. Even with Adobe software, before having spot channels in Photoshop, it was a common practice to separate to CMYK to make 2, 3 or for 2 inks prints (replacing the corresponding plate's ink for a custom ink). Simply because other programs didn't support the Adobe's custom multitone files but did support CMYK tiffs. This really sounds like you're using black as a spot color rather than going generic editing in CMYK space. I question whether doing this in an image editing application is really the right thing to do. If you're doing black text, you probably want the text to be vector rather than raster anyway -- printing an image scaled to 240 DPI is fine, but the text won't look so good at that resolution. In that case, you're better off using something like Scribus to do that kind of overlay, at least until GIMP has vector layers. Well, I can't do duotones with Gimp to insert in a 2 inks flyer. Which again is a spot color kind of use case rather than a CMYK use case. CMYK editing would help. I can't control the black generation of a separation, because the separate+ plugin doesn't support that. It just support existing profiles and there is no control. I can't control CMYK curves. And trust me, that's extremely common. Does that indicate that separate+ is what needs to be enhanced, rather than the core application? -- 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
Re: [Gimp-developer] Request to include Gimp Manual Book at Gimp.org
From: Monica Kraenzle [EMAIL PROTECTED] Date: Wed, 22 Oct 2008 11:51:02 -0300 But now to go to the book page and give a bad rating to say this is bad quality and the gimp developers say this is not an official manual is not the finest way. Do you consider this as fair? Not only to us but also to all the authors who worked on that version? We had to bad intention at all. From my experience (as the project lead for Gutenprint), it *is* a real problem when well-intentioned distributors use beta (or old) versions of our software, or make changes without discussing them with us. We've had a few cases of this happen, and the result is that users yell at us for something we didn't do. I've fired off a few angry emails of my own to distributors over things like that. Yes, the license allows you to do what you want, but that doesn't mean that it's a good idea to grab a snapshot and publish it as a book, or to distribute it with changes without clearly pointing out the local customizations. In this particular case, it would have saved a lot of hard feelings (not to mention a good bit of work on your part) to have asked about this before publishing it. If nothing else, you would at least have known what version to publish. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] 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
Re: [Gimp-developer] gimp print dlg
Date: Wed, 10 Sep 2008 22:22:45 +0200 From: [EMAIL PROTECTED] On Wed, 10 Sep 2008 19:16:36 +0200, Akkana Peck [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] writes: thanks for the explaination. I've checked and gimp-print is built with gimp option. Should that alter the dlg I get from gimp file print menu? Are you building in gimp-print then doing a make install? Is this the latest gimp-print from http://sourceforge.net/projects/gimp-print/ ? Check that make install is really succeeding. If you already have gimp's built-in gtkprint plug-in, and you also build gimp-print from the Gutenprint project, you'll probably end up with two different File-Print... menu entries. One of them should bring up the Gutenprint dialog, the other, the GTKprint one. As long as you're building gutenprint yourself, I'd recommend modifying their src/gimp/print.c: find the line that registers to N_(Image/File/Print...), (line 166 in the latest version) and change the name, e.g. N_(Image/File/GutenPrint...), Then you'll be able to tell the the two plug-ins apart and verify that your gutenprint plug-in is really getting installed. ...Akkana Thanks, a very good idea. I'm building 5.2.0-beta4 and the closest I can find is src/gimp2/print.c , sadly I don't find anything that matches the snippet you posted. What function is it in? You don't need to do any of this any more; as of 5.0, the menu item is Print with Gutenprint (if GIMP 2.4 or above is in use) to distinguish it from the GTKPrint plugin bundled with GIMP. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] 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
Re: [Gimp-developer] Gimp User Interface.
Date: Mon, 16 Jun 2008 07:52:15 -0400 From: Chris Moller [EMAIL PROTECTED] KishoreKumar Bairi wrote: Hello folks, I recently migrated from Photoshop to Gimp. Though GIMP is offering powerful functionalities, its way of opening each window of each image is bugging me a lot. My entire taskbar is filled up with GIMP windows.I'm really looking forward to see all gimp images in single Gimp window. No, no, no, and no! I've been using GIMP for a good number of years now and like the current paradigm. As far as I'm concerned, huge, monolithic, windows full of clutter I don't need at the moment not only waste screen space but make it just that much more difficult to get to the operations I /do/ need at the moment. For the original poster, if the issue is the task bar filling up, you might check if your window manager offers an option to group related windows together. KDE does, but I don't know if GNOME does. Personally, I find this kind of application-focused (as opposed to document-focused) paradigm completely unusable. For starters, I don't simply work with GIMP and nothing else; I have a lot of different things I'm doing that I switch between by just moving the mouse around (typically three emacs windows, several xterms, and a browser). If GIMP is doing a long-running filter I'll go and do something else, or maybe I'll just momentarily switch off for whatever reason of my own. A single application window hides everything else. Yes, I do use multiple desktops, and no, I don't want to confine each application to its own desktop. Usually I stick things on desktops based on what I'm doing, not based on application (so typically my primary desktop will be email and browser, #2 is where I stick Gutenprint development, and so forth). The other problem is that each application then becomes a mini-window manager, with different settings than my screen window manager. I use focus strictly follows mouse, with no autoraise, and I normally use keybindings (alt-f1 to raise, alt-f2 to lower, alt-f3 to minimize). Most applications that do this seem to follow a click-to-raise-and-focus paradigm which is the exact opposite of how I like to work. In addition, it's impossible for this kind of MDI interface to use the same keybindings to manipulate windows, because the screen window manager keeps them for its own use. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] 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
Re: [Gimp-developer] Specs for Export/Save User Interface
Date: Sat, 14 Jun 2008 18:32:04 +0200 From: Ingo Ruhnke [EMAIL PROTECTED] A useful addition to Gimp would be an auto-save. Not only could it be used to periodically save the image to prevent data loss in case of crashes, it could also be used to store .xcf files for exported files automatically, when opening such an exported file Gimp could then offer an option to recover the original .xcf data from the auto-save. One issue that needs to be considered with that is what is done with very large images. For example, I have a 96 megapixel image that with multiple layers and all that winds up at over 900 megabytes. Even with a very fast computer and RAID array, the autosave delay will be significant; on the computer I created this on (Athlon 64 3000+ with 2 GB and a drive that would get 40 MB/sec on a good day) the delay would be unacceptable (as I recall, it took at least a minute to save this, sometimes several minutes). There's also the storage implication of this. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] 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
Re: [Gimp-developer] An idea for resource management
Date: Sun, 18 May 2008 18:55:07 -0400 From: Brian Vanderburg II [EMAIL PROTECTED] I don't know if this has been talked about yet but could be nice for a future version of GIMP. Currently, in order to use a custom brush/gradient/etc, you must first create it, then edit/save/etc. Every time you want a new brush you have to create a new one, even if it is a temporary brush. Instead why not have the 'active' brush (and gradient,etc) always be user editable, saved between sessions. How would you restore the original version of the brush, in case you edited it accidentally? -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] 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
Re: [Gimp-developer] Feature idea for GSoC - Separate+ Plugin integration.
From: Joao S. O. Bueno [EMAIL PROTECTED] Date: Tue, 25 Mar 2008 00:42:04 -0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Hi Guillermo, On Mon 24 Mar 2008 14:01:00 Sven Neumann wrote: Hi, On Mon, 2008-03-24 at 13:34 -0300, Guillermo Espertino wrote: First of all, sorry if this is the wrong place or moment to post this. II think that integrating the separate+ plugin to Gimp would be a great GSoC project. Doesn't sound like it would be worth making this a GSoC project. In particular because that would mean that it would definitely not make it into GIMP 2.6. As far as I can see all that is needed for integration of the seperate+ plug-in is someone who volunteers to review the code and the user interface and to propose it for inclusion on this list. As we wanted to have this plug-in in 2.4 already, I wonder why this has still not happened yet. So, adding on to this - while only reviewing the code and the UI might be much less than expected for a whoe GSoC project, I perceive this as a valuable idea. Maybe adding to this review the implementation of some, or even more, of the features suggested could do for a Google Summer of Code. Guillermo, I would encourage you towards formalizing this application - try to summarize objectively what exists today and what do you plan to implement. Also, try some guestimates on a time frame for completing each task. The idea, bellow, of integrating it to the GIMP TIFF save plug-in is great and would make it really feel like part of GIMP. So, take a look at GIMP's TIff plug-in and giver your say on it. And of course, the separate plug-in should take into account ICC color profile magement, as implemented in the GIMP core (I reall don't know if it aready does that). And least - have in mind that the chances of approval depend very much on a favorable review of your proposal by the GIMP developers. You got some critics on your first e-mail, and some ideas as well. So use those in your favor and come up with a propose everyone here should like. Personally, I think that doing this at the application level is the wrong way to go about it. It would be much more valuable to work on this at the system level (OpenICC, I believe, is also in GSoC), or at least as part of a RIP. A lot of what was described about separate+ is already present in the Gutenprint plugin for GIMP (and I think also in Cinepaint), and also in PhotoPrint, which is a standalone application layered on the Gutenprint core. I'd rather beef this up, and provide the necessary machinery in CUPS to take advantage of it, than have a specialized plugin for one application. These capabilities are just as critical in all applications. For that matter, if saving the separations to a TIFF file (or multiple TIFF files) is really important, it's a capability that could be added to Gutenprint and again made available to all applications. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] 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
Re: [Gimp-developer] toward a plan for 2.8
Date: Sat, 26 Jan 2008 22:22:17 GMT From: William Skaggs [EMAIL PROTECTED] One of the points that emerged from the ongoing discussion is that it is time to start making a tentative roadmap for 2.8. I hope this time that Peter and his group can be brought into the discussion as early as possible, and will play a role in shaping the plan. As I wrote earlier, Peter in his LGM talk listed the things he considered the top priorities at the UI level: 10. better printing support What are the specific printing issues under discussion? -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] 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
Re: [Gimp-developer] task list
Date: Fri, 25 Jan 2008 23:50:56 +1030 From: David Gowers [EMAIL PROTECTED] On Jan 25, 2008 9:52 PM, Alexandre Prokoudine All the users who ever bugged you asking for macros recording did it because they don't feel like programmers to learn Script/Python/Perl-Fu. With non-destructive editing, used as above, almost all the things that users want to do are things that can be expressed in terms of a modification of the image graph. The example you see above -- the only user input required would be to choose which layer becomes sourcelayer. twould probably be pretty easy to build a 'quick change' dialog where the user can change all the involved values (eg gauss blur radius.) The question is, do users what to have to learn about image graphs, or do they just want to say save what I did so I can do the same thing to another set of images? -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] 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
Re: [Gimp-developer] Developer-User Disconnect
it (in the case of GIMP, under exactly the same terms as the original) with or without modification, and so forth. But with that freedom comes the responsibility to help the project along if you can, or at least to understand that if you're not going to actively help your ideas along that nobody else has the responsibility to do it for you. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] 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
Re: [Gimp-developer] using the GIMP donations
From: Sven Neumann [EMAIL PROTECTED] Date: Fri, 23 Nov 2007 08:37:31 +0100 On Thu, 2007-11-22 at 18:12 +0100, Martin Nordholts wrote: But I still can't see why it would be a bad thing to allow donors to donate money to specific features and what legal problems that would then arise. What would be the advantage if we allowed it? I can only see disadvantages if we allow people to use their money to influence our decisions on the future of GIMP. And I also expect that it will have a negative effect on the overall motivation of developers to work on the code for free. Another thing to keep in mind: nothing prevents individuals from establishing bounties (or hiring consultants) and other individuals from implementing the desired features and either creating their own forks or convincing the GIMP team to accept the feature after it's implemented. But I absolutely agree with Sven: for the project to accept bounties like this is likely to be very disruptive. The administrative overhead would fall on me to the extent possible, and as long as patches are GPL and taxes etc are handled, what legal problems would there be? Maybe these problems are bigger than I currently see I am sure there are many that you and me can't even imagine. But I don't see the point in discussing the legal and admininstrative problems unless we first come to the conclusion that we consider bounties and feature-bound donations a good idea. And so far the consensus on this list and on GIMP developer meetings has been that it isn't. One very obvious problem is if the feature doesn't get implemented but the money somehow gets used for some other purpose, which could happen very easily if a project doesn't have really good processes for handling this kind of thing -- which would take up resources better used for advancing the project in general. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] 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
Re: [Gimp-developer] Angled guides
Date: Sat, 10 Nov 2007 09:05:36 -0800 From: Tom Lechner [EMAIL PROTECTED] On 11/10/2007 08:01:39 AM, Sven Neumann wrote: On Fri, 2007-11-09 at 21:04 -0800, Tom Lechner wrote: 1. Angled Linear Guides Double click on a line defines a center of rotation. Double-clicking doesn't work for this. Apart from the fact that we don't use double-click at all in the GIMP user interface, it is also extremely difficult to define a position precisely this way. If we really need angled guides, then there's needs to be a way move the center of rotation precisely. I don't understand the double click prohibition. Seeing as how the mouse barely moves during a double click, how is that less precise than a single click? Anyway, if you are one pixel off, you can still move the thing. If double click is out of the question, then have control- click define the center point. Think about the mechanical action required for a double click: you have to hold the mouse very carefully while clicking it twice in rapid succession. It would be very easy to move it by several pixels while you're doing it. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Negative Press
Date: Sat, 3 Nov 2007 14:47:18 -0400 From: Barry Loo [EMAIL PROTECTED] GIMP just got some negative press at linux.com. What are y'alls opinions on it? http://www.linux.com/feature/120635 I've had my share of issues with the GIMP UI (and I've been vocal about it at times), but I think this piece is completely off the mark. It's really no different from a group of people going off into a small room to focus on something rather than being constantly interrupted by everyone passing by. That was a particularly unfortunate out of context quote of Peter Sikking's. The only one of the three that I've met is Ellen Reitmayr (at the April 2006 printing summit in Atlanta), and my impression was most certainly not that she isn't interested in listening to other people. She and a couple of other of the UI folks spent a couple of hours brainstorming on Gutenprint UI issues. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] 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
Re: [Gimp-developer] 2.6 roadmapping, the UI part of it...
From: Sven Neumann [EMAIL PROTECTED] Date: Wed, 31 Oct 2007 08:54:11 +0100 On Tue, 2007-10-30 at 21:59 -0400, Robert Krawitz wrote: Let's take layers as an example (because this is one of the more annoying ones to me). Having only one layers dialog has two undesirable consequences: For the rare cases where you need more than one Layers dialog, you can open a second (or even a third one). At least currently GIMP doesn't keep you from doing that. Using 2.4.0, I tried opening three images, and typing ctrl-L in each to open a layers dialog. It only opened the one dialog (and again, as soon as I move the mouse into one of the images, the image in the layers dialog changes). Nor was I able to do it from either the file menu on the toolbox or the dialogs menu on the images. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.6 roadmapping, the UI part of it...
From: Thorten Wilms [EMAIL PROTECTED] Date: Wed, 31 Oct 2007 13:10:31 +0100 On Wed, 2007-10-31 at 07:20 -0400, Robert Krawitz wrote: Using 2.4.0, I tried opening three images, and typing ctrl-L in each to open a layers dialog. It only opened the one dialog (and again, as soon as I move the mouse into one of the images, the image in the layers dialog changes). Ctr-l or menu does not open another layers dialog, true. Do you see the Auto button next to the image list menu-box ...? I never knew about that, actually. Unfortunately, the resulting Layers dialog doesn't say which image it's attached to. Nor was I able to do it from either the file menu on the toolbox or the dialogs menu on the images. It can be done from the tab menu - Add Tab - Layers. It works, although it's a bit obscure (you have to know two relatively obscure things to get there). Anyway, I see two approaches for dealing with the image / layers (or similar dialog) relation: - Always attach everything relating to just one image to its image window - Use inspectors like now The former has the potential to be less confusing and would make showing several layer stacks straightforward. Size requirements for an image and its layer stack might be quite different, though. Like I said, when I can afford it, QXGA time... ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.6 roadmapping, the UI part of it...
Date: Tue, 30 Oct 2007 21:44:56 + From: David Marrs [EMAIL PROTECTED] All Mac software ported to Windows uses the parent window model because - I suspect - it's the simplest solution to the where goes the omni-present menu bar? problem. You put it at the top of an omni-present window that has to be maximised and you've got a makeshift Mac desktop. It's not elegant and it usually doesn't work very well (see Photoshop pre CS2 for details). Most (if not all) Unix WMs already share MS Windows's behaviour of every window containing its own menu bar, so why try and solve a problem that's already fixed? Windows users hate the Gimp's current layout because it forces them to work using scaled windows. Windows users like to maximise *everything*, in case you hadn't noticed. I wouldn't be surprised if a large fraction of Windows/Gimp users maximise their canvases and then use alt-tab to access their tool dialogues. It also doesn't help that the default layout is very hungry of space. The first thing I do after installing Gimp is to reduce the size of the toolbox to something that leaves some room on my screen. I think your own mock-up is a far superior solution to an MDI layout, especially if slave windows could be rolled up or otherwise made invisible. It allows one to work full screen, removes the confusing CDI structure and also reduces the problem of task bar clutter. I also think that extending the tool dialogue's tabbing feature to the canvas windows would be very natural and help the clutter problem as well. You could have several canvas windows each containing many images in tabs. You could even go as far as allowing tabs to be moved between the tool dialogues and canvas windows so that an overview could be nested directly beneath the layers tab, for example. As long as we're talking about all this, I'd rather see things go the other way -- each image has its own toolbox, set of dialogs (perhaps in a sidebar, or as slide-outs or slide-ins), etc. Let's take layers as an example (because this is one of the more annoying ones to me). Having only one layers dialog has two undesirable consequences: 1) I can only see the layer stack of one image at a time. 2) If I move the mouse from one image to another (even if the mouse is in transit), GIMP switches which image's layers are displayed. One way of looking at this is that this is a problem with focus follows mouse (actually focus strictly follows mouse in my case, but I don't think that that matters here). The other way of looking at it is that this is a problem with dialogs that are related to a document being shared between multiple documents, so there's only one active document at a time. My preferred way of working is to have lots of open windows at a time. Sometimes a window that I'm working in at the moment (emphasis on at the moment -- I don't really have a notion of this is what I'm working on now, I jump around between things) may be partially obscured by another window, but that's how I like it. I do use multiple virtual desktops, but not in a very organized way. I rely on screen real estate (currently 1600x1200 on my laptop, and 1920x1200 on my desktop except when I bring the LCD upstairs and stick it on my laptop to get 1920x1200). I'll be a good candidate for QXGA or even HXGA when it becomes affordable -- it will just give me that much more space to expand my clutter onto. I personally do not like the Macintosh interface one bit -- it gets all the key interfaces wrong for the way I work. At least to me, it emphasizes that there's one thing that it expects you to be working on at a time (click to focus and raise rather does that, especially combined with the single menu bar that's tied to whichever application is active at the time), and that one thing is front and center no matter what. Be all that as it may, I suspect that having separate layers, channels, etc. dialogs for each image might be very attractive in a lot of cases, but it's not going to be to everyone's taste. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] 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
Re: [Gimp-developer] 2.6 roadmapping, the UI part of it...
Date: Mon, 29 Oct 2007 09:40:45 +0100 From: [EMAIL PROTECTED] Sure there's tab widget. The point I was uncertain about was whether a second click on a tab would push it back in the z-order. I know Gimp is sometimes held back by limitations of GTK+ over which it has no direct influence. Robert Krawitz has replied that there is an extension that does this. Hopefully covers it. This is particularly useful for comparing two images without needing to look away. There's a Mozilla Firefox extension that does this. Mozilla extensions don't make direct GTK+ calls (as far as I know), but evidently it's possible for Firefox to know that someone has clicked on the current tab. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.6 roadmapping, the UI part of it...
Date: Sun, 28 Oct 2007 14:25:38 -0300 From: Guillermo Espertino [EMAIL PROTECTED] Loo wrote: I'm not a developer, but I am a pro, and I would love to see some kind of tab implimentation--as long as the individual images can be undocked or detabbed allowing more than one image open at a time. In fact, that's the most profound idea I'd read about for the UI. Yes, sure. But detachable tabs aren't too different to the photoshop windows in a window approach, and maybe it's a better idea to choose that instead of tabs (for people who usually rant because Gimp UI isn't like photoshop's). Personally, I'd greatly prefer tabs to nested windows for anything like this (in general, I detest nested-window MDI interfaces for any purpose). I find the two interface paradigms completely different -- nested windows have all of the clutter problems as individual windows, without the advantages of floating windows (ability to be independently managed, using my existing window manager paradigm which may be very different from what the MDI designer selected). My two use cases for this are: * I have multiple photos of the same subject with slightly different composition, lighting, what have you and I want to decide which one to work on. Nested windows don't help me; I still have to hunt for the multiple images. Tabs let me easily alternate and compare the two (or more) images, at the same size and position on the screen. * I have selected multiple photos to process sequentially. The photos aren't related, other than being part of the same job. In this case, having all of the photographs as separate tabs makes the screen a lot less cluttered than having multiple windows, whether independent or nested. It's like separate pages in a book. I may well open extra floating windows to work on the individual images, but I don't need each image to have its own window. There is *no* situation I can think of where I'd like to have multiple floating sub-windows within a larger workspace window. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] 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
Re: [Gimp-developer] 2.6 roadmapping, the UI part of it...
Date: Sun, 28 Oct 2007 10:18:12 -0700 From: Akkana Peck [EMAIL PROTECTED] I'd love to see tabs as an option in image windows. As with Firefox, you'd be able to choose Open in new window versus Open in new tab in the same window. And of course you'd always have the New view option regardless of whether you were using tabs. It would also be nice to be able to drag and drop tabs into other tabbed windows or onto the desktop (in which case they'd become independent windows). ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.6 roadmapping, the UI part of it...
Date: Sun, 28 Oct 2007 12:03:57 -0700 (PDT) From: Micahel Grosberg [EMAIL PROTECTED] - Original Message From: Guillermo Espertino [EMAIL PROTECTED] To: Filipe Soares Dilly [EMAIL PROTECTED] Cc: Sven Neumann [EMAIL PROTECTED]; gimp-developer@lists.xcf.berkeley.edu Sent: Sunday, October 28, 2007 6:51:58 PM Subject: Re: [Gimp-developer] 2.6 roadmapping, the UI part of it... Felipe: Tabs don't work for image manipulation because is frequent to compare between two+ images or work with two views (one zoomed and the other at As an alternative, I'd like to suggest a UI setup I filched from Erdas Imagine (a GIS app). It sort-of emulates the Mac OS idea of starting an application with just a toolbar. here's the mockup (I made it long ago): http://www.geocities.com/preacher_mg/UI_gimp_menu.png After the application starts, all you see is the menu dialog at the top. It's not that different from the current setup, but a top-level menu is more reasonable than a top-level toolbox. You get a single menu instead of the duplication in menus you have today (toolbox menu and image menus). You can still have the pop up dialog appear when you start Gimp, but when you close all the currently open images, you don't need to pop it up again as the menu is still there. And you can add toolbars for file operations and common dialogs. What image does the menu apply to? In particular, how does this work with focus strictly follows mouse? -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] 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
Re: [Gimp-developer] 2.6 roadmapping, the UI part of it...
Date: Sun, 28 Oct 2007 16:59:03 -0300 From: Guillermo Espertino [EMAIL PROTECTED] Reading all the comments (including Sven's saying that tabbed windows isn't too difficult to implement) I can see that maybe a switchable interface between tabbed and floating would be the most appropriate solution. The question here is how to make them live together without damaging the UI consistency. And how to deal with some of the current problems with overlapping windows (how the utility windows obstaculize the working canvas when it is maximized, dragging the canvas beyond the image borders to avoid overlapping, etc). I don't think that making tabbed and floating live together is a very hard problem -- Firefox does that just fine (and it sounds like Opera does it even better). As far as overlapping windows go, I live with it -- I use focus strictly follows mouse -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] 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
Re: [Gimp-developer] 2.6 roadmapping, the UI part of it...
Date: Sun, 28 Oct 2007 20:29:49 -0400 From: Christopher Curtis [EMAIL PROTECTED] On 10/28/07, Robert Krawitz [EMAIL PROTECTED] wrote: Date: Sun, 28 Oct 2007 12:03:57 -0700 (PDT) From: Micahel Grosberg [EMAIL PROTECTED] As an alternative, I'd like to suggest a UI setup I filched from Erdas Imagine (a GIS app). It sort-of emulates the Mac OS idea of starting an application with just a toolbar. here's the mockup (I made it long ago): http://www.geocities.com/preacher_mg/UI_gimp_menu.png What image does the menu apply to? In particular, how does this work with focus strictly follows mouse? I think the easiest way is with a last-clicked policy. The GIMP would hint to the user which image was active by either shading inactive images (eg, making their rulers darker) or highlighting the active image (eg, making the menu button brigher). Perhaps both of these concepts could be added to the mockup; currently it looks like there are 5 active windows. So then what happens if I'm using focus strictly follows mouse and I put the mouse over another window (giving it focus)? What if I don't click in the window, but do type a key (select a tool, for example)? Personally I prefer having the menu bar on each image window. It sounds like this proposal would work well for click to focus, but not so well for focus follows mouse and particularly not for focus strictly follows mouse (where taking the mouse out of a window removes focus from that window even if the mouse is over the desktop). ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.6 roadmapping, the UI part of it...
Date: Mon, 29 Oct 2007 11:34:54 +1030 From: David Gowers [EMAIL PROTECTED] On 10/29/07, Alexandre Prokoudine [EMAIL PROTECTED] wrote: On 10/29/07, Guillermo Espertino wrote: I looked at Opera, as it has been suggested here. It has very good options for managing tabs (manage different views and make tiles or cascades for multiple views, detach windows from the tabbed environment, etc.) I have to agree that it seems pretty convenient for GIMP. Now, the question is, as gg pointed out, if GTK allows that kind of solution. I've never seen a GTK app doing that, so I'm afraid it doesn't. http://curlyankles.sourceforge.net/widgets_docking.html Wow, that's very interesting Alexandre. GIMP could definitely learn from that -- for example, a quick improvement that could be made to DockBooks is, bringing a tab to the front as it's moused-over (with some minimum hover time before switching to prevent accidents.) I'd rather not have that kind of auto-raise, but there's a Firefox extension named Tab Scope that shows previews (pop-up thumbnails) of a tab when the tab is moused over. That is very useful. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] 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
