Re: More Inconsistency in eraser, blur and dodge tools
Hello all Gimpers ;-) On Mon, 1 Nov 1999, Michael Natterer wrote: Hi all, all the stuff below sounds quite good (the current modifier usage is really confusing, even for experienced users). When redefining it (making it consistent), we shouldn't forget to care for dnd. Hacking dnd of selection masks / selections between images or images and the named buffer dialog shouldn't be too hard. I've just redefined the middle mouse button to the standard gimp dnd button (not commited yet) Left mousebutton dnd still works as now, but with the middle it's possible to drag from the indicator area and from the brush/pattern/gradient selections (ie all areas where button 1 pops up a preview and/or selects stuff) I'm thinking of the following operations: shift+mouse2 -- copy paste the selection mask or copy paste the selection itself (if it's floated) ctrl+mouse2 -- cut paste the selection ifself (works only if it's floated) (You see I'm still speaking in terms of "floating" because I didn't quite get what Tigert means with "nuke" ;-) Comments, flames??? bye, Sounds fair to me. Really lovely if I may say so -- me say go for it. To add my view the path to Gimp 1.2 is * Good, consistent and user friendly UI (with out making to much core hacks i.e make it unnessesary unstable) * Stability * Release I mean releasing Gimp 1.2 before that is not wise. Why? Well what we have been bashed most of is the inconsistent UI. So adding a lot of new features and then say "stop and go" is not very wise. The bottom line Gimp is the top of the line open source application that is targeting *_users_. I don't mind waiting around extra three months to make Gimp be the top of the line program when it comes to user friendly UI. I mean if we rush it really we can maybe release Gimp 1.2 in Jan 2000. So how much will it hurt to release it in Mars instead. Cheers Olof * Gimp isn't emacs nor is it a browser, Gimp is a artist program targeting both artists and others. Just having artist in the audience makes Gimp special. Artists are conservative and they are picky about user friendly ness. This means that the UI must be good if we want to convince them to use Gimp.
Re: More Inconsistency in eraser, blur and dodge tools
Hello all On Mon, 1 Nov 1999, Austin Donnelly wrote: On Monday, 1 Nov 1999, Michael Natterer wrote: shift+mouse2 -- copy paste the selection mask or copy paste the selection itself (if it's floated) ctrl+mouse2 -- cut paste the selection ifself (works only if it's floated) But, people like dragging with mouse1 - its more of a psychological think. Also, not everyone has a 3 button mouse, so putting too much on mouse2 is probably bad. Gimp is a X11/UNIX program, which is designed to make use of three mouse buttons. I say get a three button mouse or don't use Gimp. It's a ton easier to use the middle mouse button than to remember a trillion mod key combinations. I realise distinguishing between mouse1 click, double click and drag make the event logic more complex, but I think it's worth it in reduced number of "help me!" emails. I think the best way to avoid help mails is to have a system. Which I think I'm writing just now if I remember correctly ;-). Note also alt+mouse1 drag on a selection moved the mask itself, so this feature already exists. Well see in your own mail below where you say use PS mod keys/short cuts. When you move a PS selection you move the selection it self. You aren't making it into a floating selection. See more below. I'm just saying use "to float" if you want to have a floating selection. Sven Neumann wrote: So my proposal is: Shift is used for line mode in all paint tools Ctrl is the default tool toggle key Alt limits your moevent to 15 degree directions Check what PhotoShop uses, and use that. I have hazy memories of MacPaint and SuperPaint using shift to limit to 15 degrees. Well what about how you move a selection is PhotoShop? Gimp uses the total opposite of PhotoShop and many other Win/Mac image manipulation programs. The reason why Gimp uses to float when you drag a selection is because it's still there since the days we didn't have layers. When you don't have layers you want a float to be able to do selections and masks with in the floating selection. Today this is very confusing -- the user drags a selection gets a float, if he then try to make another selection (to e.g add) she will get a mask with in the float. She will most likely start to say four letter words now and leave Gimp to rest in peace. I say if you want a float use "to float", don't "force" an unaware user into floating selections. Furthermore it is very important to be able to transform the selection (not the selection with substance). Imagine that you want to select a round traffic sign in a photo taken from an angel. This is done by making a circle selection and the shear it. Today this is very cumbersome since the transform tool will transform the substance of the selection and not the selection it self. (Yes I have tried to use quick mask and make a transform in the "red" image. It doesn't work or at least it doesn't work in my CVS very uptodate Gimp. This is still a work around and not a good solution.) Michael Natterer wrote: Comments, flames??? I think we have larger problems than UI ones right now, and I suggest people start fixing them. Eg: - shrink wrap redraws the entire image 3 times (yes, 3!) - redundant redraws in a number of other places These _really_ bite when working with (say) 3000x3000 images. Yea they probably do, but I think Mitch is a UI programmer and wanted flames or Comments on the UI thing. Note: I'm not saying that we shouldn't fix the redraw problem. They are also important, a slow application is not user friendly. Cheers and take care Olof
Re: More Inconsistency in eraser, blur and dodge tools
Michael Natterer [EMAIL PROTECTED] writes: Hi, I'm not entirely happy with this, too. However there are places where both eg a popup _and_ dnd are logical to bind to mouse1. If I find a way to intuitively distinguish the default mouse1 action (poping up the preview) and dnd, I'll run and commit the patch. One way to do it might be this: Popup the preview immediately when the user presses the button. When the mouse is moved with button1 down by more than a few pixels, pop down the preview and enter dnd-mode. If the user doesn't move the mouse (by more than a few pixels) pop down when the user releases the button. I use this technique to distinguish between clicks and drags in Sketch and it works quite well. -- Bernhard Herzog | Sketch, a drawing program for Unix [EMAIL PROTECTED] | http://www.online.de/home/sketch/
Re: More Inconsistency in eraser, blur and dodge tools
On Mon, Nov 01, 1999 at 10:29:38AM +, Austin Donnelly wrote: On Monday, 1 Nov 1999, Michael Natterer wrote: shift+mouse2 -- copy paste the selection mask or copy paste the selection itself (if it's floated) ctrl+mouse2 -- cut paste the selection ifself (works only if it's floated) But, people like dragging with mouse1 - its more of a psychological think. Also, not everyone has a 3 button mouse, so putting too much on mouse2 is probably bad. Also, mouse2 is used for panning on the canvas. Can we add similar delay as in the brushes and patterns dialog into the toolbox popups too? It could even be something like one or two seconds, is it then possible to know if the user wants to drag instead of clicking? Is this at all a good idea? Note also alt+mouse1 drag on a selection moved the mask itself, so this feature already exists. Although many window managers grab alt for themselves, this tendency should slowly fade away as windows keyboards slowly become standard. Though you can 'escape' the grab by pressing alt-shift :) though that will not work if you bind something to alt-shift :P I think we have larger problems than UI ones right now, and I suggest people start fixing them. Eg: - shrink wrap redraws the entire image 3 times (yes, 3!) - redundant redraws in a number of other places These _really_ bite when working with (say) 3000x3000 images. Also, we have had major leakage, though the worst seem to be fixed now. All kinds of weird things start to emerge with that large images, especially with many layers.. And yes, the redraws _do_ bite with large images. Btw, can anyone explain what size should the tile-cache be? I have 256MB of ram, and sometimes I need to work with 3000x3000 images, and I love to use _lots_ of layers.. This can lead to horrible swapping that can kill X if it goes too far. Is the tile-cache a sandbox for gimp so everything larger than that will get swapped to the swapfile? Or how does it work? How to figure out an optimal setting? Thanks Tuomas -- .---( t i g e r t @ g i m p . o r g )---. | some stuff at http://tigert.gimp.org/ | `---'
Re: More Inconsistency in eraser, blur and dodge tools
On Mon, Nov 01, 1999 at 12:12:28PM +0100, Olof S Kylander wrote: Well see in your own mail below where you say use PS mod keys/short cuts. When you move a PS selection you move the selection it self. You aren't making it into a floating selection. See more below. I'm just saying use "to float" if you want to have a floating selection. This has a point. However, you _can_ use "Quickmask" to apply transformations to selections with the normal tools, just make sure your background color is set to 'black', since the background color of a mask is usually black. Well what about how you move a selection is PhotoShop? Gimp uses the total opposite of PhotoShop and many other Win/Mac image manipulation programs. The reason why Gimp uses to float when you drag a selection is because it's still there since the days we didn't have layers. When you don't have layers you want a float to be able to do selections and masks with in the floating selection. Today this is very confusing -- the user drags a selection gets a float, if he then try to make another selection (to e.g add) she will get a mask with in the float. She will most likely start to say four letter words now and leave Gimp to rest in peace. I say if you want a float use "to float", don't "force" an unaware user into floating selections. I think this might be good. Though then the user needs to know that he needs to "float" a selection. If he doesnt know, a danger of 4-letter words is near also in this case. Basically the quickmask mode helps to perform the task without too much effort, but Olof's idea might make the concept easier to understand. Some people have problems when they try to use the selection tools to draw ellipses and rectangles. Maybe this could make it more clear that selections are selections, you use them to _fill_ them with something. You first create a selection, manipulate it if you need, and then fill it or something. Or cut parts of image with them. You can always "CutPaste" the selection (or Select - Float) to get the float, and I think this is pretty intuitive for those who have some computing background? Furthermore it is very important to be able to transform the selection (not the selection with substance). Imagine that you want to select a round traffic sign in a photo taken from an angel. This is done by making a circle selection and the shear it. Today this is very cumbersome since the transform tool will transform the substance of the selection and not the selection it self. (Yes I have tried to use quick mask and make a transform in the "red" image. It doesn't work or at least it doesn't work in my CVS very uptodate Gimp. This is still a work around and not a good solution.) This actually works pretty well, but like I said, you need to check your background color to avoid leaving ugly cut-out areas in the canvas. I think we have larger problems than UI ones right now, and I suggest people start fixing them. Eg: - shrink wrap redraws the entire image 3 times (yes, 3!) - redundant redraws in a number of other places These _really_ bite when working with (say) 3000x3000 images. Yea they probably do, but I think Mitch is a UI programmer and wanted flames or Comments on the UI thing. Note: I'm not saying that we shouldn't fix the redraw problem. They are also important, a slow application is not user friendly. True. The GUI is as important as the core. Both things affect the user experience :) I understand Olof is concerned about the GUI because he has the GUM to write and to keep it up to date. It is much more fun to write about stuff that is clean and consistent :) And the good part is, he also is willing to help in the programming. I'm really happy of all you guys, I know I'm very dependant of your efforts to keep Gimp in the bleeding edge. Thanks for the great work :) Tuomas -- .---( t i g e r t @ g i m p . o r g )---. | some stuff at http://tigert.gimp.org/ | `---'
Re: More Inconsistency in eraser, blur and dodge tools
On Mon, Nov 01, 1999 at 11:12:29AM +0100, Michael Natterer wrote: (You see I'm still speaking in terms of "floating" because I didn't quite get what Tigert means with "nuke" ;-) Just listen to Olof :) I was probably sleeping or something .. The point is in Photoshop you can do a trick called "NUDGE" (not nuke :) that basically does a Selection-to-float for you, you can do it by quickly flipping the cursor keys left and right for example, if I remember correctly. But we can really use CutPaste or Select - Float for that. Tuomas -- .---( t i g e r t @ g i m p . o r g )---. | some stuff at http://tigert.gimp.org/ | `---'
Re: More Inconsistency in eraser, blur and dodge tools
Thus spoke Olof S Kylander Gimp is a X11/UNIX program, which is designed to make use of three mouse buttons. I say get a three button mouse or don't use Gimp. It's a ton easier to use the middle mouse button than to remember a trillion mod key combinations. 2 button mice can be mapped to three buttons fairly easily, no matter which X server you're using. I think the best way to avoid help mails is to have a system. Which I think I'm writing just now if I remember correctly ;-). Except it doesn't seem to work on systems without GtkXmHTML installed. I don't have that on my systems Would it be possible for the build to recognize this and remove the Help option from the File menu? The current dialog that pops in these cases (no GtkXmHTML) is fairly confusing to those who aren't developers. Is GtkXmHTML a GNOME only thing now? Can it be pulled from there either into the Gimp or (better) into GTK? I say if you want a float use "to float", don't "force" an unaware user into floating selections. If I understand what you're saying here, I agree. The default behaviour for moving a selection should be to move the outline, not the contents (which forces a floating layer to be created). Positioning of selections happens more often than the actual moving of the selections contents. -- Michael J. Hammel | The Graphics Muse | Chinese Proverb: [EMAIL PROTECTED] | War doesn't determine who's right. http://www.graphics-muse.com War determines who's left.
Re: [gimp-devel] Re: tile cache size
On Mon, Nov 01, 1999 at 06:58:09PM +0100, Simon Budig wrote: Austin Donnelly ([EMAIL PROTECTED]) wrote: Idea: if the size is set to 0, make it mean "guess something good". Out of the box gimp can come with it set to 0, and we just make the algorithm pick something appropriate. That's the hard part. Just to start a discussion: What about trying to detect if it is a "private" machine with less than 5 regular users and then using 80% of the physical memory? What? All our users have login names starting from nobody000 to nobody999! :) Also, 5x80% = 400%.. a hypothetical situation of all 5 users using Gimp at the same time :) Just joking, this might have a point but it is not trivial. But at least tell me what _I_ should use to avoid excess swapping and even crashing X.. Like I said, I have 256MB. X eats like 90MB (high res, high depth), Netscape bloats too (60MB is just a 'normal' case) etc.. so say, I have something like 100MB for Gimp, sometimes a bit more (Netscape will get swapped out when I work on gimp) Someone mentioned the tile-cache should be something like half of the ram available, does that make sense? Thanks, Tuomas -- .---( t i g e r t @ g i m p . o r g )---. | some stuff at http://tigert.gimp.org/ | `---'
Re: [gimp-devel] Re: tile cache size
On Mon, Nov 01, 1999 at 12:05:26PM -0800, Tuomas Kuosmanen [EMAIL PROTECTED] wrote: But at least tell me what _I_ should use to avoid excess swapping and even It´s easy... try to detect the pysical memory (on common platforms). Then use getrlimit to find out how much virtual memory we are to use. Then take a bit less than the minimum of both values. If none exist, use 10MB. In any case, process limits need to be set administratively on multi-user machines anyway, so they should be a good guideline. Someone mentioned the tile-cache should be something like half of the ram available, does that make sense? This lacks a definition of "available". The best value is clearly 100% of the ram that is "available" ;) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Re: Tile Cache Size
This is not necissarily true. The System-Swap routine is optimized for arbitrary data. Gimp organizes its image-data in tiles and may perform better in swapping those tiles, since they are a very special data-structure. Nor false. So the swapping routines could be optimized specially for those data (I have no idea if this is done currently) and perform better than the systems routine. Yes, but Gimp swaps to files, while system normally swaps to partition, and if the admin is smart, to a fast disk which main (unique?) task is swapping, maybe even sharing swap among a group of disks. Kernels swap is optimized (I hope it is, otherwise... argh!), we dunno about Gimp. This is more a per-site than theoric thing, I know. In the machines I used, the best was to use kernel fuctions instead of Gimp (specially if it fills your home dir up to quota limit). Is there a way to get a valid performance measurement? The NFS problem should be adressed. Can we detect somehow if the configured swap-directory is a NFS-Direcrtory and issue a warning? Via mount command. I think all Unix can do that. GSR
Re: Tile Cache Size
This is totally wrong in the case of Linux (ok, not unix, but even more common). Hehehe, then how will you describe my experiences with other non-unix systems? Do not waste your time trying: pathetic and noisy just to start. With a better layout, gimp swapping should be able to succeed virtual memory in all cases (of if partition writes are faster). Thanks for the info. Then the bad performace of Gimp must be due the fact that Gimp and kernel were swapping at the same time (so hd heads move from one point to another constantly). (Ok, 2.4 will fix most of linux´ swpaping mess and use a better layout on disk, but at the moment what I say holds). Thanks kernel developers. Question: Could Gimp use a file with few holes? In otherwords, reserve space in advance, say in chunks of some MB (so OS tries to make each big block in an acceptabe layout). And what about partitions, like OS or some CDR apps? GSR
Re: More Inconsistency in eraser, blur and dodge tools
Dear Olof, Michael for the freeze - focus on bug fixing. UI problems can be Michael considered bugs, but the truth is they are a design issue. They do work, Michael just not as might be desired. I think that Michael has a good point here. Why is it useful to declare a feature freeze? In my opinion the answer is so people can begin making plans with respect to the upcoming new stable release. If just anything is allowed after a feature freeze why declare one? Olof There was no design specifications (if I'm not totally out Olof in the sky flying). We code and write etc. for the fun and Olof joy not to do specifications (don't interpret me wrong Olof design specifications is a very good thing most of the Olof time). There is no formal design specification. However, there is an informal one. When the feature freeze was announce there was a call to declare all the features that would be included in version 1.2. These UI issues were not declared, and, as Michael already said, they are not bugs. Olof, I think that the UI changes you are working on are great and need to be included in the GIMP. However, many people have worked hard (I'm not just speaking for myself) based on the presumption of a freeze. I think that should be respected. Best Wishes, Carey Bunks Dr. Carey Bunks Senior Scientist BBN Technologies 70 Fawcett St, 15/2A Cambridge, MA 02138 tel: 617-873-3028 fax: 617-873-2918 email: [EMAIL PROTECTED]
Re: More Inconsistency in eraser, blur and dodge tools
Hello Gimpers On Mon, 1 Nov 1999, Carey Bunks wrote: Michael for the freeze - focus on bug fixing. UI problems can be Michael considered bugs, but the truth is they are a design issue. They do work, Michael just not as might be desired. I think that Michael has a good point here. Why is it useful to declare a feature freeze? In my opinion the answer is so people can begin making plans with respect to the upcoming new stable release. If just anything is allowed after a feature freeze why declare one? It depends how you specify feature freeze. Some specify it as a stop to add anything (nearly a code freeze) some one else specify it as a clean up and fix time until we enter code freeze. Me my self specify it as a clean up and fix time (that includes e.g cleaning the UI to be consistent). Olof There was no design specifications (if I'm not totally out Olof in the sky flying). We code and write etc. for the fun and Olof joy not to do specifications (don't interpret me wrong Olof design specifications is a very good thing most of the Olof time). There is no formal design specification. However, there is an informal one. When the feature freeze was announce there was a call to declare all the features that would be included in version 1.2. These UI issues were not declared, and, as Michael already said, they are not bugs. I think they where declared we Sven, Micth, Simon and me made a virtual CVS check in 8 August 1999. Which was sent to the mailing list Date: Tue, 31 Aug 1999 23:10:15 +0200 (CEST) under the subject "CCC GIMP hacking and conclusions. (virtual CVS checkin)" the delay due to that the list was down. Here Micth stated a lot of nice cleanups (just go into the mail archive and read, since I think sending the mail as an attachment is a bit to much) The mail was not "rejected" from the Gimp dev-mail community. I think that document is a quite good specification about the UI. Olof, I think that the UI changes you are working on are great and need to be included in the GIMP. I'm not working on any changes. I'm writing the help system just now, which makes it painfully obvious that the UI isn't consistent. However, many people have worked hard (I'm not just speaking for myself) based on the presumption of a freeze. I think that should be respected. I know that a lot of people has worked hard, me my self included. The discussion is not about disrespect. Trust me I respect you and other hard working people 100%, but I also respect a user demanding a good UI to work within. Best Wishes Olof S Kylander
FREEZE (was Re: More Inconsistency in eraser, blur and dodge tools)
On Mon, 1 Nov 1999, Carey Bunks wrote: I think that Michael has a good point here. Why is it useful to declare a feature freeze? In my opinion the answer is so people can begin making plans with respect to the upcoming new stable release. If just anything is allowed after a feature freeze why declare one? On Tue, 2 Nov 1999, Olof S Kylander wrote: It depends how you specify feature freeze. Some specify it as a stop to add anything (nearly a code freeze) some one else specify it as a clean up and fix time until we enter code freeze. Me my self specify it as a clean up and fix time (that includes e.g cleaning the UI to be consistent). If no-one else will do it, I hearby offer to REVERT all features added to Gimp. It's quite obvious that some/ most of the people here will continue to rationalise additional features until well into the new millenium (and I don't mean 2000). Nick.
Re: Re: Tile Cache Size
In regard to: Re: Re: Tile Cache Size, Marc Lehmann said (at 10:35pm on Nov...: On Mon, Nov 01, 1999 at 10:22:08PM +0100, "Guillermo S. Romero / Familia Romero" [EMAIL PROTECTED] wrote: Yes, but Gimp swaps to files, while system normally swaps to partition, and if the admin is smart, to a fast disk which main (unique?) task is swapping, maybe even sharing swap among a group of disks. Kernels swap is optimized (I hope it is, otherwise... argh!), we dunno about Gimp. The point is that the kernel keyes the swap by memory address (physical or virtual does not matter). Which means the keys are basically random. Gimp can use optimized ordering (e.g. group tiles that are near eahc other near on the medium) that no kernel can use. Once you start to seek your performance is gone, _no matter_ how fast your physical swap may be (for linear r/w). Wouldn't the situation be even worse, then, if we're going through the filesystem and there's "average" fragmentation? You seem to be assuming that the filesystem allocation will be contiguous (or at least close) on disk, but can you really make that assumption? Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J1, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164
Re: More Inconsistency in eraser, blur and dodge tools
Thus spoke Olof S Kylander Hello Michael, Howdy! Well I know that there are people trying to write books, I'm one of them. And sure my life would be a lot easier if we just said release Gimp 1.2 on Jan 21 2000. But I tend to look at the user and the community instead. I think the best goal is to make us (the developers and supporters of Gimp) and naturally all the users happy, than making one or two Publishers happy. Its a honorable goal, but making "all the users happy" would be a bit unrealisitc. Most projects aim to offer as much as possible for users in a reasonable time frame. Consider, for example, that even Linus felt the time between releases was too long between pre2.0 and 2.0. Thats why 2.2 and 2.4 had accelerated release schedules (well, part of the reasoning at least). There is a balance that has to be struck between the need for updates (be they new features, bug fixes or design changes) and delivering an updated product to users. Additionally, UI changes were not part of the design specifications for the 1.2 release. There was no design specifications (if I'm not totally out in the sky flying). We code and write etc. for the fun and joy not to do specifications (don't interpret me wrong design specifications is a very good thing most of the time). That may be the way projects start, but in the long term it will be very difficult to survive that way. The problem is that the project (I'm speaking in generalities here, not specifically about the Gimp) grows and involves more people. If developers fail to recognize these peoples need to make and stick to schedules, then those added people move away. People will chose the tools which meet their needs, and many users include release schedules in their needs. Of course, design specs are hard to avoid after the product gets as sophisticated as the 1.2 release has. You have many people working in many areas, and design specs just help make sure everyone is working toward the same goals. Although I agree with the need for UI consistancy, at this point I feel the need for a "reasonably near" release date would do more for user morale. The new features will outweight the UI problems, at least for a time. That extra time could be used for a 1.2.x release with the UI updates. Anyway, this is all just another point of view. As a writer, I'll adjust to what the developers decide, as I'm sure many people will. -- Michael J. Hammel |All the worlds a stage, and all the men and The Graphics Muse |women merely players. [EMAIL PROTECTED] |Shakespeare, "As You Like It", II, 7 http://www.graphics-muse.com
Re: More Inconsistency in eraser, blur and dodge tools
Thus spoke Olof S Kylander It depends how you specify feature freeze. Some specify it as a stop to add anything (nearly a code freeze) some one else specify it as a clean up and fix time until we enter code freeze. In commercial development (telecom and interactive cable, for example, where I've worked in the past), "code freezes" are seldom used. Its almost impossible, in practice, to disallow code updates because you're always finding one more bug. "Feature freezes" tend to be aimed at focusing development efforts on creating the distributable product. Often, management will pull features which aren't working in order to meet the promised schedule, moving the pulled features to the next release. This is just for a comparative purposes. It doesn't mean Gimp (or any Open Source project) need follow these guidelines. Me my self specify it as a clean up and fix time (that includes e.g cleaning the UI to be consistent). I could agree with this, as long as the primary goal is the release date set at the time of the feature freeze. I think they where declared we Sven, Micth, Simon and me made a virtual CVS check in 8 August 1999. Which was sent to the mailing list Date: Tue, 31 Aug 1999 23:10:15 +0200 (CEST) under the subject "CCC GIMP hacking and conclusions. (virtual CVS checkin)" the delay due to that the list was down. Here Micth stated a lot of nice cleanups (just go into the mail archive and read, since I think sending the mail as an attachment is a bit to much) The mail was not "rejected" from the Gimp dev-mail community. I think that document is a quite good specification about the UI. Thats fine, and sticking to the spec as it was defined here is a reasonable goal. But consider, too, that 7 months between feature freeze to release (assuming a March release, as you suggested in an earlier email) is a rather long time, especially considering it was 6 months (at least) between the 1.0 release and the 1.2 feature freeze. -- Michael J. Hammel | The Graphics Muse |I'm just working here till a good fast-food [EMAIL PROTECTED] |job opens up. http://www.graphics-muse.com
Re: FREEZE (was Re: More Inconsistency in eraser, blur and dodge tools)
Thus spoke Nick Lamb If no-one else will do it, I hearby offer to REVERT all features added to Gimp. It's quite obvious that some/ most of the people here will continue to rationalise additional features until well into the new millenium (and I don't mean 2000). Hopefully this won't be necessary. Compromise is an important part of any community. I'm sure something can be worked out. -- Michael J. Hammel | A politician's words reveal less about what he The Graphics Muse | thinks about his subject than what he thinks [EMAIL PROTECTED] | about his audience. George F. Will (b. 1941), http://www.graphics-muse.com U.S. political columnist.
