[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-kimageshop
Subject: Re: Tool(box) organization
From: JL VT <pentalis () gmail ! com>
Date: 2011-01-19 6:47:14
Message-ID: AANLkTi=Hwk5HDT=+MZwb14xtHn8DbTryXCrOEAWT_kuy () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
My feedback to each proposal is below
On Tue, Jan 18, 2011 at 9:25 PM, Sven Langkamp <sven.langkamp@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).
[Attachment #5 (text/html)]
My feedback to each proposal is below<br><br><div class="gmail_quote">On Tue, Jan 18, \
2011 at 9:25 PM, Sven Langkamp <span dir="ltr"><<a \
href="mailto:sven.langkamp@gmail.com">sven.langkamp@gmail.com</a>></span> \
wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex;">Hi,<br><br><br>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.<br> <br>The problem:<br>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.<br>
<br><br>Possible solutions that I have thought of so far:<br><br>-put those tools at \
the bottom of the toolbox as proposed on \
calligra-devel<br></blockquote><div><br></div><div>I believe this is the cleanest and \
easiest to implement of all the options.</div> <div> </div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex;"><br>-cut some of the flake tools and put the functionality \
into the Krita tools<br>
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.<br>
That would leave five tools (Default, freehand, pattern, gradient, \
calligraphy).<br></blockquote><div><br></div><div>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.</div> <div><br></div><div><br></div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex;"><br>-show and hide tools based on the active layer<br>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.<br>
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)<br></blockquote><div><br></div><div>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.</div> \
<div><br></div><div><br></div><div><br></div><div><br></div><div>Conclusion:<br \
class="Apple-interchange-newline">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).</div> <div><br></div></div>
_______________________________________________
kimageshop mailing list
kimageshop@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic