>> >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
