Correct. But perhaps you are misusing the friend
concept. Are these
friend classes so closely related that they cannot use some public
interface?
as i said above, the interfaces are not public. they are intended to
be restricted just to the specified other classes.
This means that all these classes are very tightly coupeled.
they are. in fact in some cases, they started out as private classes
of the Editor itself. when they were moved out (for greater
compilation independence), they ended up as friends because, as
stroustroup notes, private class types are just implementation aids,
not conceptually distinct objects. hence, the TrackView class is a
full bona-fide friend of the Editor.
well, it was. that's all about to change as the nature of the problem
has changed and/or become more visible, and we can now see that a
TrackView is not really just an implementation aid but something more
standalone than that.
This probably isn't easy but I think that it may,
besides improving the
compile time, make the code more readable. Also, perhaps a better
seperation from the user interface code would be possible.
well, the editor is *only* about user interface. everything in
ardour/gtk is about user interface. there is no back-end there at all
- thats all part of libardour. the editor defines policy (which mouse
actions cause which operations), it defines how undo/redo is done, and
is controls drawing during and after operations. it doesn't contain
any implementation of any operation at all. so i think there is almost
total separation already.
remember: there is complete and enforced separation of UI and backend
in ardour. no part of the backend knows about any kind of UI at all. i
know its not unique in this sense, but it just bears repeating.
--p