Re: [Inkscape-devel] [Inkscape-user] NEW: four more modes in Tweak tool
On 9/5/07, jiho <jo.irisson@...400...> wrote:
It is better now, much better! Actually it may be even a bit weak at high forces, particularly for path tweaking ;)
OK, increased it a bit again, try 16005
Some other points though: Does the fidelity value have a role for the color changing mode? I don't see any. Maybe it could be grayed out then.
Yes. Or, like I said, just separate path and color tweaking into different tools. I would do that except that I want Jon to make the vertical toolbar clippable first, otherwise it's already too tall.
For this tool I think that the brush radius as well as the forces and fidelity parameters convey more of a qualitative feel (brush big/ small, force high/low/medium, fidelity high/low etc.) and the actual values don't really matter. So maybe the spin buttons could be turned into sliders, since there is enough space on the toolbar currently. If you want to keep the quantitative information sliders similar to those used in for the snapping distance in the preferences could be used. But I really think that a simple slider, maybe with "clicks" every 10 steps or so would be sufficient and more appropriate (and it is an user of Inkscape for precision drawings who speaks!). In fact that would probably be true for many other spin buttons in other tools, in the calligraphy tool in particular, but their toolbar's are already quite full and a spin button is the most space effective widget.
Agreed, but this needs some support from Jon too. Jon, can you implement a way to optionally represent the spinbutton toolbar control as a slider?
On 9/6/07, bulia byak <buliabyak@...400...> wrote:
On 9/5/07, jiho <jo.irisson@...400...> wrote:
For this tool I think that the brush radius as well as the forces and fidelity parameters convey more of a qualitative feel (brush big/ small, force high/low/medium, fidelity high/low etc.) and the actual values don't really matter. So maybe the spin buttons could be turned into sliders, since there is enough space on the toolbar currently. If you want to keep the quantitative information sliders similar to those used in for the snapping distance in the preferences could be used. But I really think that a simple slider, maybe with "clicks" every 10 steps or so would be sufficient and more appropriate (and it is an user of Inkscape for precision drawings who speaks!). In fact that would probably be true for many other spin buttons in other tools, in the calligraphy tool in particular, but their toolbar's are already quite full and a spin button is the most space effective widget.
Agreed, but this needs some support from Jon too. Jon, can you implement a way to optionally represent the spinbutton toolbar control as a slider?
I think what's really needed is a draggable spinbutton subclass like can be found in many 3D and 2D apps. For instance most spinbuttons in Photoshop have a little popup slider that you can make come out. (Actually I think that's a pretty cumbersome UI, but still better than having to click the buttons one by one.) Blender's spinbuttons allow you to drag directly on top of the text to change the value. I think Maya, Max, and XSI also all have some variation on the draggable spin-button idea. The GLUI toolkit for OpenGL allows dragging on the buttons themselves.
I think almost all the spinbuttons in Inkscape (and Gimp for that matter) could benefit from such functionality.
--bb
On 9/5/07, Bill Baxter <wbaxter@...400...> wrote:
I think what's really needed is a draggable spinbutton subclass like can be found in many 3D and 2D apps. For instance most spinbuttons in Photoshop have a little popup slider that you can make come out.
Sure, that would be the best of both worlds, but I just don't think GTK has this kind of thing. If someone can code that out of GTK widgets, you're very welcome :)
On 2007-September-05 , at 22:05 , bulia byak wrote:
On 9/5/07, jiho <jo.irisson@...400...> wrote:
[...] Some other points though: Does the fidelity value have a role for the color changing mode? I don't see any. Maybe it could be grayed out then.
Yes. Or, like I said, just separate path and color tweaking into different tools. I would do that except that I want Jon to make the vertical toolbar clippable first, otherwise it's already too tall.
Unless there's a way to reorganize the toolbar icons, this won't really solve the problem: it is not very practical to go click the hidden tools' icons unless you can put there the tools you don't use much (and this will be different for everyone, hence the need to have re-oganizable toolbars). I personally find this OK to have color+path tweaks in the same tool. It seems quite natural, to me at least. Maybe some some color gradient/patchwork could be added to the icon to reflect that?
JiHO --- http://jo.irisson.free.fr/
On 9/5/07, jiho <jo.irisson@...400...> wrote:
Unless there's a way to reorganize the toolbar icons, this won't really solve the problem: it is not very practical to go click the hidden tools' icons unless you can put there the tools you don't use much (and this will be different for everyone, hence the need to have re-oganizable toolbars).
All toolbars are already internally constructed from an XML representation. I think it's an easy fix now to have Inkscape read these representations from a file. Jon, are you planning to add that one day?
On Sep 5, 2007, at 2:03 PM, bulia byak wrote:
On 9/5/07, jiho <jo.irisson@...400...> wrote:
Unless there's a way to reorganize the toolbar icons, this won't really solve the problem: it is not very practical to go click the hidden tools' icons unless you can put there the tools you don't use much (and this will be different for everyone, hence the need to have re-oganizable toolbars).
All toolbars are already internally constructed from an XML representation. I think it's an easy fix now to have Inkscape read these representations from a file. Jon, are you planning to add that one day?
Yes, that is correct.
And yes, planning on getting that in very soon. I want to use a nice XML form, and not the GTK+ stuff directly. Their stuff seems to be more patterned off of GLADE's support, and we'd want something more simple and abstract.
I have one or two more toolbars left to convert, then the external file representation would be next.
On Sep 5, 2007, at 1:05 PM, bulia byak wrote:
Yes. Or, like I said, just separate path and color tweaking into different tools. I would do that except that I want Jon to make the vertical toolbar clippable first, otherwise it's already too tall.
Yup. Definitely on the short list of top TODOs.
There are a few places where things are wired directly to widgets, instead of having some encapsulation. Once those are cleaned up it will be easy to get the vertical toolbar functioning like the others
For this tool I think that the brush radius as well as the forces and fidelity parameters convey more of a qualitative feel (brush big/ small, force high/low/medium, fidelity high/low etc.) and the actual values don't really matter. So maybe the spin buttons could be turned into sliders, since there is enough space on the toolbar currently. If you want to keep the quantitative information sliders similar to those used in for the snapping distance in the preferences could be used. But I really think that a simple slider, maybe with "clicks" every 10 steps or so would be sufficient and more appropriate (and it is an user of Inkscape for precision drawings who speaks!). In fact that would probably be true for many other spin buttons in other tools, in the calligraphy tool in particular, but their toolbar's are already quite full and a spin button is the most space effective widget.
Agreed, but this needs some support from Jon too. Jon, can you implement a way to optionally represent the spinbutton toolbar control as a slider?
Yes. At least one of the types is set up for doing a presentation hint for how to manifest the widget. It's not hard to do slider vs. spinbutton.
participants (4)
-
Bill Baxter -
bulia byak -
jiho -
Jon A. Cruz