On Thu, Mar 26, 2009 at 12:52 AM, drizzt wrote:

A tool should work out of box and help getting the work done right away.

But if each time you take your tool out of the box, it's behavior has changed, you cannot use it. So maybe you are creating a thing new users can play with, but please keep in mind that there are people currently using the tool !!!

I feel justified to reply only to this one, but it basically covers all of your email. You seem to be separating users into two groups: 1) those who like GIMP the way it is now and do not want any other UI and 2) new users who don't care what the previous UI looked like. And you seem to be in the first group. Too bad, because this distinction is incorrect. There's plenty of actual GIMP users who desperately want a better UI , a lot of users who kind of don't mind a new UI and a whole lot of users who don't know yet how much they will love a new UI.

Now regarding old tool/new tool. Do you know what is one of most disgusting things in applications like ACD Canvas that are over 20 years old? It's the ugly way their developers never ever refine them. Just like you say they keep all the old tools, all the old behaviours, everything they don't feel comfortable to throw away. And it piles up. How about "A" hotkey that is in use by three (sic!) different tools depending on tool group? How about 3-level nested toolbox? How about separate erasers for bitmap and vector objects? These applications become a horror to use for both old-timers and novices.

Now please give this a lot of thought before replying.

P.S. Shouting is of no help in this list.

Alexandre

drizzt wrote:

Hi all !

This is a long post, replying to many previous posts, and adding some parts from IRC chats, and some even from discussions with Gimp developers.

Hi,

Long it was, for sure. Sorry but if you don't want the GIMP UI to evolve and change, don't upgrade to new versions.

Basic rules of interaction design applies to both open source and commercial projects. Now, open source and commercial projects can have completely different goals, and often have, but basic rules of interaction design still applies. With all due respect it to me sounds like you have not looked into interaction design at all and is just ranting based on your highly personal preferences. Looking into the world of interaction design will give you valuable insights. I recommend you to read the book "The Inmates Are Running the Asylum" by Alan Cooper. It is not a handbook on how to design interactive systems, but more of an eye-opener of what's wrong with todays products and processes as far as interaction design goes. In that book he addresses a lot of the points you are making.

BR, Martin

Martin Nordholts wrote:

world of interaction design will give you valuable insights. I recommend you to read the book "The Inmates Are Running the Asylum" by Alan Cooper. It is not a handbook on how to design interactive systems, but

I wouldn't bother. Whatever insights are contained in this book are completely clouded by the outright mistakes and predudice it containts. It is little more than a rant in itself.

Graeme Gill.

gimp-developer-bounces@lists.XCF.Berkeley.EDU wrote:

Hi all !

This is a long post, replying to many previous posts, and adding some parts from IRC chats, and some even from discussions with Gimp developers. ...

I have a degree of sympathy with this post although it seems to go to the other extreme. Backwards compatibility *is* overrated. Autotools is a great example of what happens if you don't trim the crud out of your software. No doubt, I can compile Gimp on every Unix platform ever conceived between now and 1972 but I still have to learn about 4 different languages before I can begin to start understanding how it works, let alone deciphering the scripts. Call me an idiot if you like, but it shouldn't be easier to learn the finer points of C++ than the tool that simply builds it.

On the other hand, we have KDE 4. Plenty of improvements, no doubt, but no users left to appreciate them. :)

As for customisability? I think that it's probably underestimated. Take the example of me spending half an hour or more on google this evening trying to work out how to enable menu tear-offs in Gnome. As far as I can tell, the feature just isn't there any more. Luckily for me, canvas right-click still provides the feature. I needed it, btw, because I wanted to add several guides to my project, one after the other. Rather than having to navigate all the way to that menu item every time, it's much easier to just have it available on the screen.

That's not the only use of this feature, btw. Another good use is for learning keyboard shortcuts. No need to hover the mouse over an icon for half a second; just glance at the menu.

Like I said, I don't know what's happened to this (really nice) feature but I did find a clue in some Java/GTK SDK documentation which states that usability studies have concluded that menu tear-offs are a bad idea and should be avoided. Oh dear, I thought. Someone's been conducting usability studies.

Not that I have anything particularly against UI studies, but the method had better be sound, the assumptions had better be correct, and the results had better be applied appropriately. If the conclusion comes as a surprise, re-examine the experiment...carefully.

Anyway, getting back to the Gimp, I'd be willing to bet real money that whatever ideas you have about a typical Gimp user are probably wrong. By all means, design for whatever you think the common use case is likely to be but remember that Gimp is (to borrow a programming term) a low-level IMP. That makes it even more likely that usage patterns from one user to the next will be radically different. If you don't enable Gimp's users to do the things that you can't think of, you'll just have non-plussed Gimpers. If you take away those things? Well, good luck with all the hate. :)

---AV & Spam Filtering by M+Guardian - Risk Free Email (TM)---

On Fri, Mar 27, 2009 at 5:13 AM, David Marrs wrote:

As for customisability?  I think that it's probably underestimated. Take the example of me spending half an hour or more on google this evening trying to work out how to enable menu tear-offs in Gnome.  As far as I can tell, the feature just isn't there any more

gconf-editor, /desktop/gnome/interface/menus_have_tearoff

And it's on 1st page of google searhc result for "gtkrc tear-off" for me

Alexandre

Hi,

On Wed, 2009-03-25 at 14:52 -0700, drizzt wrote:

Just think of the most used piece of code on a GNU/Linux system: the Linux kernel. Didn't you know that the user interface is stable ? How would you feel if between releases the behavior of interfaces changed, and when asking the kernel developers you were told "just keep using the old kernel you used to".

Obviously you have no idea of what you are talking about here. The Linux kernel APIs are changing faster than anything else in the software world. If you had ever maintained a device driver outside the main kernel tree, you wouldn't have chosen the Linux kernel as an example of something that doesn't change its interface between releases. GIMP is very conservative compared to the Linux kernel. Our plug-in API has not seen an incompatible change for five years now.

You also probably do not realize how much work an optional change is. Every option that is added doubles the complexity of the code. It is already impossible for us to test all possible configurations that GIMP offers. If we tried to make major interface changes optional, the code would become completely unmaintainable very soon.

Sven

Alexandre wrote:

On Fri, Mar 27, 2009 at 5:13 AM, David Marrs wrote:

As for customisability? I think that it's probably underestimated. Take the example of me spending half an hour or more on google this evening trying to work out how to enable menu tear-offs in Gnome. As far as I can tell, the feature just isn't there any more

gconf-editor, /desktop/gnome/interface/menus_have_tearoff

And it's on 1st page of google searhc result for "gtkrc tear-off" for me

Did you test that? Because it doesn't work for me.

---AV & Spam Filtering by M+Guardian - Risk Free Email (TM)---

On Fri, Mar 27, 2009 at 08:02:13PM +0100, Sven Neumann wrote:

Hi,

On Wed, 2009-03-25 at 14:52 -0700, drizzt wrote:

Just think of the most used piece of code on a GNU/Linux system: the Linux kernel. Didn't you know that the user interface is stable ? How would you feel if between releases the behavior of interfaces changed, and when asking the kernel developers you were told "just keep using the old kernel you used to".

Obviously you have no idea of what you are talking about here. The Linux kernel APIs are changing faster than anything else in the software world. If you had ever maintained a device driver outside the main kernel tree, you wouldn't have chosen the Linux kernel as an example of something that doesn't change its interface between releases. GIMP is very conservative compared to the Linux kernel. Our plug-in API has not seen an incompatible change for five years now.

Still that narrow minded? You obviously didn't read the drizzt's post at all! Drizzt was comparing the linux kernel _user_ interface with the gimp's _user_ interface. As a matter of fact, I personnaly know drizzt and an I can assure you he really knows what he is talking about regarding kernel developping as he does exactly that for a living.

You also probably do not realize how much work an optional change is. Every option that is added doubles the complexity of the code. It is already impossible for us to test all possible configurations that GIMP offers. If we tried to make major interface changes optional, the code would become completely unmaintainable very soon.

Well, of course, everything could be better if more people would be even allowed to work on gimp. But I guess this won't happen since even confirmed former contributors aren't even allowed to commit trivial patches without having to explain many times what these patches do, and pass many many controls. You did everything to discourage people to contribute, so now, please, don't tell people you need ressources to maintain the whole mess.

Cheers,

DindinX

Hi,

On Fri, 2009-03-27 at 20:29 +0100, David Odin wrote:

Still that narrow minded? You obviously didn't read the drizzt's post at all! Drizzt was comparing the linux kernel _user_ interface with the gimp's _user_ interface.

As far as I know the kernel doesn't have a user interface in the sense the term is used for a graphical user application such as GIMP. It does provide a lot of interfaces to device drivers and to the higher levels of the operating system though. And these interfaces are changing quite frequently.

Perhaps this was a misunderstanding. I don't really understand the purpose of the Linux kernel example.

Well, of course, everything could be better if more people would be even allowed to work on gimp. But I guess this won't happen since even confirmed former contributors aren't even allowed to commit trivial patches without having to explain many times what these patches do, and pass many many controls.

No idea what you are referring to here. Can you explain to me what you are talking about? Of course there is a patch review process. It would be insane not to have one. But we are trying hard to review patches very fast. Did you really have to wait an unreasonable time to have your patches reviewed?

Sven

On Fri, Mar 27, 2009 at 08:51:10PM +0100, Sven Neumann wrote:

Hi,

On Fri, 2009-03-27 at 20:29 +0100, David Odin wrote:

Still that narrow minded? You obviously didn't read the drizzt's post at all! Drizzt was comparing the linux kernel _user_ interface with the gimp's _user_ interface.

As far as I know the kernel doesn't have a user interface in the sense the term is used for a graphical user application such as GIMP. It does provide a lot of interfaces to device drivers and to the higher levels of the operating system though. And these interfaces are changing quite frequently.

I won't say that the syscalls or the /proc interfaces are changing that frequently. And when they change, the older behaviour is still available as an option. A device driver isn't really a user of the kernel, but a part of it. Whatever.

Perhaps this was a misunderstanding. I don't really understand the purpose of the Linux kernel example.

Well, of course, everything could be better if more people would be even allowed to work on gimp. But I guess this won't happen since even confirmed former contributors aren't even allowed to commit trivial patches without having to explain many times what these patches do, and pass many many controls.

No idea what you are referring to here. Can you explain to me what you are talking about? Of course there is a patch review process. It would be insane not to have one. But we are trying hard to review patches very fast. Did you really have to wait an unreasonable time to have your patches reviewed?

No. I won't explain all that once more since having to explain the same thing over and over instead of doing the real work is precisely why I have quit the gimp development. And it is also why the gimp development is so slow.

I now prefer to give my time to some more attractive projects. I'm still a gimp user, though and I'm very desapointed to see which directions it takes. At least, I'm still able to maintain my own private tree when I want a special feature that won't get in because it would just take years to explain to every one why it is useful to me.

David Odin wrote:

Drizzt was comparing the linux kernel _user_ interface with the gimp's _user_ interface.

Comparing a kernel "user interface" with an image editor user interface is just plain silly.

[...]

Well, of course, everything could be better if more people would be even allowed to work on gimp. But I guess this won't happen since even confirmed former contributors aren't even allowed to commit trivial patches without having to explain many times what these patches do, and pass many many controls. You did everything to discourage people to contribute, so now, please, don't tell people you need ressources to maintain the whole mess.

I can't let you attack Sven like this without commenting on it. If you are talking about the patch I think you are talking about it was not a trivial patch. And there is nothing wrong with requiring changes to be of high quality.

Getting commit access in open source projects is all about trust and the way you are acting is not very strategic if you want to regain trust to commit non-trivial stuff. But then that is of course not what you want. You announced a few months back that you officially quit the GIMP project. All you want to do is taking some kind of revenge by talking shit about Sven. It is pathetic.

- Martin

Once again, I reply to many posts, and with a long message, but it seems that people are interested in the discussion, so I wont deceive them.

Martin Nordholts a écrit :

Comparing a kernel "user interface" with an image editor user interface is just plain silly.

I don't think so, but maybe some people have difficulties seeing the parallel, so read ahead please.

Sven Neumann a écrit :

Hi,

On Fri, 2009-03-27 at 20:29 +0100, David Odin wrote:

Still that narrow minded? You obviously didn't read the drizzt's post at all! Drizzt was comparing the linux kernel _user_ interface with the gimp's _user_ interface.

As far as I know the kernel doesn't have a user interface in the sense the term is used for a graphical user application such as GIMP.

So for you a user interface is a GUI ?

It does
provide a lot of interfaces to device drivers and to the higher levels of the operating system though. And these interfaces are changing quite frequently.

I feel like there's a need for some technical information in here.

Have you ever heard of kernel space and user space ? The linux kernel code, and all module code, is running in "kernel space", while all the remaining parts are in "user space".

On a linux system, you can take any 2.6 kernel, and still have your system up and running. Even using a 2.4 kernel will be possible, with only a few changes to some administrative tools (modutils and the like).

Why ?

Because the USER interface is stable. So much that when there is a need for a change, kernel programmers don't do it, they find another way, whatever it costs.

The kernel internals are moving, and a lot, but this the user don't care about. you can rewrite gimp every day if you want, nobody (or no user at least) will care, if the user interface is stable.

Perhaps this was a misunderstanding. I don't really understand the purpose of the Linux kernel example.

It is an example I used on IRC when someone told me to use the old GIMP version if I did not like the new one.
And chosed because everybody is using new kernels because of the improvements and the new drivers, which are added but still using the same user interface.

If you cannot see the parallel, sorry.

Then from your previous email:

Obviously you have no idea of what you are talking about here.

From what you say, I would say I have much more idea than you have.

The Linux
kernel APIs are changing faster than anything else in the software world. If you had ever maintained a device driver outside the main kernel tree, you wouldn't have chosen the Linux kernel as an example of something that doesn't change its interface between releases.

I would say only one thing: Why bother !!! Commit your driver to the kernel, and you'll have no more to do out of the tree !!! Keeping drivers out of the tree is nonsense.

GIMP is
very conservative compared to the Linux kernel. Our plug-in API has not seen an incompatible change for five years now.

So the few developpers have nothing to do, but users have to learn the tool once again after every release ?
Am I the only one feeling that there's a problem in this point of view ?

You also probably do not realize how much work an optional change is. Every option that is added doubles the complexity of the code. It is already impossible for us to test all possible configurations that GIMP offers. If we tried to make major interface changes optional, the code would become completely unmaintainable very soon.

No.
Not at all.
As I said, being a free software, The GIMP project may have some of the best programmers at hand.
Once again, there are more options in the kernel than you can think about, and the code is maintained, maintainable, and often tested. If it's done correctly and early, everything can be tested using test tools. Once again you are saying implicitly that GIMP developers are newbies. Please don't. And making major changes is not required if you spent more time thinking. For example, for the menu, making it dockable with it's docking position being a saved configuration setting, would prevent an option. And it's already done for dialogs, so it's not more work, it should even be less work.

Hi,

On Fri, 2009-03-27 at 21:38 +0100, drizzt wrote:

The kernel internals are moving, and a lot, but this the user don't care about. you can rewrite gimp every day if you want, nobody (or no user at least) will care, if the user interface is stable.

Sorry, but the GIMP user interface sucks and that urgently needs to change. 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. And we are going to make some much more drastic changes in the future.

Whenever we do a change we try to be very careful so that we don't break existing work-flows. Sometimes we fail at this and introduce a regression for certain use cases we did not consider. Usually when this happens, we are perfectly willing to make further changes to fix this.

This whole discussion is so pointless. You are making a comparison to the Linux kernel that is completely inadequate 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. 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.

Sven

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 this but saying "don't do it". Once again, for your own convenience you are having so many people loosing so much time.
And then, on the same point, you create a new menu entry called "create" but the "New image" is still outside of it ! This can be between 2 minor versions, but when you say you are redesigning the user interface, don't do it across major releases.

Thanks for reading down to here. And once again, have fun and enjoy using free software, this is the most important.

And please remember the 2006 GimpCon (quotes from the website : http://developer.gimp.org/gimpcon/2006/index.html)

Targeted user base GIMP targets experienced users. If we acknowledge that GIMP is not (primarily) for beginners [...]

What GIMP is: * GIMP is Free Software
* GIMP is a high-end photo manipulation application, and supports creating original art from images;
* GIMP is a high-end application for producing icons, graphical elements of web pages, and art for user interface elements; * GIMP is a platform for programming cutting edge image processing algorithms, by scientists and artists;
* GIMP is user-configurable to automate repetitive tasks; * GIMP is easily user-extendable, by easy installation of plug-ins.

What GIMP is not: * GIMP is not MS Paint or Adobe Photoshop

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

Hello Nathael,

On Sun, Mar 29, 2009 at 9:17 AM, Nathael Pajani 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

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

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 actual merit, not their secondary effects.

Right, I can only agree here.
But then I do not see the merit behind having an empty window when you start gimp, with most menu being empty.

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.

11 or 12 of March, in the evening, on #gimp on irc.freenode.net Someone may have the logs. I was drizzt.

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.

Very good example: OSX dock is customizable, you can change the icons in it !!! imagine a dock in wich you cannot change the icons displayed ... As any display/window manager, you can also change your desktop background. One more customization.

People like things to be customizable. You will not be able to prove the contrary.

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?

Nothing, so why not use it more intensively ?

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.

??? This is a new thing, I do not understand when or what it saved for you then.

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

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)

See previous "definition", what I call tool menus seems to be the "other things that can dock to it"

* 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 ? Nice to know anyhow. I don't mind having to press enter to finish, but I cannot 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.

I do think we would benefit from an option to automatically close the shape; I don't like pressing Enter.

Yep, I agree here, but you were the one telling there are too many options :) BUt this would be a nice option for the lasso tool :)

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.

Wouldn't "Escape" be a good choice? but then, it's only a replacement of the Ctrl+Shift+A shortcut.
And shortcuts are already customizable. I hope you do not plan to remove this feature !!!!

* 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

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.

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?

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.
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 ?

> 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. Reduced to those having time to do significant things to the community it will be very small !!!
And then, didn't it occur to you that those developing for other projects have no time for the Gimp project ? But mind, you are using their tools (the Linux kernel for example, or gcc, or any other one) How would you feel if they started saying "we don't care about those not contributing. Will you contribute to all the projects you are using?

Have fun And thanks once again for reading down to here.

Nathael Pajani, alias drizzt.

On Mon, Mar 30, 2009 at 9:00 AM, Nathael Pajani 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 feature is actually implemented, just that the way it's implemented should be reasonably straightforward and plain.

The UI actually is the main part of an Image manipulation program; at least, it's the main part of GIMP. 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.

Dealing with users is a far more complex undertaking than almost any backend task you can think of.

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.

Who do you think compiled that list? AFAIK, it's Peter Sikking, the same guy who has researched on and written a lot (all?) of the specs on gui.gimp.org

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.

We may be talking about different things here; things like docking dialogs is not a customization problem -- it's not a special switch like some things in GIMP preferences are, just a structural arrangement for the components already provided; it can be dealt with in a single place in the code, unlike a global option.

People like things to be customizable. You will not be able to prove the contrary.

What people like, and what actually works well for them, are two different things.
This is a common problem in UI, especially in open source software -- people want things that effectively reduce their ability to use the program well.
It's just like, I find some smokers inexplicably attractive, but it would be foolish of me to try to 'hook up' with such a person, as I'm very careful about my health. People want irrational things sometimes, and we should not accommodate their poor habits of thinking and acting in these cases.

So we do not provide such customizations; we only provide customization within what we have worked out to be feasible limits.

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?

Nothing, so why not use it more intensively ?

You said it would be a good improvement, implying that there is something to improve.
If nothing is stopping this, how can it be an improvement? I do not understand that.

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.

??? This is a new thing, I do not understand when or what it saved for you then.

It's not a very new thing. I always compile the latest development version myself, and have been using this feature for many months now.

In particular, some keyboard-shortcuts could only be used in the toolbox. This is no longer the case, so keyboard shortcuts behave more consistently now.
This used to bother me quite a lot, where I would hit a key, and because the toolbox had focus rather than the image window, the keyboard shortcut would not be recognized.

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

Again, that is not a menubar; it's a place to drop images.

See previous "definition", what I call tool menus seems to be the "other things that can dock to it"

I don't understand what you mean here at all, sorry.

* 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 ?

It gives a message in the statusbar

'return commits, escape cancels, backspace removes last segment' When you have drawn >= 2 points in a polygon or a >= 2 freehand segments.

Nice to know anyhow. I don't mind having to press enter to finish, but I cannot 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.

Maybe this is only in development versions (2.7) so far. But it is there.

It also matches with the behaviour of rectangle and ellipse tool (ENTER confirms the selection)

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.

Wouldn't "Escape" be a good choice? but then, it's only a replacement of the Ctrl+Shift+A shortcut.

Escape is already used, as noted above.

And shortcuts are already customizable. I hope you do not plan to remove this feature !!!!

I have no idea what you're talking about. The keys that a tool depends on internally are hard-coded, and have never been effected by the configurable shortcuts.

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.

I can only suggest you review the UI spec for this change.

Also, if you are taking screenshots much of the time, it might be sensible to either assign a keyboard shortcut to it, or use a separate screenshot taking program.

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?

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.

Well, this is not applicable here. Even-numbered major releases (2.0, 2.2, 2.4, 2.6, 2.8, 3.0) are stable series, meaning after the first release in the series is made, only bugfixes are added. For example, 2.6.1 is the first set of bug-fixes in release series 2.6.

We can only do significant redesign in the development versions (2.1.x, 2.3.x, 2.5.x, 2.7.x, 2.9.x).

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 ?

I agree, but I don't think it's applicable to GIMP. You can only afford to act based on such an idea, if you have many active developers or a very small code-base; GIMP has neither, so we must work at things piece by piece.

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.

Reduced to those having time to do significant things to the community it will be very small !!!

There's lots of ways to contribute to the community; for example an artist who shows off their artworks with a note 'made with GIMP' and a link to the GIMP website, is contributing to the GIMP community, helping to get new people into the world of GIMP. Or someone who writes an article, 'I like GIMP because..', or someone who writes a tutorial for doing some particular thing in GIMP. However it's a sure thing, if you have not the patience to spend some time doing things in the community, then you will not contribute anything significant to it, and in fact, you will not BE anything significant to it; Hence, we should not assign importance to transient users.

If we are attracting users who are then later repelled from GIMP by the behaviour of the same version they first used, then *that* is a serious problem; and we are addressing such problems through the UI redesign.

David

Hello!

On Mon, Mar 30, 2009 at 00:30, Nathael Pajani 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

Hi all!

Tobias Jakobs wrote :

On Mon, Mar 30, 2009 at 00:30, Nathael Pajani 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 having you loosing too much time on these emails.

> 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.
> 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.

Tobias Jakobs wrote :

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.

OK, but then I do not understand why the toolbox being the main window prevents the menu from becoming dockable.

* 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.

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.

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?

I was told in a previous mail.

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.

Yes, you're 100% right, and these info are often good ones, even if in this case they are not complete and, in the french translation, not even accurate.

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 ?
Gimp will become GNOME dependent ?

(And the Apple HIG)

Apple dependent ?

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 for API compatible releases.

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).

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.

You mean a major release ?
But still, being a debian user, I like their ways (Or am I a Debian user because I like their ways ?) and think that it should be so for all free software. What need to have new versions if they are "ongoing job" ?

Nathael Pajani (gimp@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.

Bye, Simon

On Tue, Mar 31, 2009 at 8:25 AM, Nathael Pajani 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