The Omni Group
These forums are now read-only. Please visit our new forums to participate in discussion. A new account will be required to post in the new forums. For more info on the switch, see this post. Thank you!

Go Back   The Omni Group Forums > OmniGraffle > OmniGraffle General
FAQ Members List Calendar Search Today's Posts Mark Forums Read

 
Connecting objects on shared layer and normal layer Thread Tools Search this Thread Display Modes
It does not seem to be possible to create a connecting line between an object on a normal layer and an object on a shared layer. Or am I overlooking something?
My application is a diagram which contains optional elements, ie, elements I want to be able to hide. Multiple Canvases would be neat for that but these optional elements connect to other, always present, elements. And since the connection lines overlap other elements, I currently need four layers to achieve this.
Top: optional elements
Second: standard elements
Third: optional connections
Fourth: standard connections

I guess this would be a feature request for a future version.
 
This is correct, connections between regular layers and shared layers are not allowed, seeing as the shared layer can show on other canvases, and connections to objects *not* on those canvases would make layout particularly difficult.
__________________
"Vroom! Vroom!!"
 
Seeing that connections to objects on other layers (also hidden ones) are possible, connections to objects on shared layers would require that each canvass contained all layers (or all layers with objects that have a connection to something on a shared layer) albeit in a hidden form. I can see that this could become noticeably more complex from a computational point of view (also from UI PoV).
 
Hello,

I seem to be missing the point in having shared layers then. What I understand is that you can only use them to share non functional objects between canvases - e.g. frames, backgrounds, etc. ?

I do not see the problem with allowing connections either, but that might just be me.
For example, let's call the objects on a shared layer when only looking (hypothetically, anyway) at the shared layer master objects.
The actual objects (those derived from the master objects) presented on the canvas we call derived objects.
These derived objects would inherit properties like appearance, size and location from the master object. When any of these properties is changed by e.g. resizing a derived object, this change would feed up into the master object and accordingly down into all derived objects.
There are however also properties that do not make sense to be shared between canvases - like connections. In this case the derived object should just act like a normal member of the canvas and store its e.g. information regarding connections with the local instance.

Does this make sense at all?

Best regards,
sth
 
This thread seems to have died but I'm fighting this issue right now. I'd like to echo the query as to what the value of shared layers is if you can only share non-functional components.

My group has a complex software topology to implement and we know only a handful of fixed components across four tiers of software. I'd like to put those components into a shared layer and have different canvases show multiple software design proposals with proposal-specific components connecting to the fixed components. I think this is a pretty compelling use case.

I would suggest that Omni limit the immediate redraw of connection lines for moving objects on (a shared layer in) the currently displayed canvas. You might be able to 'lazily' redraw other canvases with that shared layer in the background and light up a red dot or other warning marker if the object movement seems to disrupt another of these canvases. Then the user can go to that canvas and fix the connections.

Best,

Andrew Wolfe

Last edited by awolfe_ii; 2011-12-29 at 05:56 AM.. Reason: finish work
 
I second this request.

I have a few graphs, whose nodes are all the same. Hence it makes sense to put the nodes on a shared layer. The edges of each graph differ, so I put those on a regular layer. This means I can't connect my edges (lines) to my nodes (boxes). That's mighty annoying.

I do understand the issue: if I re-arrange the nodes on one canvas, not only do the edges on this canvas move along, the edges on another canvas should also move along. This may not be trivial to implement, but if it is implemented, it sure would safe me a lot of work making diagrams!
 
I'm attempting to do the exact same thing.

I get the issues about flow and would propose that the objects at least *act* like they're connecting (use the magnets, etc., from the shared layer). I would be okay having to manually correct the flow if I do something drastic, but to have nothing to hang a connection onto makes it almost a non feature except for frames and formats.
 
Here's a workaround I found...

Drop all of your nodes on the shared layer.

Draw all of the connections you need for your diagram version on the shared layer.

Select all of the connections and other objects specific to the diagram version.

Right click over the local layer and choose Move Selection to Layer.

This seems to drop the endpoints in the right place, etc. Naturally it won't move with your objects if you change the base layer, but if you're pretty sure where you want those objects to appear it should work pretty well. Just trying it out myself.
 
 


Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes


Similar Threads
Thread Thread Starter Forum Replies Last Post
Shared Layer Problem dpan OmniGraffle General 6 2013-01-06 01:09 PM
Change an existing layer into a shared layer Jor_is OmniGraffle General 8 2012-03-19 10:10 PM
Pasting into a Shared Layer PRV OmniGraffle General 1 2009-07-09 02:06 AM
shared layer functions leanbean OmniGraffle General 1 2009-05-21 05:30 PM
Change an existing layer into a shared layer Jor_is OmniGraffle General 0 2008-02-25 12:19 PM


All times are GMT -8. The time now is 01:31 PM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2024, vBulletin Solutions, Inc.