Re: [Gimp-developer] Gimp interface changes
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
Re: [Gimp-developer] Gimp interface changes
Hi all! Tobias Jakobs wrote : On Mon, Mar 30, 2009 at 00:30, Nathael Pajani g...@nathael.net wrote: 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. Right. Because I do not see why there are now two windows at startup. Yes, you pointed to the wiki explanation already. It seems you are all OK for this empty unuseful window at Gimp startup or when the user closes all image windows to bring back it's desktop space for something else. With screens becoming wider, a vertical toolbox is not too much space wasted, but that big empty window is here for nothing. You even had to specify what it should look like for it not to be mistaken for an image window. This was impossible with the toolbox window. And then, using the toolbox window to open a new image seems OK to me, while using an existing image window is just incoherent. But then I do not see the merit behind having an empty window when you start gimp, with most menu being empty. 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) So, a duplicate space, and as we can drop in the tool selection part, it's mostly an extension of this space, so taking up space for not much. 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 ... And ? Gimp is not a paint. I thought free software were not bound to create releases in time at the lowest possible cost. 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. Ok, I'll drop this comparison. And I won't comment on the number of gimp developers, but try not to have it decreasing further. And Gimp being free software, you can call on contributors... But some seems to wait for it to be a phoenix... 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... Ok, I'll use one of your proposed examples: OpenOffice Won't bother counting the options either. 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. The number of lines of code has nothing to do with what is important. Gnome is a UI Window managers are UI GIMP is an Image Manipulation Program The User interface is here to allow access to it's capabilities as an image manipulation program. Or am I mistaken again ? Even, both parts might be independent and many UI being pluggable to the image manipulation part. 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. Right. David Gowers wrote: -- this is what led to the current form of the free-select tool -- but the whole idea of an application is to provide capabilities to the user .. the interface should not be dependent in any way on how the feature is actually implemented, just that the way it's implemented should be reasonably straightforward and plain. Right also. But once again what in here prevented the designers from creating two tools? especially when selections can be summed up using different select tools? But maybe we should stop arguing on this point, as each argument you try to bring in is an argument for my point of view, or has no relation to the point you try to defend. Maybe I'm
Re: [Gimp-developer] Gimp interface changes
Nathael Pajani (g...@nathael.net) wrote: Right. Because I do not see why there are now two windows at startup. Yes, you pointed to the wiki explanation already. It seems you are all OK for this empty unuseful window at Gimp startup Please don't confuse your opinion with facts. This window is useful and why it is useful has been discussed already or is described in the spec. With screens becoming wider, a vertical toolbox is not too much space wasted, but that big empty window is here for nothing. You even had to specify what it should look like for it not to be mistaken for an image window. This was impossible with the toolbox window. But the toolbox window cannot fulfil the tasks of the no-image window. For a start it cannot show the proper global menu. 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 ... And ? Gimp is not a paint. I thought free software were not bound to create releases in time at the lowest possible cost. Gimp not being paint - which in itself is a polemic and not-helpful non-comparison - does not mean that we *have* to make our life harder than necessary. [...] 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. The number of lines of code has nothing to do with what is important. Gnome is a UI Window managers are UI GIMP is an Image Manipulation Program The User interface is here to allow access to it's capabilities as an image manipulation program. Or am I mistaken again ? Count the numbers of people using gimp as a programmatic backend and compare it to the number of people using gimp via the GUI. Then you have a rough estimate if the UI of Gimp is important or not. (Hint: There is a reason why we recomment imagemagick to people for certain tasks) The UI actually is the main part of an Image manipulation program; NO at least, it's the main part of GIMP. NO again, because you are confusing it's goal, and the number of lines of code related to each part. Why are you trying to argue against our own perception of the Gimp? Isn't Gimp what the Gimp developers think it is? An other reason for keeping the 'New Image' at top is, that it is the recommended place from the Gnome HIG. And ? Gimp will become GNOME dependent ? (And the Apple HIG) Apple dependent ? I guess we should follow the NHIG - i.e. The Nathael Human Interface Guidelines. Because there is nothing that is researched better. /sarcasm Bye, Simon -- si...@budig.de http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp interface changes
On Tue, Mar 31, 2009 at 8:25 AM, Nathael Pajani g...@nathael.net wrote: Hi all! The number of lines of code has nothing to do with what is important. Gnome is a UI Window managers are UI GIMP is an Image Manipulation Program The User interface is here to allow access to it's capabilities as an image manipulation program. Or am I mistaken again ? No, but this doesn't negate the idea that the UI is the most important part. If GIMP didn't have it's UI, it would instead be something like ImageMagick. Since people mainly use GIMP in a way that is incompatible with ImageMagick, it's reasonable to conclude that the most significant part of GIMP is it's UI. Right also. But once again what in here prevented the designers from creating two tools? They did. And then, they got feedback that said, these tools are too similar, I think they would work better merged. especially when selections can be summed up using different select tools? But maybe we should stop arguing on this point, as each argument you try to bring in is an argument for my point of view, or has no relation to the point you try to defend. Maybe I'm having you loosing too much time on these emails. I'm not losing any time, though you often don't seem to understand; whether this is because of a language barrier or simply your own insistence on having a different conversation from everyone else participating in this discussion, I don't know; but be assured that any time wasted, is not mine. I can quote Sven as saying that the majority of code in GIMP deals with UI, and my own investigation of GIMP code confirms this. I did not investigate, so I'll rely on you, and I can understand this very well. But it doesn't make the UI any more important. This is a good point. I addressed it earlier in this email. Nothing about pressing ENTER in the status bar. (in french at least) Not before you have clicked somewhere to try getting rid of this polygon behaviour. If you will not experiment, it hardly seems likely that you would discover anything. What have you tried to discover it? I was told in a previous mail. He is asking, 'When you were looking for this feature, what have you done to discover it?', AFAICS. OK I thought 2.2, 2.4, 2.6, were major releases. (They look like it from outside, with the new splash and so on). GIMP changes splashes quite frequently. For instance, in the 2.3 development cycle, we went through about 5 different splashes. David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp interface changes
Nathael Pajani wrote: You are making a comparison to the Linux kernel that is completely inadequate Point of view. The whole point was about stable interfaces, and saying to the users to move back to the previous version if they did not like the changes (what if kernel developers started to say you that ?), but no more arguing about this, it seems everybody missed the point. Hi, I think the point made is clear and always was, but I don't think it holds water. Changing the kernel interface in an incompatible way would typically require large amounts of code to be rewritten, while changing the GIMP user interface in incompatible ways requires no code rewrites at all. Note, again, that the GIMP _programming_ interface is carefully being kept backwards compatible for the same reason the significant parts of the kernel user space API is, but a user interface does not have the same problem of backwards compatibility. As long as it is improving, most people will be happy with the changes. And as far as I can tell from almost obsessively having sought up and read comments on and reviews of GIMP 2.6 on various sites and forums for a long time now, most people think that GIMP 2.6 was an improvement UI wise and that we are heading in the right direction. BR, Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp interface changes
David Gowers a écrit : Hello Nathael, Hi ! Nice to have a constructive answer from time to time :) 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. Hum, I think there is a misunderstanding here. So I'll use an example. First, what I call a tool menu is this: http://www.nathael.org/Data/tool_menu.jpg 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. You cannot think of creating one interface that will fit 99% of the current and future users, or you plan not to count current users that will have to switch to another program, or to create a fork (even their own one). And there is NO possible confusion, neither for the user, nor for the coder in this. 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 [...] means that there are 8,796,093,022,208 combinations of options to test already. [] I cannot agree with you here. 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 ? 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. So with these two example at hand I cannot agree at all. 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. So designing the UI first is just silly. Both have to be thought in parallel. 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. But this is free software, and those not happy with this should rather go programming commercial software ... and discover that the grand discours about planning the design is just that. 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. 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. I still do not see why more possible customization hurts. When the UI is well thought, then customization goes easy. 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
Re: [Gimp-developer] Gimp interface changes
On Mon, Mar 30, 2009 at 9:00 AM, Nathael Pajani g...@nathael.net wrote: David Gowers a écrit : Hello Nathael, Hi ! Nice to have a constructive answer from time to time :) 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. Hum, I think there is a misunderstanding here. So I'll use an example. First, what I call a tool menu is this: http://www.nathael.org/Data/tool_menu.jpg 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. You cannot think of creating one interface that will fit 99% of the current and future users, or you plan not to count current users that will have to switch to another program, or to create a fork (even their own one). And there is NO possible confusion, neither for the user, nor for the coder in this. 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 [...] means that there are 8,796,093,022,208 combinations of options to test already. [] I cannot agree with you here. 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 ? The kernel is made up of modules, which are almost entirely independent. With this, the total amount of testing needed is much reduced, because any given module has only a few options and can be tested independently. GIMP, which is an application, has a UI, and all options effect the user's perception of that UI. For the core of the program, a simplification such as is applied to the Linux kernel, is impossible; the core behaviour of the program stands as one whole thing to the user, and we test it as one whole thing. This kernel comparison just does not work. Please stop using it. 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. Gnome also is structured in many individually testable components, like the kernel, and unlike GIMP. I (and, I think, some of the core GIMP developers) would like GIMP to be structured like Linux or Gnome -- this has great advantages -- but it definitely is not where GIMP is at currently. 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. So designing the UI first is just silly. Both have to be thought in parallel. 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. But this is free software, and those not happy with this should rather go programming commercial software ... and discover that the grand discours about planning the design is just that. I don't know what to say to such a viewpoint. Of course you need to adjust your plans as you get feedback from actually implementing them -- this is what led to the current form of the free-select tool -- but the whole idea of an application is to provide capabilities to the user .. the interface should not be dependent in any way on how the
Re: [Gimp-developer] Gimp interface changes
The more I read this, the more I feel that a solution like the present in Inkscape (wich is not precisely an example of a great interface) would be a one-time solution for everyone. Just to see what I'm talking about, open a new Inkscape session, go the the right edge of the window and drag the bar to the left. There's the space that will be used to dock the dialogs. If GIMP would have something like that to dock the floating windows and toolbox, I guess most of the one-window fans will be satisfied. I can understand it's not a trivial work, but seems to be a reasonable solution that can make everyone happy. I wouldn't need more preferences options, it can behave like the current windows regarding how the windows positions are saved. I guess that would be a tad problematic when there is more than one image open, though. I'd personally stick with the floating windows just like they are now, but maybe that possibility would calm some people out there. :-) Gez ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Gimp interface changes
Hi all, Yes, a long one once again. You may be accustomed by now. But I hate being shallow-minded. As the subject changed, I think it is interresting to reflect the change in the mails subject, but this is a follow up of the Re: [Gimp-developer] Dockable Dialogs Should be Dockable Everywhere thread. Sven Neumann wrote : This whole discussion is so pointless. Partly, yes, but I hate leaving so big mistakes uncorrected. This is one of my flaws. But I'll try to put an end to the pointless parts. You are making a comparison to the Linux kernel that is completely inadequate Point of view. The whole point was about stable interfaces, and saying to the users to move back to the previous version if they did not like the changes (what if kernel developers started to say you that ?), but no more arguing about this, it seems everybody missed the point. and at the same time you did not give a single concrete example of a change that you disliked. Or even bothered to explain what you dislike about it. Some, but lost in all the other stuff or on other media (IRC) which is a mistake I made, I agree, so I'll try to be more constructive. 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.) Sorry, but the GIMP user interface sucks and that urgently needs to change. Has there been a survey about this ? We have plans to improve it and we are not going to make every change optional just to please some users that are not willing to follow us on the user interface changes. Not optional, but customizable. This is the key of free softwares (from my point of view at least) And do not tell me (or others) it is not good because other programs have too much customization possibilities. 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 them, and they'll move to commercial softwares. This is too bad. But I already said this. 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. So nice to read as an argument. 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. 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 ! One suggestion (not from me but which pleases me): have the main menu dockable, as are the tools menus. * 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. * 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
Re: [Gimp-developer] Gimp interface changes
On Sun, Mar 29, 2009 at 1:47 AM, Nathael Pajani wrote: Sorry, but the GIMP user interface sucks and that urgently needs to change. Has there been a survey about this ? http://www.mmiworks.net/eng/publications/2006/11/creating-user-scenarios-with-gimpteam.html http://gui.gimp.org/ Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp interface changes
Hello Nathael, On Sun, Mar 29, 2009 at 9:17 AM, Nathael Pajani g...@nathael.net 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 01110111000101110001011. 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.
