Toolbox management proposal (presets and tool toggle)
Before I start... what can I submit as "blueprint", and what should I be submitting as "wishlist" instead? Can I use the wiki? If so, what pages am I supposed to save them as? Anyway, most of these will be submitted separately, but they're all only made feasible with a proper toolbox management.
So the toolbox is getting cramped, right? At the same time, it's not really fun when many tools are grouped and you have to find each sub-component (case of the tweak tools, I can never remember the shortcuts either). So here's a possible solution, and some possibilities that'd derive from it.
1. Toolbox proposal
http://img113.imageshack.us/img113/416/toolbarmanagement1ov3.png http://img146.imageshack.us/img146/3712/toolbarmanagement2xb0.png
Some features: - There should be a visible icon, as people won't be able to find the feature otherwise.
- The icon allows you to access toolbox presets.
- Managing a preset is easy, just go to "configure toolbox" and toggle on and off the visibility of any tool, just like with Gimp.
- Multiple toolbars may be possible: see mock-up 1. The additional floating toolboxes would have a close button, though not the "main" one to avoid confusion (insert "Aaah! My toolbox has disappeared!" messages).
- Some tools could have "grouped" and "separate" options (mock-up 2). Examples: . square, ellipse, spiral and polygon can be options of a single "shapes" button for those who don't use them often. . the individual modes of the tweak tool could be accessible separately: see mock-up. . when 3D shapes are added, they'd also have both grouped and separate options.
- Since management is easy now, have some LPEs as tools too? Please? PLEASE???
2. LPE as tools
With a proper toolbox management system like the one above, LPEs can be incorporated as tools when needed. It saves one the trouble of applying one from a panel every time (it Really breaks the flow when you have a lot of lines to do, not to mention the LPE panel takes up a lot of space).
This would simplify interface for many LPEs tremendously. You just select the tool, modify any necessary parameters, and draw the paths you need. As soon as you've drawn the path the effect is automatically applied. For example, Spiro lines: you draw your normal bezier, and as soon as you release the mouse it becomes a Spiro line (by the way, any chance for "native" Spiro lines as opposed to a Bezier with an LPE on it?).
I actually think LPEs should eventually be separated into categories: - Spiro lines (native spiro lines? Yes please!) - Complex lines (sketch, waves, wide) - Shape generators (gears, stiches, etc.) - Guides (grids, technical, composition guides, perspective guides) - Transform (envelop deform, perspective deform) - etc.
3. LPE tool: Wide lines
It's crazy, but it's nearly impossible to find a program that would let you do a nice double-edged line without either: - a tablet (+ very steady hands, which I don't have) - half a dozen operations - or forcing you to switch between panels.
It's Really discouraging when you want to do several hundred hair strands. D:
The wide lines LPE would be a very simple tool: a few basic shapes are saved. You draw your path. The shape automatically gets stretched onto it:
http://img164.imageshack.us/img164/9302/widestrokeslpemx3.png
There you go, easy-to-edit (direction wise, in any case, I'm assuming that a person doing dozens of hair strands does not care about the exact form of each) double-edged stroke drawn in a single operation with a mouse (or with bezier, whichever).
Note: Developers will probably not want to set this as a tool until a proper toolbox management system is in place, which is why I proposed one myself (though I'd be more than happy if a better solution comes along).
For this particular LPE tool, you'd have the following entries: - size: size of the maximum. It basically takes the saved shape and adjusts the size first, so you can modify the width of the strokes with just the directional keys. - presets: preset shapes: single edge, double edge with max at 1/2, double-edge with max at 1/4, etc. Users can add their own commonly-used shapes, but the above are among the most ridiculously common ones. - and you can adjust the size with just the directional keys! (though there could be %width options to further tweak the thin lines)
If anybody knows how to automatically generate shapes likes these, that's fine too (though let's be honest, including a few files of shapes like these would take up tiny disk space anyway. They're 4 nodes each!).
4. Tool for charts: shapes with text
Another feature that probably would be considered too much waste of real-estate without a proper toolbox management.
I often use Inkscape to do charts. Having to call up the Align dialog each time (which really takes up a Lot of space by the way) just to place a few text into shapes, and having to realign every time the text is modified, is needlessly tedious to say the least.
The auto-text shapes I'm proposing would come as Ellipse, Text, or Polygon. They're simple: place a shape, click on the center and you can start typing away. The text is always automatically aligned to center (or some other option of your choosing).
They may have the following features or options: - padding of text to borders: sets a minimum distance between the text and the border. - auto-adjust size: if the text starts to fill the shape, the shape resizes automatically to fit. - the default is for the text to be centered, but there could be other alignments. - linked duplicates: a linked duplicate only conserves the shape, not the text content, so by making a duplicate, when the text in one of the boxes forces one of the items to become bigger, all the other shapes of the same type resize as well. This is for those charts that need all elements to be of approximately the same size. - adding points for connectors: this is simpler for rectangle shapes than for other shapes... you can basically specify how many connector points you want per side (example: 3). Though, ideally, there'd be an on-canvas means to mark points for each side, but I don't have UI ideas for that one...
Also handy for comics.
It's at least three steps fewer (changing the tool, selecting all then aligning the whole, not to mention it has to be repeated if the text is changed much) for a rather common task, which can translate into a good enough time gain and a much more pleasant work flow.
Any comments before I submit? (if only to say which ones should Not be submitted as blueprints, because I'm a bit confused right now)
Hi Valerie,
excellent suggestions! I'm going to comment in detail in a couple of days, since I'd like to get some things that I'm working on sorted out and committed first. Just wanted to mention that my work for GSoC is very much in the spirit of some of your ideas. In particular, I'm planning to take a good step towards making LPEs easier to use and establishing them as tools in their own right. As I said, more comments to follow (probably during the weekend).
Best, Max
Just wanted to mention that my work for GSoC is very much in the spirit of some of your ideas. In particular, I'm planning to take a good step towards making LPEs easier to use and establishing them as tools in their own right.
Yes! Thank you!
You're the one doing the technical drawing tools, right? It's one of the reasons I've decided to bring up this proposal "now." Otherwise there'd really be no-place left for all of them...
Now the problem is whether toolbar management is easy to implement or not...
I'm going to comment in detail in a couple of days, since I'd like to get some things that I'm working on sorted out and committed first.
No problem! Take your time!
The blueprint system gives a better mechanism for prioritizing and collaborating on writeups of ideas than we can get with wishlist items. Blueprints can also be linked together in dependency chains, which sounds like it could be useful in this case.
So I would recommend submitting all of them as blueprints.
Thank you very much! I'll wait for Maximilian's comments first to see if I can refine the ideas before posting them.
On Thu, May 29, 2008 at 11:30:22AM -0700, Valerie wrote:
Before I start... what can I submit as "blueprint", and what should I be submitting as "wishlist" instead? Can I use the wiki? If so, what pages am I supposed to save them as? Anyway, most of these will be submitted separately, but they're all only made feasible with a proper toolbox management.
The blueprint system gives a better mechanism for prioritizing and collaborating on writeups of ideas than we can get with wishlist items. Blueprints can also be linked together in dependency chains, which sounds like it could be useful in this case.
So I would recommend submitting all of them as blueprints.
Bryce
On May 29, 2008, at 11:30 AM, Valerie wrote:
Before I start... what can I submit as "blueprint", and what should I be submitting as "wishlist" instead? Can I use the wiki? If so, what pages am I supposed to save them as? Anyway, most of these will be submitted separately, but they're all only made feasible with a proper toolbox management.
So the toolbox is getting cramped, right? At the same time, it's not really fun when many tools are grouped and you have to find each sub-component (case of the tweak tools, I can never remember the shortcuts either). So here's a possible solution, and some possibilities that'd derive from it.
- Toolbox proposal
http://img113.imageshack.us/img113/416/toolbarmanagement1ov3.png http://img146.imageshack.us/img146/3712/toolbarmanagement2xb0.png
Some features:
- There should be a visible icon, as people won't be able to find the
feature otherwise.
The icon allows you to access toolbox presets.
Managing a preset is easy, just go to "configure toolbox" and
toggle on and off the visibility of any tool, just like with Gimp.
This is good, but I don't think it quite goes far enough.
:-)
We've been talking about profiles or modes that can shift more of the UI. Toolbars, menus, docked palettes, etc.
Internally I've gotten most of the current toolbars changed to use XML definitions. The plan is to expose these soon through some nice markup format (the internal format GTK+ uses is not quite appropriate for our needs).
The source is in src/widgets/toolbox.cpp at the moment, and the existing XML starts with:
"<ui>" " <toolbar name='SelectToolbar'>" " <toolitem action='EditSelectAll' />" " <toolitem action='EditSelectAllInAllLayers' />" " <toolitem action='EditDeselect' />" " <separator />" " <toolitem action='ObjectRotate90CCW' />" " <toolitem action='ObjectRotate90' />" " <toolitem action='ObjectFlipHorizontally' />" " <toolitem action='ObjectFlipVertically' />" " <separator />"
Names for the toolbars is one thing to work on... but the big overall task is probably those action names. Those will be the key for dynamic UI.
So for a menu or toolbar configuration, we'll just need to allow for the final XML format (yet to be determined) to be loaded, modified via tweaking the UI directly, and saved.
But to the big picture... we've been talking about supporting "workflows" or "modes" or whatever, that are use oriented. That is, some might have a "diagramming" workflow, and some users might want an "icon editing" workflow, etc. Some might change in the middle of a project. A comic author switching from pencils phase to inking phase might be one example.
This is good, but I don't think it quite goes far enough.
:-)
We've been talking about profiles or modes that can shift more of the UI. Toolbars, menus, docked palettes, etc.
Oh, sure! I've been pushing the concept of "workspaces" for both Gimp (where it was immediately marked as "low priority" :o ) and Krita of KOffice. In the case of KOffice, they've noted that their current UI tools are insufficient for dynamic workspaces, so it will need a lot of work.
I've found it slightly less urgent until now for Inkscape though, because despite the variety of tasks possible with Inkscape, they don't diverge Quite as much as say... photo manipulation vs painting in Gimp (in particular, as soon as the painting folks want more painting features, the photo folks start complaining that it would add too much to the UI, which led the developers to say once and for all that Gimp is a Photo program, go figure).
However, if technical drawing capabilities are added to Inkscape, then it changes the situation somewhat and would require more specialized settings. Autocad (which has yet more functions, but whatever) isn't a completely separate program from Adobe Illustrator for nothing (say, text command palette for Inkscape...).
Anyway, I've always been pretty fond of "divide and conquer" approaches. A full workspace approach would be: - toolbar management (my current proposal) - saving of preset settings (both document -snap, guides etc- Inkscape tool settings) - menu editing (in my opinion, more important for complex raster programs than for Inkscape) - and enabling/disabling of specific features (animation capabilities only activated in an "animation" mode, collaborative features only activated in an "online collaboration" mode)
These can all be implemented separately, then grouped with a single Workspace command (menu drop-down: choose workspace. A workspace would basically be loading: a toolbar setting + a menu setting + tool and document settings + etc.)
I started with toolbar management because I find it the most immediately useful and urgent: to make all those new LPEs into proper tools. Tool access is where 80% of workflow goes. Sure, it's really pesky when I have to remember to turn on or off the "scale stroke width" when doing charts or doing something else, but it's something that I only need to do once per document so at least I can live with it.
Accessing those LPEs that could be implemented as tools though? A whole other story. ;)
Oh by the way, if said toolbox management proposal gets added, could the two following be added? - color correction toolbox (brightness/contrast and other such niceties, so you don't have to save as png and export to Gimp all the time) - some raster tools (I'm not asking for a raster program in Inkscape. But I like making mock-ups in Inkscape a lot more than in Gimp because of the easy select and moving around. But I could really use that crop tool without opening Gimp's gazillion panels each time D: )
On Thu, May 29, 2008 at 3:30 PM, Valerie <valerie_vk@...36...> wrote:
http://img113.imageshack.us/img113/416/toolbarmanagement1ov3.png http://img146.imageshack.us/img146/3712/toolbarmanagement2xb0.png
I agree that the tool overload problem needs to be resolved sooner or later, but do we really need it to be that complex? Why not just allow the user to add and remove tools from a "tool pool" onto a single toolbar? Sure that won't allow for as many tools as your proposal, but I'm really not convinced that we indeed need that many tools. Turning each mode or LPE to a tool is not the best approach IMHO. Each tool, ideally, must represent some specific way of working, a work paradigm, where many separate capabilities or modes may fit.
With a proper toolbox management system like the one above, LPEs can be incorporated as tools when needed. It saves one the trouble of applying one from a panel every time (it Really breaks the flow when you have a lot of lines to do, not to mention the LPE panel takes up a lot of space).
Many LPEs make little sense unless you can adjust their parameters, and while for some of them the params would fit into the controls bar, but e.g. for Sketch there's no chance to fit everything there.
More importantly, a tool is warranted when (at least) there's something different that it does when you drag on canvas. What would an LPE tool do on a drag? Draw a path? But we have Pen and Pencil for that. Why not, instead, add a simple LPE choosing widget to the control bars (now empty) of these tools?
This does not mean that LPEs don't need to be _editable_ on canvas. They do. But this is doable via handles, and is being done already.
release the mouse it becomes a Spiro line (by the way, any chance for "native" Spiro lines as opposed to a Bezier with an LPE on it?).
Not in the sense that SVG does not support anything but regular bezier paths. So at the SVG level, they will always be regular paths with LPE attached. But we can certainly make dealing with Spiros more convenient - for example, we can add to the Pen tool a switch allowing it to draw a spiro path directly.
http://img164.imageshack.us/img164/9302/widestrokeslpemx3.png
This widget is exactly what I would love to see, but not in its own tool - why? Its most natural place is on the control bars of Pen and Pencil, forcing these tools to produce paths with pattern-on-path with predefine profile paths. A profile width control would also be appropriate there.
I agree that the tool overload problem needs to be resolved sooner or later, but do we really need it to be that complex? Why not just allow the user to add and remove tools from a "tool pool" onto a single toolbar?
Because usually, people use specific sets of tools for specific tasks, common groups of which can be determined: - drawing (in which case people like me would rather have tweak tools separate) - charts (as I've said, I'd really like to see dedicated chart tools. They Could be implemented as sub-modes of the current shapes as long as people don't mind the clutter) - 3D (when you have multiple 3D tools, you'd want these, deform to 3D, 3D grids and a few normal drawing tools) - technical (you'd need all those new technical tools) - font design? (Spiro! Just keep the current implementation, but eliminate the red line of the original) - color adjustment? (calls up brightness/contrast, hue/saturation etc for those last minute adjustments) - some raster tools? (I'd rather do my mock-ups in Inkscape than in Gimp because of the easy boxes and easy moving things around. However, I Really need that crop tool...)
Having pre-defined categories would be convenient for users, especially when they can further tweak on their own and create their own sub-sets. Assuming that users don't want to be limited to one set of tasks, allowing them to quickly-access sub-sets would be handy.
I actually base this approach on my gripes with Gimp: Gimp allows you to tune your interface (more or less) to One task and that's it, when there are several types of tasks I'd like to do with it. Having to re-tune the interface each time though is so annoying that I've stopped bothering completely, even though it results in a rather unpleasant workflow.
Many LPEs make little sense unless you can adjust their parameters, and while for some of them the params would fit into the controls bar, but e.g. for Sketch there's no chance to fit everything there.
More importantly, a tool is warranted when (at least) there's something different that it does when you drag on canvas. What would an LPE tool do on a drag? Draw a path? But we have Pen and Pencil for that. Why not, instead, add a simple LPE choosing widget to the control bars (now empty) of these tools?
This widget is exactly what I would love to see, but not in its own tool - why? Its most natural place is on the control bars of Pen and Pencil, forcing these tools to produce paths with pattern-on-path with predefine profile paths. A profile width control would also be appropriate there.
So basically, you're proposing complex strokes as a sub-mode of pencil and pen? That's workable. How do you propose to settle the UI issue of fill vs stroke color? With LPE, the stroke Is the shape, after all (though I suppose said shape/stroke doesn't need its own stroke).
I'll try to design a mock-up for this then.
By the way, have any of you ever used the Freehand draw tool of Karbon14 of KOffice? It's even smoother than Inkscape's. I know someone from Inkscape is working on a new implementation of freehand so that the final curve is calculated only once all the points are placed, resulting in smoother output, but would it also have sub-modes (raw, curve, line) + additional smoothing like Karbon14?
Screenshot:
http://img137.imageshack.us/img137/9927/karbon14px5.png
Smoother output + auto LPE on it = win!
participants (5)
-
Bryce Harrington
-
bulia byak
-
Jon A. Cruz
-
Maximilian Albert
-
Valerie