Transform tool not ready for release
I've been hacking at the internals of the transform tool, but until now I hadn't looked at how it worked from the outside. It's just not right! You need to be able to set the transform by swapping between modes (rotate/shear/scale/perspective - plus move), adding to the existing transform at each stage, and checking the result (probably with no smoothing, for speed). Once it's right, the final transform should be done in one step from the original layer. Right now, it's not very useful for real work. (Can some users back me on this?) This is independent of how it handles selections, of course. (As an aside, I think 1.0.4 was closer to the correct behaviour, at least in performing each transform from scratch instead of from the previous result. Do we need some kind of forum for discussing and keeping track of design decisions like these? Preferably one with working artists involved. Or are they listening here?) So, does this fall inside or outside the feature freeze? (It's not exactly new code, mostly just rearrangement.) Is anyone else in a position to work on this, or should I take it on? Does anyone seriously disagree that this needs doing, even if not for 1.2? -- David Hodson -- [EMAIL PROTECTED] -- this night wounds time
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
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
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: 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
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: Re: Tile Cache Size
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). There are obvious exceptions, like nfs, but I think we shouldn´t optimize for the broken case. -- -==- | ==-- _ | ---==---(_)__ __ __ 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: [gimp-devel] Re: Tile Cache Size
On Mon, Nov 01, 1999 at 10:02:29PM +0100, Simon Budig <[EMAIL PROTECTED]> wrote: > 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. Last time I looked, swap space in gimp is managed on a first come first server basis, i.e. no special layouting. It should not perform worse than linux´ swapping, which is much worse in some respects. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Tile Cache Size
On Mon, Nov 01, 1999 at 09:41:17PM +0100, "Guillermo S. Romero / Familia Romero" <[EMAIL PROTECTED]> wrote: > Why I say that? Becuase Unix swap (I suppose to a partition, not to a file) > will be better than Gimp swap This is totally wrong in the case of Linux (ok, not unix, but even more common). With a better layout, gimp swapping should be able to succeed virtual memory in all cases (of if partition writes are faster). (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). -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
I18N
The stupid I18N behaviour of the week: when menus are translated, any string for which the system finds no translation gets translated to "Fichier" (in French), which means "File". I don't know the innards of the translation system, but a fact is that things used to work more or less and now are broken. :-( --- David Monniaux Tel: +33 1 44 32 20 66Fax: +33 1 44 32 20 80 Laboratoire d'informatique de l'École Normale Supérieure, 45 rue d'Ulm - 75230 PARIS cedex 5 - FRANCE
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: [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: [gimp-devel] Re: Tile Cache Size
Guillermo S. Romero / Familia Romero ([EMAIL PROTECTED]) wrote: > Why I say that? Becuase Unix swap (I suppose to a partition, not to a file) > will be better than Gimp swap. So if you need to swap, use first what the OS > provides, and then Gimp system (and if NFS, remember to use local /tmp for > Gimp). 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. 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. The NFS problem should be adressed. Can we detect somehow if the configured swap-directory is a NFS-Direcrtory and issue a warning? Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: Tile Cache Size
>And, Tigert, in your case I'd propose to set it to something like 200MB >assuming you don't do too much other stuff when working on large images. >From my experience, tile cache size should be calculated (in a stand alone workstation, aka system where processes are mainly owned by the guy with the mouse) as RAM plus real swap minus kernel, X, wm, terminals, etc memory. Why I say that? Becuase Unix swap (I suppose to a partition, not to a file) will be better than Gimp swap. So if you need to swap, use first what the OS provides, and then Gimp system (and if NFS, remember to use local /tmp for Gimp). Disclaimer: personal experience based on the speed I experienced and the noise I heard (HD making "music" vs pure mad noise). I have not read the source, measured stats with top or anything technical. GSR
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: 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: [gimp-devel] Re: tile cache size
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? Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: tile cache size
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. Austin
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
Tile Cache Size
Hi, Tigert wrote: > > 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? > Ooh, it hurts that now even our major poweruser nows how to set the tile_cache_size correctly. This makes clear that we have to do something about this. Every time I see people using The GIMP, they haven't changed their tile_cache_size and work with the default setting of 10MB which makes it awfully slow!! What about the idea I proposed to let the user set the tile_cache_size in the user_installation process? We could pop up a dialog explaining the meaning of the tile_cache and proposing some suitable defaults based on the amount of memory the user has. And, Tigert, in your case I'd propose to set it to something like 200MB assuming you don't do too much other stuff when working on large images. Salut, Sven
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
