Hello Nathael, On Sun, Mar 29, 2009 at 9:17 AM, Nathael Pajani <gimp@xxxxxxxxxxx> wrote: > Hi all, > > > It appears that your only problem is that things are changing. Sorry, but you > > will have to get along with that. We are not going to stop ourselves from > > changing the GIMP user interface to the better. > Changing to the better is good, but the better should not be the point of view > of a few, neither intended to "copy the behavior of commercial programs to gain > new users" (this is the feeling I had from lots of remarks here and on IRC) , > and much less again, simplifying the interface and removing customizability > because of a said difficulty to maintain or code the whole stuff (which, I say > it once more, is insulting Gimp developers.) Removing customizability is best. I'm not kidding. Customizability is what happens when you can't figure out how to make the program behave sensibly in 99% of situations. Every point of customization is also a point of potential confusion, for both the coder and the user. Difficulty of maintenance as hard-coded options go up is a fact, it's not at all insulting. In order to achieve very reliable code, software must be tested with every combination of options available. This means to achieve moderate reliability, software must be tested with 50% or more of the combinations of options available... To show some perspective on this, you can regard each togglable option in the GIMP preferences as a bit in a binary number. In SVN head, this binary number is 43 bits long -- in my case, the number is 1111011101110000000111111111011111110001011. 43 bits of options (not including the other, multiple choice or arbitrary options, which would inflate it by quite a lot of bits -- maybe about +224 bits) means that there are 8,796,093,022,208 combinations of options to test already. This illustrates amply the situation: GIMP, and many other applications, open-source and closed-source, have so many options that thorough testing is a virtual impossibility. Each single toggleable option that is added doubles the amount of testing needed to get a bug-free program. Togglable options are the simplest case. Customizable behaviour (eg. scriptable behaviour) increase the amount of testing required for a reliable program to nigh-infinity (which is not to say that we should not have them at all. Just that they're vastly more expensive to support than togglable options) > > Sorry, but the GIMP user interface sucks and that urgently needs to > > change. > Has there been a survey about this ? Alexandre addressed this, but also : 95% of software UIs suck quite badly. This is because most often they are simply written as an afterthought to the backend: 'oh, we need to make this FOO capacity available to the user. What's the easiest way to do that?' rather than designing the frontend first and designing the backend so it fits well with the frontend. This leads to incoherent UI -- and customization of dubious value. The recent changes, OTOH, were based on real UI work with users to discover what things users most often had trouble with. > > And do not tell me (or others) it is not good because other programs have too > much customization possibilities. It is not good, precisely because they have too much customization possibilities. We need a meaningful minimum of customization, the absolute least customization for the greatest potential effect; that is the ideal customization situation for any software. > > And we are going to make some much more drastic changes in the future. > Please remember that user are working with The Gimp. Changing the user interface > drastically because you do not feel like keeping the old one will discourage Feelings have nothing to do with this. Reasoned, rational, open review does. Anyway, changes discourage and encourage people all the time, but changes should be made due to their actual merit, not their secondary effects. > So, one point I already brought to the discussion, here and on IRC: the > possibility for the user to customize the interface, or in other words, "Not ONE > interface for everybody". > When I said this on IRC (that the interface should be customizable, as it is for > so many free softwares, mind, window managers for example) I was told that this > is an ineptitude, because the most used user interface (M$ OS's one) is not > configurable. I would be interested to read the appropriate section of the IRC log, if you have it. Personally, I think Apple is a better example. They don't actually have *stellar* UI, but they do have good UI, because they really work at it. We can see, through their UI designs, that carefully considered simplicity is something that works quite well. > Then, another point: using configurations, as it is done for window managers, > which users can share. I think this would be a good improvement. > Thus, you can make things move as much as you want, as long as the user can come > back to a configuration he nows and can use. What exactly is stopping users from sharing their gimprc, templaterc, or whatever now? (like this person has done: http://crunchbang.org/archives/2007/11/01/iab-templates-for-gimp-2-dot-4/ ) > > Now, the points I criticized about the changes I noticed, and possible solutions: > > * The main menu (files, image, layer, ...) is no more in the toolbox (at the top). > I do not understand, as there is still the place reserved, (so this is screen > place lost) and it is in every image window. > Then, when I want to open a new window, or acquire a screenshot, or scan... I > have to use the menu of a current image ! This is silly ! Perhaps, but it was decided that it was less silly than having 2 separate top-level menus, and I have to agree -- having 1 top-level menu is vastly less confusing and has saved me a lot of time. And of course, if you don't like that menubar taking up space, you can disable it -- there are still a variety of ways to access the menus even without it. > One suggestion (not from me but which pleases me): have the main menu dockable, > as are the tools menus. I don't understand this suggestion at all. The tools menu? do you mean the dialog where you can toggle which tools are available or reorder them, or the toolbox itself (which is not dockable per se -- other things can dock to it, but it cannot dock to other things) > * About the lasso tool : > Previously, after going through most of the selection you needed, you were able > to release the mouse, and the selection was closing itself. now you go to > another mode of selection (polygon) !!!!! > Silly again ! > If there is a need for a polygon selection tool (And this is a good thing, you > are right), then create one ! > But please do not remove interesting features ! > And now you cannot click once in the image to clear the selection with this > tool, as it will start drawing a new polygon. Ok, you can do it by pressing > Ctrl+Shift+A, but this was nice, you you are merging a new tool in an existing one. > Create the new one please. Again, actual analysis has been done that indicates the combined tool was generally better -- if you really experiment with it, you can find it's actually extremely powerful. The 2 separate tools used to exist in GIMP, in the previous development series; I used it then, and I agree that the separated tools are vastly inferior to the combined one. With adept use of the new tool, the only common usage of the old tool you lose out on is single-stroke selections -- it is possible to make them, but harder; more often I end up pressing ENTER to close the shape, so the difference OLD versus NEW is 'click-drag' versus 'click-drag, ENTER'. I do think we would benefit from an option to automatically close the shape; I don't like pressing Enter. And, I think we could provide the 'select nothing' facility reasonably, if the user just clicks once and then hits Enter -- this is IMO a fairly clear indicator to select nothing. I think we have planned for the future, when GEGL is quite well integrated into GIMP, to make tools 'plug-in-able'. This would allow things like separate poly/freehand select tool, if you so desired and coded it. I know I'd like a 'contour fill' variant, that is like a mix between bucketfill and freehand-select: click-drag to describe a shape, which will be automatically closed and filled. (Grafx2 http://code.google.com/p/grafx2/ has this, and it's a truly excellent drawing tool.) > * acquisition menu moved (and renamed in the french version at least) > OK, this is just convenient, and this is the kind of changes one can get used > to. but this is bad when one needs to learn once again how to use something that > was just there. especially when using scanners is so touchy, and you wonder > whether it is a problem with your scanner or a said improvement. > Of course I have no solution to prevent this but saying "don't do it". > Once again, for your own convenience you are having so many people loosing so > much time. For their convenience too! Lost time in the short term is just a fact, it occurs with all changes. For definite improvements, that lost time is the price for the later gained time from the UI improvements once you learn them well. I suppose it is reasonable to not care too much about those people who leave the GIMP community because they are put off by the need to adapt to ultimately beneficial changes -- these people probably do not have the patience to do anything significant in the community anyway. > And then, on the same point, you create a new menu entry called "create" but the > "New image" is still outside of it ! This is a compromise due to how frequently the user will use 'New Image' > This can be between 2 minor versions, but when you say you are redesigning the > user interface, don't do it across major releases. This makes no sense to me again -- I'm not trying to insult you, I just look at it and think 'what does that mean?' After all, redesigning UI is a big, noticable thing. Making such a change between eg. 2.6.6 and 2.6.7 would be very rude and would contradict expectations. We have always had major changes between stable release series -- 2.2 was notably different from 2.0, as was 2.4 from 2.2, 2.6 from 2.4, and as 2.8 will be from 2.6. Big changes. Why (and how!?!) should we, could we, break this trend? David _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
