On Mon, Mar 30, 2009 at 9:00 AM, Nathael Pajani <g...@nathael.net> wrote:
> David Gowers a écrit :
>> Hello Nathael,
> Hi !
> Nice to have a constructive answer from time to time :)
>> Removing customizability is best. I'm not kidding. Customizability is
>> what happens when you can't figure out how to make the program behave
>> sensibly in 99% of situations. Every point of customization is also a
>> point of potential confusion, for both the coder and the user.
> Hum, I think there is a misunderstanding here. So I'll use an example.
> First, what I call a tool menu is this:
> http://www.nathael.org/Data/tool_menu.jpg
> These are dockable. And we can create as many windows as we want, with
> groups of these tabbed inside. This is customization.
> The main menu (http://www.nathael.org/Data/main_menu.jpg) should be dockable
> as well.
> You cannot think of creating one interface that will fit 99% of the current
> and future users, or you plan not to count current users that will have to
> switch to another program, or to create a fork (even their own one).
> And there is NO possible confusion, neither for the user, nor for the coder
> in this.

>> Difficulty of maintenance as hard-coded options go up is a fact, it's
>> not at all insulting. In order to achieve very reliable code, software
>> must be tested with every combination of options available. This means
>> to achieve moderate reliability, software must be tested with 50% or
>> more of the combinations of options available...
>> To show some perspective on this, you can regard each togglable option
>> in the GIMP preferences as a bit in a binary number. In SVN head, this
>> binary number is 43 bits long [...] means that there are
>> 8,796,093,022,208 combinations of options to test already.
>> [....]
> I cannot agree with you here.
> Once again, I'll use the kernel as an example here: I won't bother counting
> the number of options and the possibilities resulting, I'll just state that
> it's the
>  biggest piece of code I have ever seen, and still the most reliable.
> Are kernel programmers "superhero" ? "genius" ?
The kernel is made up of modules, which are almost entirely independent.
With this, the total amount of testing needed is much reduced, because
any given module has only a few options and can be tested
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

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

Gimp-developer mailing list

Reply via email to