Would single-window fix usability nightmares?

[Ilya Zakharevich]

          [Repost after a list resurrection]

I've read through the discussion of (a possibility of) a single-window
GIMP interface.  Both on the mailing list, and on
  http://www.mmiworks.net/eng/publications/2009/09/gimp-single-mode.html

However, I do not see how much this would affect the (AFAIK) main
complaint about multi-window GIMP: that having several windows with
several possibilities of what is focused requires many extraneous
mouse clicks and/or keypresses.

When the windows are merged into one, STILL only one of subwindows has
a focus?  So how does this improves the current nightmares (e.g.,
keyboard shortcuts not working - especially when most needed ;-)?

  [Myself, I do not use PhotoShop, but what I saw is people who use
   both PS and GIMP say that PS allows about 3x times quickier UI
   interaction - in large respect due to no need to "fix mis-focus".]

       I mean here the [rare?] cases when GIMP caught up with
       particular features of PS, so one can compare not feature sets,
       but how convenient is it to perform the operations...

And if a solution to this problem is found, why would not it "work"
with multi-window interface too?

Or is the improvement ONLY in the fact that utility windows will never
obscure the image?

=======================================================

BTW, if one considers single-window interface as "just a fix for UI
interaction slowness", I see no problem with editing multiple files:
just have a "single-window interface" open for each of them.

If this turns out to be important: to make things take less screen
space, one could allow utility docks to "shrink" on unfocussed
windows...

Yours,
Ilya

_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Alexandre Prokoudine]

On Fri, Oct 2, 2009 at 10:25 AM, Ilya Zakharevich wrote:

> a focus?  So how does this improves the current nightmares (e.g.,
> keyboard shortcuts not working - especially when most needed ;-)?

Lemme guess - you are on WIndows? :)

Alexandre
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[peter sikking]

Ilya Zakharevich wrote:

> However, I do not see how much this would affect the (AFAIK) main
> complaint about multi-window GIMP: that having several windows with
> several possibilities of what is focused requires many extraneous
> mouse clicks and/or keypresses.

the introduction of a single window mode is in no way related to that.

> When the windows are merged into one, STILL only one of subwindows has
> a focus?  So how does this improves the current nightmares (e.g.,
> keyboard shortcuts not working - especially when most needed ;-)?

that is a serious bug.

in what version(s) of GIMP does this happen?

     --ps

         founder + principal interaction architect
             man + machine interface works

         http://mmiworks.net/blog : on interaction architecture





_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Ilya Zakharevich]

On 2009-10-02, peter sikking <peter@...> wrote:
>> However, I do not see how much this would affect the (AFAIK) main
>> complaint about multi-window GIMP: that having several windows with
>> several possibilities of what is focused requires many extraneous
>> mouse clicks and/or keypresses.

> the introduction of a single window mode is in no way related to that.

Good to know; so let me refine: is there ANYTHING in the move to
single window which would not be achieved by

  a) restricting the maximal size of image window to the gap between
     two toolboxes; and

  b) making z-order changes syncronized between the main window and
     toolboxes?

(I mean: whenever z-order of main GIMP window changes *wrt non-GIMP
windows*, the z-order of "dependent" windows changes accordingly.
Same for toolboxes: similar changes in THEIR z-order should be
reflected in the z-order of the "current" image window)

>> When the windows are merged into one, STILL only one of subwindows has
>> a focus?  So how does this improves the current nightmares (e.g.,
>> keyboard shortcuts not working - especially when most needed ;-)?
>
> that is a serious bug.
>
> in what version(s) of GIMP does this happen?

2.6.6.  Tested on Windows.  Examples:

a) Press TAB (toolboxes disappear);
   Press TAB (toolboxes  reappear, focus on "Layers");
   Press TAB - now you navigate "Layers" toolbox.

b) Focus to Layers.  Press F11.  Nothing.  Press o.  Nothing.  Press 4
   (user configured to "1:4 zoom").  Nothing.

Thanks,
Ilya


_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Tor Lillqvist]

> 2.6.6.  Tested on Windows.

As has been said before, one should not think that the way GIMP's
windows behave on Windows is how they are supposed to behave. There
are bugs in GTK+ on Windows that affect GIMP.

It is pointless to describe the misbehaviour of GIMP windows on
Windows to GIMP developers, as they don't use Windows themselves.

To see GIMP behave as it is supposed to, you need to use it on Linux.
The reference window manager is metacity, as far as I know, but also
other window managers might work well enough.

--tml
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Ilya Zakharevich]

On 2009-10-21, Tor Lillqvist <tml@...> wrote:
> It is pointless to describe the misbehaviour of GIMP windows on
> Windows to GIMP developers, as they don't use Windows themselves.

Let me restate it:

  it is pointless to fix bugs/problems on windows, since they do not
  happen (and if they happen, developers do not want to see reports).

Are you sure that the situation is as you describe it?

> To see GIMP behave as it is supposed to, you need to use it on Linux.
> The reference window manager is metacity, as far as I know, but also
> other window managers might work well enough.

Sorry, but I find this attitude as misplaced as one in the previous
paragraph...

Yours,
Ilya

_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[David Gowers]

On Wed, Oct 21, 2009 at 1:42 PM, Ilya Zakharevich
<nospam-abuse@...> wrote:
> On 2009-10-21, Tor Lillqvist <tml@...> wrote:
>> It is pointless to describe the misbehaviour of GIMP windows on
>> Windows to GIMP developers, as they don't use Windows themselves.
>
> Let me restate it:
>
>  it is pointless to fix bugs/problems on windows, since they do not
>  happen (and if they happen, developers do not want to see reports).

No, it means the bugs are in GTK+, not GIMP, and it requires GTK+
developers who run Windows to fix these bugs (or a GIMP developer who
runs Windows and has some knowledge of GTK+ and an inclination to fix
these bugs). Do you seriously think a person running Linux is going to
be able to reliably fix a bug that only shows up on Windows?

>
> Are you sure that the situation is as you describe it?
>
>> To see GIMP behave as it is supposed to, you need to use it on Linux.
>> The reference window manager is metacity, as far as I know, but also
>> other window managers might work well enough.
>
> Sorry, but I find this attitude as misplaced as one in the previous
> paragraph...

Your expectations that GIMP will exert such extreme control over the
window management are also unreasonable. Your window manager manages
your windows, GTK+ communicates to the window manager what window
behaviour GIMP is asking for, GIMP communicates to GTK+ what window
behaviour it wants. The particular 'communications breakdown' is
between GTK+ and the Windows window manager, GIMP is not involved in
the problem, only a casualty of it.
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[David Gowers]

On Wed, Oct 21, 2009 at 11:22 AM, Ilya Zakharevich
<nospam-abuse@...> wrote:

> On 2009-10-02, peter sikking <peter@...> wrote:
>>> However, I do not see how much this would affect the (AFAIK) main
>>> complaint about multi-window GIMP: that having several windows with
>>> several possibilities of what is focused requires many extraneous
>>> mouse clicks and/or keypresses.
>
>> the introduction of a single window mode is in no way related to that.
>
> Good to know; so let me refine: is there ANYTHING in the move to
> single window which would not be achieved by
>
>  a) restricting the maximal size of image window to the gap between
>     two toolboxes; and
>
>  b) making z-order changes syncronized between the main window and
>     toolboxes?
>
> (I mean: whenever z-order of main GIMP window changes *wrt non-GIMP
> windows*, the z-order of "dependent" windows changes accordingly.
> Same for toolboxes: similar changes in THEIR z-order should be
> reflected in the z-order of the "current" image window)
>
>>> When the windows are merged into one, STILL only one of subwindows has
>>> a focus?  So how does this improves the current nightmares (e.g.,
>>> keyboard shortcuts not working - especially when most needed ;-)?
>>
>> that is a serious bug.
>>
>> in what version(s) of GIMP does this happen?
>
> 2.6.6.  Tested on Windows.  Examples:
>
> a) Press TAB (toolboxes disappear);
>   Press TAB (toolboxes  reappear, focus on "Layers");
>   Press TAB - now you navigate "Layers" toolbox.

I can reproduce this very annoying behaviour. I have to refocus the
image window in order to get TAB to work again, and basically gave up
on using TAB at all. Platform: Arch Linux (i686), GTK 2.16.5, Window
Manager: AwesomeWM 3.3

I believe my WM always focuses the newly shown window, which may
reflect on this behaviour.

>
> b) Focus to Layers.  Press F11.  Nothing.  Press o.  Nothing.  Press 4
>   (user configured to "1:4 zoom").  Nothing.

I can't reproduce this; all keyboard shortcuts work as expected,
except where they conflict (for example, when a text-entry field like
palette or color name is in focus, you have to be able to type o as an
ordinary letter). May be Windows-only.
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Alexandre Prokoudine]

On Wed, Oct 21, 2009 at 4:52 AM, Ilya Zakharevich wrote:

> Good to know; so let me refine: is there ANYTHING in the move to
> single window which would not be achieved by
>
>  a) restricting the maximal size of image window to the gap between
>     two toolboxes; and
>
>  b) making z-order changes syncronized between the main window and
>     toolboxes?

As mentioned before, synchronized panning in tiled image windows, for instance.

Alexandre
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Ilya Zakharevich]

On 2009-10-21, David Gowers <00ai99@...> wrote:

>>  it is pointless to fix bugs/problems on windows, since they do not
>>  happen (and if they happen, developers do not want to see reports).

> No, it means the bugs are in GTK+, not GIMP,

It was "GIMP's decision" to use GTK+, so any bug in GTK is
automatically a bug in GIMP - and a responsibility of GIMP maintainers.

> and it requires GTK+ developers who run Windows to fix these bugs
> (or a GIMP developer who runs Windows and has some knowledge of GTK+
> and an inclination to fix these bugs). Do you seriously think a
> person running Linux is going to be able to reliably fix a bug that
> only shows up on Windows?

Now you know that your question was very misdirected, right?  [Judging
by your other post.]

> Your expectations that GIMP will exert such extreme control over the
> window management are also unreasonable.

No.  Expectations of a user that things work the way they are
documented are NEVER unreasonable.  They may be
unconvenient/embarassing to developers, but this is a different topic...

> Your window manager manages your windows, GTK+ communicates to the
> window manager what window behaviour GIMP is asking for, GIMP
> communicates to GTK+ what window behaviour it wants.

You write as if I care how things are implemented (and as if I do not
know this ;-).

> The particular 'communications breakdown' is between GTK+ and the
> Windows window manager, GIMP is not involved in the problem, only a
> casualty of it.

Wrong.  And even if it were true, the problem is *with GIMP*, not with
some intermediaries.  WMs differ; this is a fact of life.  When
developers hide their heads in sand ("it just works with my WM"), it
is nothing to be proud of...

Ilya

_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Ilya Zakharevich]

On 2009-10-21, Alexandre Prokoudine <alexandre.prokoudine@...> wrote:
>> Good to know; so let me refine: is there ANYTHING in the move to
>> single window which would not be achieved by

>>  a) restricting the maximal size of image window to the gap between
>>     two toolboxes; and

>>  b) making z-order changes syncronized between the main window and
>>     toolboxes?

> As mentioned before, synchronized panning in tiled image windows, for instance.

Great!  So "ANYTHING"-question is answered.  How about a complete
list?  ;-)

Thanks,
Ilya

_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Tor Lillqvist]

> It was "GIMP's decision" to use GTK+,

Well, d'oh! I wonder if you know what the "G" in GTK+ means?

Yeah, they should have stayed with Motif, would have prevented the
port to Windows and all the clueless whining that causes.

--tml
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Alexandre Prokoudine]

On Wed, Oct 21, 2009 at 12:14 PM, Ilya Zakharevich wrote:

> It was "GIMP's decision" to use GTK+

You made my day :)

>> The particular 'communications breakdown' is between GTK+ and the
>> Windows window manager, GIMP is not involved in the problem, only a
>> casualty of it.
>
> Wrong.  And even if it were true, the problem is *with GIMP*,

If a particular system service in Windows gets broken and some apps
don't work as expected, would it be their developers fault? :)

I can see how a John Do can blame GIMP for GTK+ issues, but I don't
see why GIMP developers should bother about John Do's misconceptions
about software development.

Alexandre
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

On Wednesday 21 October 2009, Ilya Zakharevich wrote:
> Good to know; so let me refine: is there ANYTHING in the move to
> single window which would not be achieved by
>
>   a) restricting the maximal size of image window to the gap between
>      two toolboxes; and
>
>   b) making z-order changes syncronized between the main window and
>      toolboxes?
>
IMHO the move to a single image window with dockables would solve quite a lot of interoperability problems. For example there are plenty of broken window managers out there. Relying on them (WM developers) getting it right in the end for the GIMP is proving to be a long wait. As desktop environments go the window managers that work with the GIMP as intended tend OTOH to be the ones that don't play well with KDE for example (if you even have the choice, which you haven't really in KDE4). Oh and windows is a beast that isn't handled easily as well - the window manager there sucks at managing applications that consist of multiple single windows that don't have a proper native inheritance structure - which places the problem either into the GTK+ ballpark (a vital library once created to suit GIMP but which now is driven by people with their own development goals which don't necessarily match the GIMP requirements any longer) or forces the GIMP developers to avoid this area in the long run.
Besides that there are things like split layer views that I'd like to see - for example editing a layer mask side by side the image area it belongs to which IMHO are next to impossible with the current multi window arrangement.
--
mfg
Karl Günter
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Tor Lillqvist]

> Let me restate it:
>
>  it is pointless to fix bugs/problems on windows, since they do not
>  happen (and if they happen, developers do not want to see reports).

No, not at all. Bug reports (in the proper place, i.e.
bugzilla.gnome.org) are always welcome, especially if they describe
specific error scenarios, that have not been reported earlier, that
can be easily reproduced even with some relatively simple app like
gtk-demo without requiring running a complex one like GIMP.

Sure, I certainly am well aware that the maintainers of GTK+ on
Windows (i.e. myself and a couple of others, in our "copious spare
time") are not as responsive to bug reports as some users seem to
expect. That doesn't mean we would ignore the reports, though.

> Are you sure that the situation is as you describe it?

You mean when I said "It is pointless to describe the misbehaviour of
GIMP windows on Windows to GIMP developers, as they don't use Windows
themselves." ?

That depends on who is counted as a GIMP developer, but at least
currently, the people who understand GIMP best and actively work on
GIMP don't use Windows. (This means something like two to four people,
in their spare time, in case you have the unfortunate common
misconception that there would be a large number of GIMP developers.)

Personally I do use Windows, and I am to some extent a (or even "the")
maintainer of GTK+ and GLib on Windows, but currently I am sorry to
say that I don't really have the resources or inspiration to work much
on GIMP. I would love to, in principle.

> Sorry, but I find this attitude as misplaced as one in the previous
> paragraph...

I am just stating what I see being the factual situation. It's not a
question of "attitude". You mean the (de-facto active) GIMP developers
have "an attitude" when they don't bother to use Windows?

--tml
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[yahvuu]

Hi all,

Alexandre Prokoudine wrote:
> I can see how a John Do can blame GIMP for GTK+ issues, but I don't
> see why GIMP developers should bother about John Do's misconceptions
> about software development.

perhaps the Windows version should wear a 'beta port of GTK+'
disclaimer as a nag-screen. Seriously. The most annoying buggy
software is buggy software which you expected to work flawlessly.

As Ilya points out, it's legitimate that users blame the GIMP project.
So i think a warning upfront can reduce the frustration, and
also communicate the responsibilities a bit.


regards,
yahvuu


_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Ilya Zakharevich]

On 2009-10-21, Alexandre Prokoudine <alexandre.prokoudine@...> wrote:
>>> The particular 'communications breakdown' is between GTK+ and the
>>> Windows window manager, GIMP is not involved in the problem, only a
>>> casualty of it.

>> Wrong.  And even if it were true, the problem is *with GIMP*,

> If a particular system service in Windows gets broken and some apps
> don't work as expected, would it be their developers fault? :)

If they fix the defect - yes, of course.  If not - of course it is
their developers fault.  Why do you ask, is not the answer obvious
("most obvious" if the problem happens on ALL windows systems)?

The situation with free software is *slightly* more delicate.  But
"only slightly"; remember what fox explained to the little prince...

> I can see how a John Do can blame GIMP for GTK+ issues, but I don't
> see why GIMP developers should bother about John Do's misconceptions
> about software development.

These are not misconceptions.  Software does not modularize; at least
not in the sense of dilution of responsibility.  If you use a library,
its bugs BUG YOU.

Ilya

_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Alexia Death-2]

On Thu, Oct 22, 2009 at 12:54 AM, Ilya Zakharevich
<nospam-abuse@...> wrote:
>> I can see how a John Do can blame GIMP for GTK+ issues, but I don't
>> see why GIMP developers should bother about John Do's misconceptions
>> about software development.
>
> These are not misconceptions.  Software does not modularize; at least
> not in the sense of dilution of responsibility.  If you use a library,
> its bugs BUG YOU.

I think that it is one of the STRENGTHS of FOSS that if there's a bug
in a component users of that component do not try to hack round it,
but expect the bug to be fixed at the source benefiting everyone.

I'm sorry to say this, but your attitude is starting to piss me off.
Your attack mentality and complaining are not helping. Perhaps you
should stop that and do something that would actually help, like
contribute some code.

We work on gimp for FUN. Most of us do not use Windows(I don't have
one for my personal use) and those that do are not skilled enough to
do GTK development on that platform. We do what we can. I personally
got involved in the project by hunting a bug that ended up being in
GTK. It got fixed. True, the bug was specific for Linux, but that's
the platform I do my development on. I done have neither the will nor
skills to do that. You can do it on windows if you want.

--
--Alexia
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[David Gowers]

On Thu, Oct 22, 2009 at 5:14 PM, Alexia Death <alexiadeath@...> wrote:

> On Thu, Oct 22, 2009 at 12:54 AM, Ilya Zakharevich
> <nospam-abuse@...> wrote:
>>> I can see how a John Do can blame GIMP for GTK+ issues, but I don't
>>> see why GIMP developers should bother about John Do's misconceptions
>>> about software development.
>>
>> These are not misconceptions.  Software does not modularize; at least
>> not in the sense of dilution of responsibility.  If you use a library,
>> its bugs BUG YOU.
>
> I think that it is one of the STRENGTHS of FOSS that if there's a bug
> in a component users of that component do not try to hack round it,
> but expect the bug to be fixed at the source benefiting everyone.
>
> I'm sorry to say this, but your attitude is starting to piss me off.
> Your attack mentality and complaining are not helping. Perhaps you
> should stop that and do something that would actually help, like
> contribute some code.
>
> We work on gimp for FUN. Most of us do not use Windows(I don't have
> one for my personal use) and those that do are not skilled enough to
> do GTK development on that platform. We do what we can. I personally
> got involved in the project by hunting a bug that ended up being in
> GTK. It got fixed. True, the bug was specific for Linux, but that's
> the platform I do my development on. I done have neither the will nor
> skills to do that. You can do it on windows if you want.

^^^^
This :).

You said all the things I wanted to say but didn't figure out how to express.

I won't say anything else to avoid being inflammatory.
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[peter sikking]

OK guys,

the tone of this discussion is distracting from the real problems
we have and a possible solution.

and we do have problems that are in gtk (mainly on windows) and with
a load of window managers that do not even implement the window hint
that we are apparently the bleeding-edge users of for our docks.

insight: I met with the openPrinting guys on tuesday and was telling
them how this gtk+windows situation looked like a mini version of
linux printing (_nobody_ can be bothered to work on print dialogs).
the impression of one of the guys was that when it comes to gtk+windows,
what you are talking about is GIMP and inkscape.
these two seem to be the only clients (more than one way) that matter.

what is not helping us is that outsiders expect this big application
to have a big and active development team. to my surprise even the
official commit stats come to that conclusion. meanwhile everyone
who hangs around here knows that we have very limited resources.
piecing all the contributions together I say we got about 3.7
full developers worth going on a at any given time.

I am sure that the 1 million users who download GIMP for windows
every month somehow expect that is was developed on windows.

so the solution is not to ask the people who (and I am grateful
for it) do their best to contribute now. the solution is to
stop potential contributors having to find out by osmosis how
they can help us.

what we can do is be much more concrete on www.gimp.org and
say on the home page: "Help wanted". This is eerily close
to job openings at companies, but that is what we have.

and similar to companies we have to 'sell' our needs a bit.
show that new developers can work on a coherent package of
work where they can make an impact, pretty soon. I think
for instance Martin and Alexia discovered that over the
last years and they have carved out their niche(s) where
they are having a large impact.

"GIMP is looking for an experienced windows XYZ developer who
can really make a difference to our user experience on windows."

I do not want this to be a high-maintenance thing like the SoC.
The effort for the current contributors should be limited to:
- coming up with a coherent package of work and requirements
   for the new contributor ("has to know XYZ libs and ABC algos")
- write the help wanted add (if you do one a month, it may become
   NEWS on all those GIMP tracking sites)
- help the new contributor with the bug numbers and where to start
   in the source ("oh, that is in gtk")
- be really clear in what we want to achieve (I can help with that)
- no further hand-holding

another 'external' area where we really can use some help is gegl,
to get that from its bumbling experimentation speed to production
speeds that are same or even better that current GIMP (I read between
the lines in irc that not everything in GIMP it profiled to the bone).

     --ps

         founder + principal interaction architect
             man + machine interface works

         http://mmiworks.net/blog : on interaction architecture





_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer