That was what I was planning to do. But instead of grayed icons, I think I'll replace them by specific node align icons (node align vert, node align hor, node ditribute vert, node distribute hor).
Yes, I like the screenshot in your blog. I need to play with it, however, to be able to comment more. What is your SF name so I could give you CVS access?
One idea I had is this: Imagine you have a path consisting of strict horizontal and vertical segments, and you want to distribute (some of the) vertical segments (not nodes!) equi-spacely. I think it's a pretty common situation, but distributing _nodes_ will break the verticality of segments. So I propose to add a (perhaps optional) rule: If two or more nodes are aligned vertically (within some tolerance), consider them one node and move them as a whole during horizontal distributions, and the same for horizontal alignment/vertical distributions. Makes sense?
Also, I'm sure you did it, but just in case: node alignment must only affect selected nodes (node selection only exists in the node edit context), not all nodes in the selected object.
Another thing I always wanted to have is Random distribution. Maybe you can add it while you're working on that dialog, I think it should be easy enough?
To do so, if it's not already here, I'll add a stdc::signal<void, ToolIdent> _tool_changed; for the desktop.
Yes, it will be very useful in other situations as well.
Yes. But as we will refactor all the dialogs, that should be the right time to do it. The only thing needed is to make each dialog inherit from a class.
That's a good idea, as currently there's much shared code that can be moved to the parent class (delete/destroy handlers, etc.). Some of the shared code is already factored out into dialog-events but not all.
is the impact on the GUI. Do we keep buttons for calling each dialog ? How much docker areas can you create? How do you create one ? What happens with keyboard shortcuts ?
I'm not sure about docker areas (never used them), but of course each dialog must remain a verb with its own button icon and shortcut, as they are now.
Multiple instances of the same dialog does not sound like a
good >idea
at all. I think it will be just confusing without any
advantage.
OK, so maybe a ctrl+shift+a shortcut could bring the align dialog in a new docker if it does not already exists. This way, you could still work as now, but w/ the ability to group several dialogs in one.
Yes, if the current behavior is more or less preserved (e.g. I can use the shortcut to open the dialog, or bring it to front if it's already open, and if the dialogs remember position/size) then I see no problem with them being dockable (if the dock sets are remembered too).
I was also wondering if we could split the fill dialog in 3 different dialogs, strarting in the same docker, but you could rearrange that, eg if you want to see in the same time fills and strokes ...
Yes, I thought about breaking it into Color dialog (two tabs) and Stroke dialog (single tab).