-
One of my two main uses for arrows is to point at some line of text within an object. Currently the only way to do that is to manually create a magnet and position it at the beginning of the line of text. However, when I resize the object, then all the magnet points no longer point at the line of text I wanted. ARGH! Now I have to manually reposition tons of little magnet points every time I want to resize an object. THIS IS SUPER ANNOYING. Please change it.
-
My other main use for arrows is to point from a specific spot on an object to a specific spot on another object. I use magnets to get my arrow itself to go as close to completely horizontal or vertical as possible, and/or to maneuver it through the empty space between other objects. However, if I resize an object, the point where the magnets attach changes EVEN ON SIDES OF THE OBJECT THAT HAVE NOT MOVED! So for example: create two boxes, and draw a flat line connecting the right side of the left box to the left side of the right box. Now, drag up the middle resize point of the top edge of the left box to make it taller. Even though the right side of the left box is not changing position in the L-R dimension, the arrow connecting to it still moves upwards relative to the new vertical size. THIS IS SUPER ANNOYING. The magnetic anchor point should NOT MOVE if the side that it’s on is just growing or shrinking but not actually moving. Magnets should only change their absolute position relative to the canvas if the object is being moved, but not if it’s being scaled. Or at least, there should be a “thumbtack” mode for magnets that makes them stick into the canvas at that point, and moving an object would be the only way to shift their positions.
A couple of screenshots ?
One solution to this kind of thing can be a script which automates the creation of composite shapes, with the magnet points and other characteristics that are needed, by grouping visible (and invisible) elements.
PS if you don’t need to update the text – just resize the shape – it might be worth experimenting with Copy As PDF and then Paste to get PDF versions of your text shapes.
Less directly editable (can still be edited through linkback), but might have better resizing behaviour for your application.
Here are two shapes converted to PDF, and grouped with small invisible circles placed on the letter ‘e’, with a link between the circles.
OK here’s what I’m talking about. When I resize the lavender-colored box, making it taller/shorter, all the arrows that connect into the right side of that box change their positions. The dashed arrow even changes which magnet it’s connecting to!
See what happens is that I start diagramming the flow of messages between classes and methods in our app. As we make changes I update the diagrams and often they become more complex over time. When that happens, I need to make some parts of the diagram smaller so I can fit more stuff into the diagram.
For example here I might want to make the lavender-colored box shorter so that I can squish all the other boxes inside it closer together.
Expected/Desired Behavior: I should be able to make it shorter down to the center of the cyan-colored “if YES” box, without having the magnets on the right side of the lavender box change their positions. When I pull down the top of the lavender box, the uppermost magnet on its right side (with the solid line connecting to it) should only move when the top edge of the box hits the place where the magnet is. Then, the magnet would be in the upper right corner of the lavender box.
Subsequently, the magnet (or “thumbtack” if we need to make a new feature) would “remember” where it was originally put down in terms of absolute canvas coordinates that would only change if the whole box gets dragged somewhere.
When a drag operation occurs then the “remembered” absolute canvas coordinates of all magnets would be translated by the same number of measurement units X and Y as the box was dragged.
That way, I could make the lavender box so short that all the magnets were in its corner, then drag it somewhere else on the screen, and then make it twice as tall as its original height—and after that, all the magnets would still be the same exact number of pixels from the bottom edge of the lavender box as they were before anything was changed.
Or is there already a way to do that? I don’t want to make things into PDFs because that will make them non-editable and I need to retain the ability to edit everything.
I’ll take a closer look over the weekend, but a quick first response to:
because that will make them non-editable and I need to retain the ability to edit everything
That’s what I thought too, but turns out that they do remain editable – clicking on them takes you to a link-back editing window.
In this arrangement, shown with View > Magnets checked, the horizontal arrows are attached to magnets not on the lavender block itself, but to magnets on an invisible block (no fill or edge) on a layer below it.
What you just showed is not a solution to my problem. The point is that it takes too much extra time to hassle with magnets the way they are now. If a feature was implemented as I suggest, it would then save me that time.
However what you are suggesting makes me do even more steps than I already am: now I have to create some box in the background and connect things to it; I can’t easily select those magnets or make new ones because they’re on a different object than the one I want it to appear they are connecting to; and it just becomes far to complex and convoluted.
I need to work fast and simple. I want to make shapes, put points on them for arrows to connect to, then resize the shape in one dimension and not have the connection points change position relative to the new height of the box—I want the arrow’s absolute screen position to take priority.
Right now, in the current version, even if I lock an arrow it still moves when I resize the box because its magnet moves, because the magnet’s position scales with the scale of the object—even though I have “no scaling” checked in Inspector > Object > Geometry. As far as I’m concerned that is not expected behavior and therefore it’s a bug. Why should “no scaling” lead to magnets’ positions scaling?
Maybe the solution is to add a “scale magnets position” option to the Geometry scaling pop-up menu. So basically for any given object, you would be able to set a preference on that object to determine whether magnet positions scale with the object, or not. If set to no magnet scaling, the, I described in my post above, the magnets would stick in the corner of the object trying to get as close to their original position as the object’s current dimensions would allow (a position to which they would restore themselves given the opportunity).
Understood.
Possibly some of that could be accelerated or semi-automated with a script, but equally, needing to fiddle with scripts can often be symptomatic of using the wrong tool …
Yep. I was mainly posting this here as a feature suggestion for the devs.
One thing is with non-square shapes I’m not sure how you could change the behavior other than making the magnet try its best to maintain its current position rather than trying to scale with the shape—but it would still move unless the point of scaling was set to anchor at the magnet. As far as I know, OmniGraffle does not allow the user to change the anchor-point used for scaling, like, say, Illustrator does.
I was mainly posting this here as a feature suggestion for the devs.
May be worth noting that in recent exchanges with OmniGroup they have defined this as an essentially customer ⇄ customer forum, back-pedalled a bit on a suggestion in the help file that members of staff are likely to take part, and emphasized that emails to support are the channel that actually gets read.
If you would like this to get into the request Intray, (or even read by staff at all) I think it might be prudent to use OmniGraffle > Help > Contact Omni
Warning • Not Suitable for those with a Short Attention Span
[quote=“Jon, post:1, topic:25112, full:true”][/quote]
AFAIC the problems you are experiencing are cause by two categories of issues. Let me take them in a sequence that reduces typing.
II Misunderstanding or Imprecision
OG5 is a very fine drawing tool, less than perfect because the maintenance is poor, and the features are short-sighted, but still leaps ahead of the competition. The product is the way it is.
What you think should be, and should not be, are not bugs, they are the way the Magnets work. Deal with it. Some large number of users are quite happy with the way magnets work, etc, and we definitely, positively, do not want it changed.
Now you may want them to work some other way, and that is fine, but that is an enhancement or option or new feature, etc, not a bug. Submit them as desirables, and certainly discuss them here.
-
Bug 1
I agree that a line that is locked, should be locked on the magnet that it is connected to. -
Bug 2
Likewise a shape that is locked, should not have have any connected lines move to other magnets, when other shapes are moved.
The rest are misunderstandings or imprecision or not understanding the characteristics of objects and how to manipulate them for your use. It appears you do not have experience with Groups: purpose-built simple objects, grouped together.
No. There are many ways. It depends on how much experience you have with OG; with Standards; what you are drawing; simple objects or complex ones (grouped, purpose-built objects); etc.
First, that is poorly conceived (the way you conceive the problem, your concept, is incorrect).
No. You are failing to differentiate the fact of the shape (that contains text) and the text, and the fact that you want to manipulate each, and separately.
So really, you want two objects: a shape and a text-object.
-
Give the text-object two magnets are East & West
-
Connect the lines to the text-object, not the shape
-
Size the shape to the text-object (plus a margin)
-
Position the text-object over the shape
-
Group the shape and the text-object
-
If you want lines of text to be separate, so that each line of text can have its own magnets, make each line of text a separate text-object.
There, the need for super-annoying magnet manipulation is eliminated.
That is too imprecise to deal with. Additionally, it contradicts your statements re what you want when the shape is moved:
-
Magnets are points in the shape, not on the canvas. A Magnet in a shape is not an “anchor” point. It is a point that lines can connect to.
-
It appears what you want is not absolute to the canvas, but relative to the shape (that the magnets are in)
-
That in addition to the Magnets (the behaviour of which we do not want to be changed), you would like Thumbtacks
New Feature Thumbtacks
A Thumbtack is similar to a Magnet, but it retains its relative position in the shape, ie. it does not move when the shape is resized (whereas a Magnet does move when the shape is resized).
-
There are limits to that
-
Eg, when the shape is resized to be less than the max-Thumbtack area … the Thumbtacks that are [now] outside the shape would be lost. So the minimum resize area for the shape would be the maximum Thumbtack positions. (Delete the Thumbtacks such that you can resize the shape even smaller.) Etc.
-
In your example, you are resizing the shape by moving the top edge, and you want the magnets to retain their positions relative to the bottom-right. However, most people would want the positions relative to the top-left, and they would move the bottom-right handle.
-
Again, I think if you connected your lines to the text-objects, rather than to the shapes, your problem would be greatly reduced, if not eliminated.
No. Moving the Thumbtack positions (within the shape) would be the only way to shift their positions relative to the shape. Moving the shape moves the Thumbtacks that it contains because it is part of the shape (pedestrian).
Nevertheless, Thumbtacks are a great idea. Add it to the Wishlist.
-
I would be happy with simple Thumbtacks, relative to the top-left of the shape, and the min resize area being the max Thumbtack area.
-
If you want the full quid, you will need to request a DropDown for other relative positions; checkboxes to retain Thumbtacks that are beyond the shape size; etc.
I Substandard Diagram
This is actually the more important category of issues, and dealing with it properly will greatly ease the pain overall of drawing and maintaining these diagrams. Ie. each pain point will be eased, and the sum total ease will be greater overall. I gave the second category first, because you clearly want the OG issues addressed with priority.
-
Your diagram is substandard, and grossly so. It starts with UML, but actually it is a mash-up of UML plus a Flowchart, plus Notes, plus triggers, plus …
-
Now I understand perfectly, that UML is a dog, and a legless one, that it is not useful as defined. That it is not a standard by any stretch of the imagination. That in order to make it even somewhat useful, one has to add various bits and pieces (one single symbol plus a million notations does not a Standard make). Which you are doing. But you have gone way beyond what it acceptable for a technical diagram, you have several different UML diagrams, plus non-UML, all on the one page.
-
So the first recommendation is to separate the different types of UML diagrams, and draw one per page. The Classes and Methods have to be separated.
-
One of the principal notions of a standard is that the symbols are the same shape and size (noting of course that in UML, the height will vary). If you break basic rules, the diagram will be hard to understand (for others), and that breaks the reason for the diagram in the first place (communication with others).
-
Failing that, draw a few (not many) UML diagrams on one large page, and add connections.
-
But do not mix non-UML with UML. Draw the Flowchart as a separate diagram.
-
Some of your shapes should not be shapes, they should be labels on lines. Eg. “If YES”.
UnitTesting
-
should be a completely separate version; model; diagram-set; binary. For sanity reasons, if not diagram reasons. Especially when external Methods (again, UML cannot describe such) are used, or external corporations are used.
-
Add a tiny notation << externalFoo >> , rather than a set of symbols.
Composition/Decomposition
Where UML (and all OO notations) fail, totally and completely, is: it has no notion of composition/de composition.
-
You have realised that Inheritance is quite different to composition. Great.
-
Which is one of the many reasons high-end practitioners use an honest Standard such as SSADM (DataFlows) or IDEF0 (Function Model). Each of them have full decomposition.
-
So here you are, trying to add what UML is ignorant of, and has no semantics for: decomposition.
-
But you are doing that by butchering UML symbols.
-
For decomposition, it would be much easier if you chose a Standard, all of which have decomposition, and the diagrams for complex object models are very easy to understand.
-
That would completely eliminate your resizing of butchered UML symbols, and the problems consequent to that.
Summary
To sum up, use a Standard, and use it within the confines of the Standard, do not exceed it. The result will be several pages that are easy to understand, rather than one page that shows too much, that is difficult to understand.
-
When you find yourself fiddling with low-level items every time that you have to change the diagram, that should be a red flag to you, that you have done something wrong at the higher levels.
-
I am not saying that OG is the wrong tool, rather that you have not thought things out; your symbols or groups are not correct; you have exceeded a Standard.
Complex Single Diagram Regardless
Failing that, if you insist on drawing a diagram in OG that has too much complexity, that uses butchered UML symbols plus plus, use Layers.
-
One layer for Classes; another for Methods; another for the Flowchart.
-
In addition to making connections between the correct objects (described above, at the top), this will ease your pain further.
