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

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

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

Gimp-developer mailing list

Reply via email to