Hello!
On Mon, Mar 30, 2009 at 00:30, Nathael Pajani <g...@nathael.net> wrote: > David Gowers a écrit : > > These are dockable. And we can create as many windows as we want, with groups > of > these tabbed inside. This is customization. > The main menu (http://www.nathael.org/Data/main_menu.jpg) should be dockable > as > well. If you make such suggestions please always say why. To add customization because it is technical possible is not an argument. Every new option or new feature must help to reach the product vision. And to do so, every new feature should have an usecase that describes how this feature helps to reach the product vision with this feature. >> 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 [...] means that there are >> 8,796,093,022,208 combinations of options to test already. >> [....] > I cannot agree with you here. If the complexity increases logarithmic or linear is not that impotent. But I don't understand, why you are trying tu discuss facts. Every option is expensive. It costs time in programming, testing, documenting, supporting ... > Once again, I'll use the kernel as an example here: I won't bother counting > the > number of options and the possibilities resulting, I'll just state that it's > the > biggest piece of code I have ever seen, and still the most reliable. > Are kernel programmers "superhero" ? "genius" ? As a lot of other people already told you, you can't compare the kernel with GIMP. Just have a look at the number of developers. There are ~10, perhaps even less, active GIMP developers and no one is paid for working on GIMP. > Tell me, I'm one of them, I'll appreciate :) > Another example I'll use as some spoke about it previously: Gnome. I'll not > bother counting the options you can find in gconf either. Still, gnome is > stable > (from my point of view at least, but most will agree) and even if it's not a > perfect display manager, I think it's a very good one that manages to perform > it's task. > And the Gnome example is most accurate, don't try saying the contrary this > time: > it uses GTK, and it's also a GNU project. > But it's not one program. If you are looking for a programm to compare GIMP with have a look at OpenOffice, Inkscape, Blender, Krita... >>> > 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. > Right and wrong. > Right, the UI must not come as an afterthought. > But the UI is not the main part of an Image manipulation program, it's here to > give access to it's capabilities. Have a look into the code, the UI is the biggest part in GIMP. > So designing the UI first is just silly. Both have to be thought in parallel. Of cause this in reality not an linear process, but an interaction between the developers, the UI designers and the users. > But this is very hard for a project like Gimp, when programmers are more > interested in the backend part and when this part is made up of small parts > added one by one with no global initial view. You are having a wrong assumption here. Most of the GIMP developers are interested in the UI and the "global initial view" is the product vision. >> The recent changes, OTOH, were based on real UI work with users to >> discover what things users most often had trouble with. > I just hope you did not ask users that would like to have a photoshop clone > for > free. > That's why I pasted the points from GimpCon 2006. Users tend to want what they > have with the commercial software. Gimp is not that. The GIMP GUI team made user observations, wrote user scenarios, made a meeting with the developers, community members, documentation writers and more. And one of the rules always was and still is: "GIMP is not Photoshop!" > But then I do not see the merit behind having an empty window when you start > gimp, with most menu being empty. Have a look into the "No image open specification": http://gui.gimp.org/index.php/No_image_open_specification >> And of course, if you don't like that menubar taking up space, you can >> disable it > It's it not being here but still taking up the space that is strange: > http://www.nathael.org/Data/unused_menu_space.jpg That is not the space that was used for the menu, but a new space that was added after removing the menu to indicate that you can drop images to the toolbox like you can drop images to the "No Image Window" (NIW) >>> One suggestion (not from me but which pleases me): have the main menu >>> dockable, >>> as are the tools menus. Yes, that is a valid wish and was already discussed some time before. The problem is, that the toolbox was the main window and so a little bit special. Removing the menu out of the toolbox and adding the NIM was the first step to make the toolbox a little bit less special. >>> * About the lasso tool : >> [....] >> 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'. > Ho, very nice UI improvement ! > How are we supposed to discover this ? Have a look into the statusbar. > Nice to know anyhow. I don't mind having to press enter to finish, but I > cannot > discover it. What have you tried to discover it? > If you plan for good UI, then a small tooltip saying "press enter to close the > selection" (of course with a setting to enable/disable tooltips, or it would > not > be fun) would be a UI improvement. No, tooltips are not a good idea, because tooltips would hide parts of the most impotent thing in GIMP the image. That's why the statusbar is much saner for GIMP. >>> * acquisition menu moved (and renamed in the french version at least) >> [....] >> 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. > Right, but I do not see the improvement It was renamed because the script-fu menu points from the old Xtns-menu (btw. a really bad name for a menu) where added to this menu and then the old menu name no longer fit to the entries inside it. >>> 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' > I use it less than 10% of the times I use gimp... and I must not be the only > one. But I use screenshots and scanning very often on the other hand. An other reason for keeping the 'New Image' at top is, that it is the recommended place from the Gnome HIG. (And the Apple HIG) > From my experience, when you are redesigning something, it can be done > accross > minor releases (2.6.6 to 2.6.7 and then more parts for 2.6.8, and some more > again for 2.6.9 and so on. GIMP follows here the good old GNU version theme major.minor.maintenance. The last number is for bugfixes and translations only the second number fpr API compatible releases. > But not some parts for 2.6, some for 2.8, and some last bits for 2.10 > Releasing is not a requirement (or so I think). If there is job to be done, > you > do it before releasing a major release so that ALL the changes are done for > the > major release. > When all of you are saying "we are redesigning the UI" but here is only one > part, I feel like it is a work in progress. This is completely contradictory > to > performing major releases. You do not release a work in progress as a major > release. > Am I the only one with this point of view ? > Yes, because at least I'd like to have a new GIMP version every 1-2 years and not every 10 years. Regards, Tobias _______________________________________________ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
