Remove Canvas::Layout, use Canvas::Container for the same purpose, move child-rendering into Item::render_children() so that it
could theoretically be used by any derived type.
The idea now is that a scroll group item can be added to the canvas which will causes its children to scroll in either or both
directions (horizontal or vertical). There are few complications: the position() of the ScrollGroup is ambiguous depending
on whether you want it with scroll taken into account or not, so Item::canvas_position() was added, which defaults to
the same value as Item::position() but is overridden by ScrollGroup to return the position independent of scrolling. This
method is used when translating between item/canvas/window coordinate systems.
Note that the basic idea is that we MOVE the scroll group when a scroll happens. This mirrors what happens in the GnomeCanvas,
where Nick Mainsbridge came up with a great idea that allowed unification of the time bar and track canvases.
This makes continued merges with ardour codebase easier, at the
small cost of removing the XML-based constructors. They were not
in use anyway and their use doesn't really fit into the
conception of the canvas as a dynamic UI element. Could reintroduce
them at a later date.
[Details] Important: On Mavericks Tracks could be successfully built with static library linkage so far.
Use --internal-static-libs flag configuring the build.
[Reviewed by] Partially reviewed by Paul Davis. Some Improvements may be promoted in future.
