Hi Holly
I think that's an excellent idea. There's a rewrite of Theme.js in the
offing to push a lot more of the configuration out to file, but I don't
think it's going to be happening quite yet. And, of course, even when it
does happen it will need to start from a basis in which all the colours
are configured centrally from Theme.js. I'd suggest defining the colours
in Theme.js and then accessing them through methods/fields on the
ComponentAppearance.js. The general intention is that the theme defines
the parameters of the behaviour ("Disabled bundles are grey, active
bundles are mauve, services are yellow") and then the component appearance
defines a more specific set of characteristics for a given bundle ("My
colour is mauve, my text is grey").
I made a start on that last night and moved three bundleOutlineColors to
Theme.js - I'll work through Component.js today and move every hard
coded color
to Theme.js. What do you think about line characteristics, eg thickness?
I feel they should probably move too.
Yes, I think we might end up with quite a lot of pain when we try and
improve the rendering. It's one of the downsides of moving more things to
be top-level components instead of anchoring bigger objects and more
behaviour onto the relationships - we'll need a much smarter layout
manager so that it can handle things like keeping services close to their
owning bundles instead of rendering them halfway across the screen.
Yes - the relationship between a service and the bundle that registers
it is different from other relationships though. I think it could be a
fixed length line? and possibly part of the service graphic rather than
a separate relationship object? Don't know - just a thought.
Zoë
