Call for ideas: requirements for Krita tool actions system

[Gábor Lehel]

On Sun, Jun 5, 2011 at 2:30 PM, Boudewijn Rempt <boud at valdyas.org> wrote:
> On Sunday 05 June 2011 Jun, Silvio Heinrich wrote:
>> On 06/05/2011 01:40 PM, Boudewijn Rempt wrote:
>> > On Sunday 05 June 2011 Jun, Dmitry Kazakov wrote:
>> >> 12) On some modifiers, like Ctrl and Space, the current tool shoud be
>> >> switched to another one temporarily, like to Color Picker Tool and Pan Tool.
>> > We did that before, but the users didn't like it because the option widget changed. I think that we should have two kinds of tools: normal, and temporary, where the temporary tool only changes the cursor but not the option widget.
>> >
>> > When should we move back to the first tool? On release of shortcut, or on pressing another key? We had the p->pan, b->back to freehand shortcuts, but users didn't like those.
>> We should move back when releasing the shortcut keys.
>> I don't know if it really matters if the tool option widget will change
>> because when releasing the shortcut keys the options
>> should change back anyway...
>
> I know -- but the users we had back then when this was the system disliked the flicker of changing widgets a lot, which was the reason for putting pan and picker in the freehand tool in the first place.

I wasn't one of those users and don't have the relevant experience,
but: when a tool-shortcut was pressed, did only a single widget/docker
change appearance, or did it cause entire continents of the window to
reconfigure themselves (whether because they also changed, or because
of cascading resize and layout changes)? I strongly suspect it
would've been the latter, and that kind of thing can indeed be ugly,
slow, and disorienting, so I can definitely understand users'
annoyance with it. If there were some way to *ensure* that only a
single docker morphed into a different one, staying the same size,
without causing any of the other dockers to react to it, and that this
happened instantly and seamlessly, I don't think I would have a
problem with it. (Just speculation, though... I may be using all kinds
of mistaken assumptions here, in that case, apologies for the noise.)

>
>  >> 13) Canvas rotation should be accessible from all the tools.
>> >> 14) The tool's stroke and decorations should be cancelled on pressing Esc.
>> >> 15) Mouse Wheel should do Pan/Zoom in all the tools.
>> > Maybe we can implement that in the canvas, instead of in the tools?
>
>> Pan, zoom and rotation are implemented in the canvas but there should be
>> 3 separate tools to access this functionality
>
> What I meant was, handle the mousewheel event in the canvas code, instead of delegating it to the tool. otherwise, those functions will stop when the user selects a flake tool. Additionally, we can/should have dedicated tools, of course.
>
>> so that users can see right after starting krita the first time what it
>> is able to do.
>> Later they will use shortcuts anyway but at the first steps with krita
>> it's nice to have an overview.
>> And we would have a logical, consistent system.
>>
>> to 15) The mouse wheel really should be freely configurable (with an
>> option in the preferences) if you want to assign
>> it to pan, zoom or rotation (rotation would be really great for the
>> Intuos4 owners... I think you saw the touch rings on the boards :D ).
>> And yes it should work no matter what tool is selected.
>>
>> Great that the tool stuff gets already started :D
>> If it works out well it would be a big improvement in usability.
>>
>> _______________________________________________
>> kimageshop mailing list
>> kimageshop at kde.org
>> https://mail.kde.org/mailman/listinfo/kimageshop
>>
>>
>
>
> --
> Boudewijn Rempt | http://www.valdyas.org, http://www.krita.org
> _______________________________________________
> kimageshop mailing list
> kimageshop at kde.org
> https://mail.kde.org/mailman/listinfo/kimageshop
>



-- 
Work is punishment for failing to procrastinate effectively.