My SF name is o__b

Done, you can commit your code now. Welcome to the team! :)

...

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?

Looks weird to me, and could be surprising for the user. But I understand the need for such a functionality. If we generalize a bit, this would be distributing groups of nodes. But this is hard in terms of UI.

Yes, what I propose is a subset of "distribute groups", and yes, fully generalized "distribute groups" is difficult to implement and may be overcomplex in terms of UI. Which is why I propose this special case - I think it's very common in practice and pretty intuitive once you get used to it. Just think of it as nodes "snapping together" when they're on one horizontal or vertical, so that distribution buttons treat them as a whole. This may be switched off by a checkbox in the align dialog (on by default, with the state remembered across sessions in a preference value).

...

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?

I'm not sure to understand what it means. Just throw each node on an random position, or keeping the order and randomize the step size, or even distribute against a distribution function (gaussian, poisson, etc.) ?

In fact there may be many various approaches to randomization, but for practice, what I think will be the most useful is two buttons: Shake and Shuffle.

1. Shake: Each selected object moves by some small random distance from its current position. Here a Gaussian distribution would be appropriate, so that small displacements are more frequent than large ones. The default radius might be 0.05 of the total span (span == the distance between the outermost selected object), with this value ("the force of the shake") settable in preferences. Shake may sometimes change the order of objects if they're close together, but normally it will not. If you need a stronger shake, just keep pressing the Shake button.

2. Shuffle: All objects are placed at random points within the entire span between the outer objects. This does not preserve the order of the objects, but shuffles them like cards in the pack. For example, if you have a row of equispaced objects and you want to change their positions randomly but keep the equispaced distribution, you press Shuffle and then Distribute equispaced to space them evenly again.

Note: it is obvious that the overall span of the objects will keep getting narrower if you press Shuffle repeatedly. I'm not sure if this is a problem that we have to live with, or it makes sense to try to compensate for it by artificially expanding the span before shuffling so that, _on average_, the span stays the same across many subsequent shuffles (it's an interesting mathematical problem, by the way - how much we need to expand the span for this condition to satisfy).

Also note: in the above, "objects" may be nodes (in node tool) or object centers (otherwise); I don't think we need separate shake/shuffle buttons for left/right edges. However, when calculating the span, it makes sense to measure it between the outer edges of the bboxes of the outer objects, not between their centers.

Let me know what you think of this plan.

Done. I'm just wondering why so many enums are anonymous and you pass plain ints as parameters ?

No idea, maybe just Sodipodi legacy...

...

...

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.

OK, I'll look at this.

Obviously what needs to go into that class is all the standard global variables in all dialog files (x, y, w, h, dlg, etc.).