Re: More Inconsistency in eraser, blur and dodge tools
On Mon, Nov 01, 1999 at 10:20:01PM +0100, Olof S Kylander wrote: > Hello Michael, > > On Mon, 1 Nov 1999, Michael J. Hammel wrote: > > > 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. > > > > Actually, it has a potentially big impact. The Gimp is one of the premiere > > applications in the Linux world. A feature freeze was announced earlier in > > an attempt to schedule a release date. You have quite a few book > > publishers trying to do books on the Gimp and trying to time release of the > > book with the product. End users associate published texts with the product, > > especially when a printed document is not delivered with the product. > > > > I've had at leat 5 different publishers ask me about release dates. I've > > been telling them late December to late January based on the feature > > freeze and goals for the freeze - focus on bug fixing. UI problems can be > > considered bugs, but the truth is they are a design issue. They do work, > > just not as might be desired. > > 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. I agree. It is not about developing gimp in a way that sells the most books. Ii is about making the ultimate graphics tool for Linux/Unix that is free and helps you to make the job done. Books shall follow that. Now, I DO understand, like Olof that it's a cat-and-a-mouse play writing a book about all this, but isn't the application the most important thing? Otherwise we can just stop the development, fix all bugs and release Gimp Final and start writing books about it. But we are talking about a developers version here, which just entered freeze. I do consider the GUI part very important, since I'll be twiddling with that most of the time. Others consider their book important which is perfectly understandable. But does Gimp exist for us to write books about it or to use it? I dont mean this as a flame. But basically Yosh is the maintainer, people here are the developers, and while trying not to break everything, I think the goal is to mold gimp into more usable, more powerful application. Books need to follow the development, not vice versa. > > 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). Right. If we find along the way that some rules are not good anymore, those can to be changed if everyone agrees. Since some good points were raised on the GUI part, why not fix them since people are willing to implement the changes? It would be totally different if nobody would be willing to _do_ the work. Just some thoughts, I dont mean this as a flame against you writing books, those are very important too, especially for new users! After all, we'll get a stable Gimp with, hopefully, also a great GUI :) Tuomas -- .---( t i g e r t @ g i m p . o r g )---. | some stuff at http://tigert.gimp.org/ | `---'
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.
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: 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
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: 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
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
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
Hello Michael, On Mon, 1 Nov 1999, Michael J. Hammel wrote: > > 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. > > Actually, it has a potentially big impact. The Gimp is one of the premiere > applications in the Linux world. A feature freeze was announced earlier in > an attempt to schedule a release date. You have quite a few book > publishers trying to do books on the Gimp and trying to time release of the > book with the product. End users associate published texts with the product, > especially when a printed document is not delivered with the product. > > I've had at leat 5 different publishers ask me about release dates. I've > been telling them late December to late January based on the feature > freeze and goals for the freeze - focus on bug fixing. UI problems can be > considered bugs, but the truth is they are a design issue. They do work, > just not as might be desired. 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. > 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). Cheers Olof
Re: More Inconsistency in eraser, blur and dodge tools
Hello All :-) On Mon, 1 Nov 1999, Michael Natterer wrote: > 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. On the other > hand you can now (after my next commit ;-) drag stuff from brushes/ > patterns/gradients without changing the active element. In all > places where mouse1 has no special meaning, dnd works with mouse1. > > This is not perfect, so please bomb me with suggestions... Well if I think of some I will send them to you instantly. > > 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. > > Yep. What I meant was dragging the selection mask / selection itself > to another image, not inside the same canvas. Yes thats the way to go! > Agree. But I also think that removing ui inconsistencies actually _is_ > bugfixing. Bringing dnd everywhere to make the thing consistent isn't > necessarily bugfixing-only, but as it goes hand-in-hand with the context > stuff (which did fix various bugs), I guess it's worth to finish for 1.2. Totally agree with Mitch! I.e Mitch hack it nice but don't make unnessesary changes making even more unstable. Cheers Olof
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: More Inconsistency in eraser, blur and dodge tools
Thus spoke Olof S Kylander > 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_. Very true. > 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. Actually, it has a potentially big impact. The Gimp is one of the premiere applications in the Linux world. A feature freeze was announced earlier in an attempt to schedule a release date. You have quite a few book publishers trying to do books on the Gimp and trying to time release of the book with the product. End users associate published texts with the product, especially when a printed document is not delivered with the product. I've had at leat 5 different publishers ask me about release dates. I've been telling them late December to late January based on the feature freeze and goals for the freeze - focus on bug fixing. UI problems can be considered bugs, but the truth is they are a design issue. They do work, just not as might be desired. Additionally, UI changes were not part of the design specifications for the 1.2 release. Feature updates were, but mostly as a matter of work done. Although I agree that UI updates are necessary, it seems too late in the 1.2 cycle to try to add a focus on them now. We're already looking at a full year between 1.0 and 1.2. For what its worth, my wishes would be that UI changes be spec'd out for 1.4 and not added into the freeze period for 1.2. -- Michael J. Hammel | The Graphics Muse | I'm not a complete idiot, some parts are missing! [EMAIL PROTECTED] | http://www.graphics-muse.com
Re: More Inconsistency in eraser, blur and dodge tools
Tuomas Kuosmanen wrote: > > 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 Cut&Paste or Select -> Float for that. Ah, ok. It's just another word for "float". At least I didn't confuse it with "nude" ;-) Anyway "nuke" sounds a bit radioctive ... we would need a special mouse cursor for this operation then (just to prevent users from getting an overdose) ciao, --Mitch
Re: More Inconsistency in eraser, blur and dodge tools
Hi, Austin Donnelly wrote: > > On Monday, 1 Nov 1999, Michael Natterer wrote: > > > +mouse2 --> copy & paste the selection mask or > > copy & paste the selection itself (if it's floated) > > +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. 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. On the other hand you can now (after my next commit ;-) drag stuff from brushes/ patterns/gradients without changing the active element. In all places where mouse1 has no special meaning, dnd works with mouse1. This is not perfect, so please bomb me with suggestions... > 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. Yep. What I meant was dragging the selection mask / selection itself to another image, not inside the same canvas. > 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. Agree. But I also think that removing ui inconsistencies actually _is_ bugfixing. Bringing dnd everywhere to make the thing consistent isn't necessarily bugfixing-only, but as it goes hand-in-hand with the context stuff (which did fix various bugs), I guess it's worth to finish for 1.2. Happy GIMPing, --Mitch
Re: More Inconsistency in eraser, blur and dodge tools
Hello (again) On Mon, 1 Nov 1999, Tuomas Kuosmanen wrote: > 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 talk about generating "help" mails ;-). > > 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. [snip] > > > > 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. Maybe but as you also say Cut&Paste is more common in the comp world. Beside that if you really want a float you most of the time don't want to move it, and then you use "to float". > 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 "Cut&Paste" the selection (or Select -> Float) to get > the float, and I think this is pretty intuitive for those who have some > computing background? I also think so so why not change the behavior to not create a float? > 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. Well see my above comment about help mail generating ;-). It's not funny to write about work arounds in the Help system. > 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 :) Well, actually the help system this time. When I started to convert it to 1.2 it was painfully obvious that we had a inconsistent way of handling mod-keys and selections. My plan is to make the help sys and then GUM since after making the help I got the core text to GUM. And the good part is, he also is > willing to help in the programming. Maybe a little but I'm filled up with Airbrush, Help, GUM 1.0.X and GUM 1.2 and GUT 1.2. Cheers Olof
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 Cut&Paste 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
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 "Cut&Paste" 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 10:29:38AM +, Austin Donnelly wrote: > On Monday, 1 Nov 1999, Michael Natterer wrote: > > > +mouse2 --> copy & paste the selection mask or > > copy & paste the selection itself (if it's floated) > > +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
Hello all On Mon, 1 Nov 1999, Austin Donnelly wrote: > On Monday, 1 Nov 1999, Michael Natterer wrote: > > > +mouse2 --> copy & paste the selection mask or > > copy & paste the selection itself (if it's floated) > > +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: > > is used for line mode in all paint tools > >is the default tool toggle key > > limits your moevent to 15 degree directions > > Check what PhotoShop uses, and use that. I have hazy memories of > MacPaint and SuperPaint using 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
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: > > +mouse2 --> copy & paste the selection mask or > copy & paste the selection itself (if it's floated) > +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
On Monday, 1 Nov 1999, Michael Natterer wrote: > +mouse2 --> copy & paste the selection mask or > copy & paste the selection itself (if it's floated) > +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. 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. 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. Sven Neumann wrote: > So my proposal is: > is used for line mode in all paint tools >is the default tool toggle key > limits your moevent to 15 degree directions Check what PhotoShop uses, and use that. I have hazy memories of MacPaint and SuperPaint using to limit to 15 degrees. 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. Austin
Re: More Inconsistency in eraser, blur and dodge tools
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: +mouse2 --> copy & paste the selection mask or copy & paste the selection itself (if it's floated) +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, --Mitch Sven Neumann wrote: > > Hi, > > > There are some major inconsistency or more precisely hard to use functions > > in the eraser, the sharpen/blur and dodge/burn tools. > > > > Pressing Ctrl will change the tool behavior from eraser --> anti-eraser, > > blur --> sharpen and dodge --> burn. > > > > Pressing Ctrl will in combination with Shift limit the movements/stokes > > to horizontal movements. > > > > Okay so if you want to have only horizontal movements then you also get the > > opposite effect i.e sharpen instead of blur. This is _not_ good!!! > > Okay so if you want the opposite effect and want to e.g have only > > vertical movements? This will not work with short cuts. > > > > Anyway this will be a mess in short cuts and work around solutions. > > > > I think it's better to remove the "line" drawing function you will > > probably not use it as much as you use the short cut to change tool > > effect. > > > > Yes, we have to overwork the modifier keys! I'd propose to use only a > single modifier for constraining the movement into a special direction. > The gradient/blend tool already offers this. Strg/Ctrl are bound to > horizontal/vertical movements as usual. Shift shows what I am thinking > of here: It limits you to 15 degrees steps. IMHO this works quite well > and would free up one modifier. It should be possible to find one key > that can then be used explicitely for constraints and would never have > a different meaning. > > So my proposal is: > is used for line mode in all paint tools >is the default tool toggle key > limits your moevent to 15 degree directions > > We would have to drop for "Allow Enlarging" in the Crop&Resize tool, > but I think we could live without that. > > Salut, Sven
Re: [gimp-devel] Re: More Inconsistency in eraser, blur and dodge tools
>Hmm - what do you think about dropping the panning (Ugh - no - dont beat
>me! :-) I think the Quick-navigation is much more useful and quicker.
But less precise. And you must move your cursor to the corner. That is like
having the menus in a fixed place instead of where you want (tear off or
right click).
>So we could use the middle mousebutton for an alternative function, maybe
>even a second device with an own context.
Let me see: we have ctrl, shift, alt and space, all near and waiting to be
used (meta / windowskey / "whatever the name" too in some machines). Or
maybe we could have a dialog and let the user select what action wants.
I think actions should make reference to the key:
Shift to change behaviour ("inverse").
Ctrl for fine control (lines, angles).
Alt for alternative (alternative what? alt shift and alt ctrl?).
Well you get the idea, fixing keybindings, yes, removing features (specially
if there is no strong reason), no thanks.
Can anybody post the curent list of key mods?
GSR
Re: [gimp-devel] Re: More Inconsistency in eraser, blur and dodge tools
Tuomas Kuosmanen ([EMAIL PROTECTED]) wrote: > We also have Space if we need something. On Photoshop it is used for > panning, but Gimp has mouse2 for that. Could Space be a toggle after all for > the togglable tools? I know we had a talk about this a while back, and we > agreed that Shift is a "natural" way to "shift" things.. But it is clearly > conflicting at the moment.. I would be just happy to control the tool > toggles (erase/antierase, fg/bg fill, blur/sharpen, dodge/burn) with SPACE. Hmm - what do you think about dropping the panning (Ugh - no - dont beat me! :-) I think the Quick-navigation is much more useful and quicker. So we could use the middle mousebutton for an alternative function, maybe even a second device with an own context. Just my 0.01$ :-) Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: More Inconsistency in eraser, blur and dodge tools
Hello > Yes, we have to overwork the modifier keys! HeHe ;-), it is more or less impossible to know what all of them do. I'd propose to use only a > single modifier for constraining the movement into a special direction. > The gradient/blend tool already offers this. Strg/Ctrl are bound to > horizontal/vertical movements as usual. Shift shows what I am thinking > of here: It limits you to 15 degrees steps. IMHO this works quite well > and would free up one modifier. It should be possible to find one key > that can then be used explicitely for constraints and would never have > a different meaning. > So my proposal is: > is used for line mode in all paint tools >is the default tool toggle key > limits your moevent to 15 degree directions > > We would have to drop for "Allow Enlarging" in the Crop&Resize tool, > but I think we could live without that. I think that would be a _very_ nice solution !!! Lets go for it!! Cheers Olof
Re: More Inconsistency in eraser, blur and dodge tools
Hi, > There are some major inconsistency or more precisely hard to use functions > in the eraser, the sharpen/blur and dodge/burn tools. > > Pressing Ctrl will change the tool behavior from eraser --> anti-eraser, > blur --> sharpen and dodge --> burn. > > Pressing Ctrl will in combination with Shift limit the movements/stokes > to horizontal movements. > > Okay so if you want to have only horizontal movements then you also get the > opposite effect i.e sharpen instead of blur. This is _not_ good!!! > Okay so if you want the opposite effect and want to e.g have only > vertical movements? This will not work with short cuts. > > Anyway this will be a mess in short cuts and work around solutions. > > I think it's better to remove the "line" drawing function you will > probably not use it as much as you use the short cut to change tool > effect. > Yes, we have to overwork the modifier keys! I'd propose to use only a single modifier for constraining the movement into a special direction. The gradient/blend tool already offers this. Strg/Ctrl are bound to horizontal/vertical movements as usual. Shift shows what I am thinking of here: It limits you to 15 degrees steps. IMHO this works quite well and would free up one modifier. It should be possible to find one key that can then be used explicitely for constraints and would never have a different meaning. So my proposal is: is used for line mode in all paint tools is the default tool toggle key limits your moevent to 15 degree directions We would have to drop for "Allow Enlarging" in the Crop&Resize tool, but I think we could live without that. Salut, Sven
Re: More Inconsistency in eraser, blur and dodge tools
On Sun, Oct 31, 1999 at 01:08:03PM +0100, Olof S Kylander wrote: > Hello Again > > There are some major inconsistency or more precisely hard to use functions > in the eraser, the sharpen/blur and dodge/burn tools. > > Pressing Ctrl will change the tool behavior from eraser --> anti-eraser, > blur --> sharpen and dodge --> burn. > > Pressing Ctrl will in combination with Shift limit the movements/stokes > to horizontal movements. > > Okay so if you want to have only horizontal movements then you also get the > opposite effect i.e sharpen instead of blur. This is _not_ good!!! > > Okay so if you want the opposite effect and want to e.g have only > vertical movements? This will not work with short cuts. > > Anyway this will be a mess in short cuts and work around solutions. > > I think it's better to remove the "line" drawing function you will > probably not use it as much as you use the short cut to change tool > effect. I find this annoying too. We simply have too much modifiers or something :) And I personally dont use the linedraw too much, though I need it sometimes. But I find the linedraw preview that always is on the way pretty annoying.. > A small question, why don't we use the AltGr button? Most people use mouse with their right hand and thus have the left hand on the keyboard.. And AltGr is pretty far.. But I am left handed, so I'm all for this :) (no, I dont use the mouse in my left hand though.. I can control 2 pointer-devices simultaneously, navigating menus is IMHO easier with the mouse than with the tablet pen :) We also have Space if we need something. On Photoshop it is used for panning, but Gimp has mouse2 for that. Could Space be a toggle after all for the togglable tools? I know we had a talk about this a while back, and we agreed that Shift is a "natural" way to "shift" things.. But it is clearly conflicting at the moment.. I would be just happy to control the tool toggles (erase/antierase, fg/bg fill, blur/sharpen, dodge/burn) with SPACE. Thoughts? Tuomas -- .---( t i g e r t @ g i m p . o r g )---. | some stuff at http://tigert.gimp.org/ | `---'
