I want to have two textbox be "glued" together, say the left side of one to the right side of another, so that: * When I move one of them, the other moves with it; * When I resize one of them, the other moves for the gluing to still be respected; * When I rotate one of them, the other also rotates around the same axis, for the gluing to still be respected. Grouping two objects achieves the first goal, but not the others - and in fact makes them somewhat more difficult as you have enter the group and mess around with its overall area.
Also relevant to Draw.
Related enhancement request: bug 147542. To me, would be a welcome addition. Object borders and points already "snap" to each other depending on settings in View > Snap Guides, but having a keyboard modifier to "glue when snapping" would be interesting. I can see how grouping is an independent concept to the idea. Marking as new, but adding Design/UX team to CC.
Makes not much sense to me. Text boxes or frames are means to place content at exact x/y positions while using multiple columns in one text box gives a lot of freedom for any other layout. Ultimately it is question of ODF and I doubt sticky objects in terms of A follows B are defined. But you may group objects and such a group behaves as wanted. => NAB/WF
(In reply to Heiko Tietze from comment #3) > Makes not much sense to me. Text boxes or frames are means to place content > at exact x/y positions while using multiple columns in one text box gives a > lot of freedom for any other layout. But I don't think this is only about text layout. I was more imagining using it for complex plans and diagrams. > you may group objects and such a group behaves as wanted. Eyal mentioned in the Description that his points 2 and 3 are not covered by groups (cases of one shape following the other when only one is moved/resized), but I think point 3 is actually already covered, given that the pivot point can be moved to anywhere. I guess it would only make it marginally more convenient (e.g. quickly rotating the two shapes using the default pivot point of one of the shapes). But admittedly, this sounds like a complex feature to develop, when _most_ of the use cases would be covered by the existing groups.
(In reply to Heiko Tietze from comment #3) > Makes not much sense to me. Text boxes or frames are means to place content > at exact x/y positions while using multiple columns in one text box gives a > lot of freedom for any other layout. I don't see how this comment relates to this bug: * This bug is not about textboxes, it's about all objects. * This bug is not about initial placement by the user, it's about changes (including of placement) to objects without direct user action on the objects. * This bug has nothing to do with columns... are you sure you're commenting on the right bug? 8-\ > Ultimately it is question of ODF That's paradigmatically false. That is, it's true that some features require changes to the ODF. However, they can be acknowledged as desirable or necessary features before the ODF spec has changed, along with an implicit or explicit petition to change/add to the spec. (In fact, sometimes they can even be implemented as editing-session-lifetime features which aren't persisted in the ODF, but I'm not suggesting that for this enhancement.) > You may group objects and such a group behaves as wanted. It definitely does not, as I will elaborate in a reply to Stephane. > > => NAB/WF
(In reply to Stéphane Guillou (stragu) from comment #4) > Eyal mentioned in the Description that his points 2 and 3 are not covered by > groups (cases of one shape following the other when only one is > moved/resized), but I think point 3 is actually already covered, given that > the pivot point can be moved to anywhere. Good point about setting the pivot point, but - it doesn't quite cover point 3, because: I. Once object are grouped, the pivot point will not snap to relevant points within the object of interest. The only way to set the point correctly would be to get the exact size & position of the shape (which in itself may have a bit of a precision problem, see bug 152079). II. Whenever you want to perform another rotation - you need to perform the whole procedure of setting the pivot point again. So, even after you've gone to all the trouble, III. The pivot point is not relative to the group, but to the slide/page. So if you move the grouped object, or if you resize an object within the group, or if you resize the whole group - you can't even rotate again around the center of the _same_ object. So - it is not marginally more convenient, it is significantly more convenient...