Re: View Hierarchies for apps like Quartz Composer
Re: View Hierarchies for apps like Quartz Composer
- Subject: Re: View Hierarchies for apps like Quartz Composer
- From: Graham Cox <email@hidden>
- Date: Thu, 8 Oct 2009 12:26:59 +1100
On 08/10/2009, at 11:03 AM, Darren Minifie wrote:
Hi Everyone
I've recently tried implementing a tool that functioned similar to
Quartz
Composer (the tool was for an entirely different purpose, and I did
not know
about Quartz Composer at the time). Basically, the user is
presented with a
canvas. On the canvas, the user can place squares that represent
components,
and these components can be linked together by dragging a line from
one to
another. While, I did get an implementation working, I felt it was
quite a
bit of hackery, and I'm wondering if anybody else has any experience
with
such a user interface? For me, the hard part was figuring out which
view
hierarchy the connecting lines belonged to. For example my view
hierarchy
was NSWindow --> Canvas --> Components. A connecting line from one
component to another didn't seem to fit as a subview of any one
component,
because its bounds were not within that of any single component -
they were
between components. My solution was to create a clear CALayer for
each
line, and that layer was owned by the canvas, not any component.
Whenever a
component was moved on the screen, the appropriate lines needed to be
updated as well. My solution seemed, to me, to have far to many
layers and
weak references.
There are many applications like this: OmniGraffle, Keynote (to some
extent), OpenOffice, Reason, etc. Is this type of interface so
common that
there are known "tricks" to solving the problem easier (I'm thinking
something analogous to a design pattern). Thanks a lot.
Hi Darren,
There are two issues here.
First, you need to model the connections themselves, in the abstract.
For example, it might make sense for an object to have a "connections"
property that contains references to the objects it is connected to.
It might also make sense for this to be divided into "outputs" and
"inputs", depending on what your connections represent and how you
want to manage them. This is purely at the data model level, and is
completely separate from how these connections are displayed in a
graphical representation of your model.
The next issue is how you then display the connections. This should
become a lot more natural once you have the data model actually
modelling the connections. For the connected objects themselves, you
might have an associated view for each one, or you might ask each
object to draw itself in which case it just draws its visual
representation into a common view. This latter approach is very
common, and will give better performance than having separate views or
layers for each object. The connections would do something similar -
each object could ask its connections to draw themselves. Doing that,
the question of "who owns the connections" in a visual sense goes away
altogether. The drawing proceeds naturally from the clear ownership
that exists in the data model.
So the short answer is - model the connections and the drawing will
tend to look after itself, or at least become obvious. You seem to be
trying to model the connections as views themselves, which is not the
right way to go about it.
By the way you could adapt DrawKit ( http://apptree.net/
drawkitmain.htm ) to do this (Mac only, not iPhone) - I don't provide
support for connections between objects out of the box at the moment,
but adding this is a relatively straightforward thing since it already
provides structures for modelling and drawing objects arbitrarily
distributed on a canvas, and interaction with the user.
--Graham
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden