Seems like a minor thing, but it's quite a surprise when it happens. Selecting arrows in a group leads to them all being disconnected. That should not happen. A group is a more virtual object than that, and should just adjust itself when its components are changed due to connections. This may entail a rework of how groups work. It might also be nice at the same time to allow groups that do not remove the object ordering. -- LarsClausen - 19 Mar 2004 More thoughts on groups: Currently, grouped objects are replaced by a single group object. This means that they can lose depth relationships with other objects. E.g. if objects A, B, C overlap and that order, then when A and C are grouped, the order becomes B, (A+C). Later ungroup makes it B, A, C. This is not really acceptable behaviour, grouping should be transparent to object ordering and vice versa. Fixing this requires a full rethink of how grouping works -- basically, it should be much more like parenting, rather than an object of its own. However, saving must still work in the same way as before. -- LarsClausen - 22 Mar 2004 Here's a major change from the old group scheme:Grouping should be done with parenting.
A group is simply an object that can parent, has only its handles as physical representation, and that grabs selection from its children. This has the following advantages:A few disadvantages, though:
- Only one grouping scheme in Dia.
- Grouped objects are still in the diagram (see problems with bezier selection)
- Simpler load/save functions.
- Grouped connections don't need to be broken off.
- Groups can easily be opened/closed.
- Groups become more real objects that can have extra functionality.
- This would solve the reordering problem (of grouped objects losing their stacking relative to non-grouped objects).
However, it is entirely likely that someone would want to have a group with some but not all objects parented. This ought to be legal. So instead of each object having a parent, it should have a list of parents. Nothing odious about this, it'd have to check bounds and selection against each of them. It would also mean that an object can belong to more than one group, giving rise to a slight problem of what group gets selected when the object is selected. We could just disallow overlapping groups till we figure that out (though groups within groups would be fine, the inner group would just become a parent of the selected objects, and the outer group a parent of the inner group). It's easy to check if a grouping is legal, just see if all objects have the same parent group. Comments welcome. -- LarsClausen - 18 Sep 2004
- This entails a major change in the save file format, requiring tools to be updated.
- The XML save files don't show the structure of groups explicitly, only through 'parent' relationships. Though explicit ordering disallows an object belonging to multiple groups.
- The importers/exporters that understand groups will need rewriting, too.
| Edit -:- Attach -:- Ref-By -:- Printable -:- More |