From kde-kimageshop Wed Jan 19 06:47:14 2011 From: JL VT Date: Wed, 19 Jan 2011 06:47:14 +0000 To: kde-kimageshop Subject: Re: Tool(box) organization Message-Id: X-MARC-Message: https://marc.info/?l=kde-kimageshop&m=129541966331453 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============0642510840==" --===============0642510840== Content-Type: multipart/alternative; boundary=001636c5a5d020900f049a2d6310 --001636c5a5d020900f049a2d6310 Content-Type: text/plain; charset=ISO-8859-1 My feedback to each proposal is below On Tue, Jan 18, 2011 at 9:25 PM, Sven Langkamp 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). --001636c5a5d020900f049a2d6310 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 pr= oposal I'm putting it for discussion.

The problem:
Currently the first eight tools in the toolbox are flak= e 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 im= plement of all the options.
=A0

-cut some of the flake to= ols and put the functionality into the Krita tools
There are some tools that have very little value for Krita like the connect= ion 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, calligra= phy).

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 wou= ld show the Krita gradient tool on a paint layer and the flake gradient too= l 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 dra= wing on a shape layer so every tool would shift by one position. One possib= le 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 free= hand tool would show up where the Krita freehand tool was.
I think the disadvantage of this is that it might not too obvious when some= thing switched. (I also thought of vector paintops, but I'm not sure th= at is worth the effort)

This option doe= sn'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&#= 39;t think of exceptions) when some controls disappear instead of being gra= yed-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 an= d 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).

--001636c5a5d020900f049a2d6310-- --===============0642510840== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ kimageshop mailing list kimageshop@kde.org https://mail.kde.org/mailman/listinfo/kimageshop --===============0642510840==--