Tool(box) organization

[JL VT]

My feedback to each proposal is below

On Tue, Jan 18, 2011 at 9:25 PM, Sven Langkamp <sven.langkamp at gmail.com>wrote:

> Hi,
>
>
> I have been thinking about a better organization of the toolbox. Since Boud
> didn't like my first proposal I'm putting it for discussion.
>
> The problem:
> Currently the first eight tools in the toolbox are flake tools. The are
> more of less useful for work in Krita, but are in general secondary
> functionality for Krita. So the question is how the tools should be organize
> to give fast access to the common tools.
>
>
> Possible solutions that I have thought of so far:
>
> -put those tools at the bottom of the toolbox as proposed on calligra-devel
>

I believe this is the cleanest and easiest to implement of all the options.


>
> -cut some of the flake tools and put the functionality into the Krita tools
> There are some tools that have very little value for Krita like the
> connection tool or filter effect tool (we can't save filters created by
> that). The path tool basically has the same stuff the Krita path tool has.
> That would leave five tools (Default, freehand, pattern, gradient,
> calligraphy).
>

Eliminating a tool whose results can be saved in a .kra file sounds very
reasonable too, I see no reason to keep one, and can't think of a use case
where using a tool that can't be saved could be useful for someone.



> -show and hide tools based on the active layer
> This would hide all tools that are not compatible with a certain layer and
> show the tools that are. So it would show the Krita gradient tool on a paint
> layer and the flake gradient tool on a shape layer. Problem here is that is
> can cause some toolbox buttons to shift e.g in the second group the freehand
> tool isn't capable of drawing on a shape layer so every tool would shift by
> one position. One possible solution could be to do some clever arrangement
> so that the hidden tools would appear in the gaps left by the hidden Krita
> tools, so the flake freehand tool would show up where the Krita freehand
> tool was.
> I think the disadvantage of this is that it might not too obvious when
> something switched. (I also thought of vector paintops, but I'm not sure
> that is worth the effort)
>

This option doesn't seem viable to me. From what I've seen, getting Qt
widgets to behave is a whole ordeal, and it's almost always confusing (and I
can't think of exceptions) when some controls disappear instead of being
grayed-out when the layer changes or some other actions are done performed
in the image. Sounds very tricky to pull when something simpler (options 1
and 2) can do the job better or just as well.




Conclusion:
I think a mixture of proposal 1 and 2 would be the best: remove tools that
are of little or no value to Krita, and place the rest at the bottom of the
toolbox (unaltered for simplicity, unless there is a strong reason to remove
duplicated functionality, like appears to be the case of the Flake path tool
and the Krita path tool).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kimageshop/attachments/20110119/e89d1c47/attachment.htm