On Thu, 28 Sep 2006 14:39:39 +0200, Raphaël Quinet <raphael@xxxxxxxx>
wrote:
On Thu, 28 Sep 2006 01:42:12 +0200, gg@xxxxxxxxxxx wrote:
[...]
1/ In general I find it needs too many mouse/keyboard actions to
achieve a
simple operation.
1a/ specific: undo : edit | undo . This must be one of the most common
actions I want a one click solution, in the same window as I am editting
in.
There's always cntl-Z cntl-Y but that means dropping the mouse and
diverting my attention away fron the screen. Very slow.
Well, the undo shortcut is probably not assigned to Ctrl-Z by
accident. Did you notice that there is no Z in "undo"? Something
like Ctrl-U could have been used instead (and was used in the past).
But many applications use Ctrl-Z. If you are a right-handed
english-speaking user (or at least someone with a qwerty keyboard),
you can see that Ctrl and Z are close to each other and can be pressed
easily with the left hand while the right hand is on the mouse. You
might complain about discrimination against lefties or foreigners, but
at least for a large percentage of the users, the Ctrl-Z shortcut can
be found easily without diverting attention from the screen or mouse.
Yes, I know cntl-Z can be hit with one hand but I am going to scrabble
around unless I look, in which we're back to my original point. A close to
hand undo button would be a lot faster.
1b/ I pull up a dlg. the first text entry is highlighted so I can type
to
replace , fine. But if I want to edit it eg 100 to 400, I go to select
the
"1" with the mouse and the editted text gets dragged. Huh? So I have to
click to deselect the reselect the bit I want.
Solving this problem would probably require disabling drag & drop from
the input fields. I am not sure that anyone uses that feature anyway,
at least for the short entry fields that we have in most dialogs
(except for the text tool). I agree that it is more likely that
someone who clicks and drags in one of these short input fields wants
to select some digits instead of dragging the whole number elsewhere.
This should probably be submitted in Bugzilla.
Done.
2/ I am continually repeating the same placement/configuration
operations
where once should be enough.
2a/ It seems none of the filters retain thier position and size,
although
they retains _some_ of their settings.
Right. We do not even have an API allowing the plug-ins to retain
their size and position easily. Although the current API based on
gimp_get_data() and gimp_set_data() could be used for that, every
plug-in writer would have to write hacks around gimp_dialog_new() or
gimp_dialog_run() in order to resize the window correctly. In
addition, the filters that have a more complex layout with resizeable
panes inside the window would also have to remember the size of each
of them (e.g. Filters->Map->Bump Map) and those that have multiple
tabs should remember which tab is active.
Taking Bump Map as an example, this is a good case in point. The preview
autorescales so all we need is size and position to be reatained. Many of
these previews are too small to see the effect clearly. That's my main
reason to resize the dlg.
I think technical difficulties of implementation need to be separated from
UI discussion until the value of the idea has been assessed. I would have
other comments about the flexibility on API implementations.
specific: Filters | Motion Blur ... I resize to get a more visible
preview size and move it out of the way of other things on the screen.
Next time I use it I dont want to start again.
While this is probably down to the plugin writer, at least the "common"
filters should be vetted/modded to retain size/pos before being
integrated. And it should be recommended for all plug-ins.
I agree. Please submit this improvement proposal in Bugzilla. It may
even be useful to remember the window positions (for the plug-ins)
accross gimp sessions. In this case, this information should probably
go into the pluginrc or something similar.
Done.
2b/ If I use a dlg on one image and set, say units to pixels , if I open
another image or even duplicate I have to reset the same options.
specific: Image | Scale Image , set to percent . Duplicate image , Scale
Image : back to default pixels.
Although it would make sense for Duplicate, I am not sure that it
would be good to always remember the last values used when you create
a new image. The defaults can be set in Preferences->Default Image
and I would like these values to be used.
I was refering to scale image, duplicate was mentioned to show that each
instance of the dlg reverts while the same instance retains. Rather
inconsistant. Settings could be stored when the dlg is closed so that the
same dlg on another image can retain them.
2c/ I have selected for tools to store settings but this seems limitted.
specific: again the Scale Image dlg. units combo. This is held for the
time I edit an image but not affected by the config option :tools store
settings.
I do not understand what you expect in this case. Things like the
resolution, units, grid spacing and so on are a property of the image.
The Scale Image dialog should just use what is specified for that
image. But maybe I misunderstood what you meant.
I dont see what "tool store settings" does. I see some data about brushes
if I plough through the configs but if I choose to work in percent rather
than pixels this is not remembered.
May be this just needs to be more complete.
2d/ I set a value , eg rotation degrees or scale percent. Next time I
pull
up the dlg it's back to NOP settings : zero degrees or 100% scaling.
Now I
dont necessarily want the same value but one thing it's sure I dont need
is a NOP. Last entered value would be a better starting point.
Hmmm... I am not too sure about that. One the one hand it would not
be too hard to remember the last values and the user could easily
click on the nice Reset button if these values are not appropriate for
the next image. On the other hand, I would probably be surprised to
see my image (preview) instantly rotated, shrunk or distorted as soon
as I activate one of the transform tools.
Well I looked at this with rotate. The preview on the image just shows the
outline that will be rotated but does not move the image/selection until
the dlg closes. This indeed seems the best of both worlds if it retains my
last rotation setting. I either hit "go" or reset as you suggest.
There are different behaviours on both shear and perspective. That should
probably be a bug report in itself.
If all were aligned to the rotate model this could work very well.
All these are minor things on their own but the overall effect is
_several
times_ more mouse actions than are really needed to get a job done.
Right. This kind of usability feedback is useful and should be
discussed here or in Bugzilla. Thanks for your comments.
No problem. In trying to debug a couple of issues I rapidly became
frustrated with the ammount of time I was wasting on these repeated
manouvres. If there's a willingness to address some of these points that's
great.
-Raphaël
_______________________________________________
Gimp-developer mailing list
Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
_______________________________________________
Gimp-developer mailing list
Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
