Re: [Gimp-developer] GIMP UI quality opinion

[Bogdan Szczurek <thebodzio gmail com>]

W dniu 12-02-16 17:25, Aleksey Midenkov pisze:
> On Thu, Feb 16, 2012 at 8:18 PM, Bogdan Szczurek<thebodzio gmail com> 
 wrote:
>> W dniu 12-02-16 16:57, Aleksey Midenkov pisze:
>>
>>> On Thu, Feb 16, 2012 at 6:06 PM, Robert Krawitz<rlk alum mit edu> 
  wrote:
>>>> On Thu, 16 Feb 2012 16:07:51 +0400, Alexandre Prokoudine wrote:
>>>>> On Thu, Feb 16, 2012 at 3:43 PM, Aleksey Midenkov wrote:
>>>>>> To Martin: even Save and Save as on toolbar saves one click. Not
>>>>>> saying about such repitive operations as Rotate, Resize, Auto levels
>>>>>> etc. Now trivial photo treatment is done with the whole lot of 
clicks!
>>>>>> I'm pretty sure their count can be reduced thrice with toolbars.
>>>>
>>>> Generally, you're not doing those things more than once per image 
(well,
>>>> when downscaling a large image by a lot -- say, reducing a 100 
megapixel
>>>> panorama to a web-size thumbnail -- I do it in multiple passes of no
>>>> more than 50% each, which seems to reduce jaggies and moire patterns).
>>>
>>> Yes once per image, you right. But this doesn't change the point. The
>>> click count from menu is at least twice, if from submenu then 3x. Also
>>> such functions as 'Autolevel' is 3-4 clicks. When I have 10 photos I
>>> need to process in some manner if I spend on one image 20 clicks, it
>>> will be 200 clicks. From toolbar it would be, say, 70-90 clicks. And
>>> please don't suggest me to write batch script (I know you have that in
>>> Gimp).
>>
>> Why not? Write a script… or suggest solid action recording. These 
are the
>> ways meant exactly for that kind of work. 40 click or 200 clicks – 
they'll
>> all be annoying just the same :}.
>
> Because each operation on each photo must be eye-controlled. F.ex.
> cropping parameters or brightness tuning is different per each image.
> Every one and else try to simplify all cases to one solution. But
> there are no simple solutions. Somewhere scripts are better, somewhere
> (in lots of real cases) not.

And that's why script can display popup window or wait for input when 
needed. You're right – parameters can differ, but workflow (single 
steps) remain the same. You can argue, and rightfully so, that sometimes 
a couple of "trys" are necessary to be satisfied with the results of a 
single "workflow step" (e.g. you've decided that you've used curves too 
"aggresively" than justified and want to go and try again). Here's IMHO 
real potential ground for innovation. How about leaving scripts and 
"actions" paradigms and step forward to "workflows"? It should be easy 
enough with GEGL (not only GEGL ops are to be considered, mind you, but 
GEGL would be helpful) to build such things. I understand single 
"workflow" as follows:

• You've got a series of images to process. The thing is, some of the 
transformations must be done manually (like smearing some paint over) or 
controlled on by-image basis (it's your concern AFAIK).

• Each of the images have to have the same basic set of operations 
applied in well defined order. So we have known: image list and the set 
of steps for each image. It remains uknown, however, if some of these 
steps will be repeated or reverted to try again. It would be convenient 
to do so but stay in the "workflow" at the same time to avoid having 
forget something (like converting to grayscale) before saving image.

• What you'll need to solve this problem are basically 5 keyboard 
shortcuts (or "buttons" if you will) – easy enough to master even in 
music player ;}: 1 – previous image, 2 – next image, 3 – previous step, 
4 – next step, 5 – apply current step's transformation/operation. Exact 
behavior remains to be discussed later. That's it! One thing worth 
noticing is that "step" can be understood also as using a brush, so 
simple queue of GEGL transformations or "adjustment layers" are not 
sufficient here.

How about that?

>>
>>
>>>>
>>>>> 1. We are aiming at professionals who tend to rely on shortcuts.
>>>>> 2. We take a great care providing as much vertical space for actual
>>>>> images as possible.
>>>>
>>>> With the increasing prevalence of 16:10 and even worse 16:9 screens,
>>>> that's absolutely essential.  Even with my 1920x1200 screen, vertical
>>>> space is at more of a premium than horizontal.  With a contemporary
>>>> 1920x1080 or worse, the problem would be far more severe.
>>>
>>> As was said before, good software supplies customizable and stackable
>>> toolbars. That means that everyone is free to remove or add toolbars
>>> and buttons to his personal needs (and to vertical sides of the screen
>>> too). This removes problem with vertical space (which I personally
>>> value too) and neglect the statement about cluttered interface. Hey
>>> people, don't you really used something like Microsoft Word or
>>> LibreOffice to not understand that?! :-) (I'm not yelling)
>>
>> I did and am. And that's why I moved gross of my work to apps that 
can be
>> controlled mostly by keyboard :} – it's just much quicker that way. 
Granted
>> – for me… but there are more people to back up this statement. 
Getting used
>> to using your keyboard and shortcuts extensively can be quite 
demanding, but
>> it just pays off in the long term.
>
> I were using Emacs for programming and knew a lot of key-bindings. And
> now I prefer KDevelop.

You prefer KDevelop… or rather clicking down buttons with your mouse? 
That's your _choice_, and the above was my _suggestion_ :}. I _suggest_ 
something that works for me and works good at that – not trying to drag 
anybody into "the hell I'm in" just out of envy of their better ways ;}.

> So what? That is your experience, and that is
> mine.

I've seen many people used to "clicking" and convinced them to use "my 
way". Haven't heard any complaint – on the contrary – people tend to 
tell me it's quicker and easier for them to use keyboard shortcuts. 
That's my experience. Maybe it was only a handful of people I've 
"experimented on" but still enough to notice micro-tendency :}.

My best!
thebodzio