Guillaume Laurent wrote:
> Well, that's the whole point of signals : you emit them without caring what
> happens afterwards. I'm not sure we're talking about the same thing here,
> looking at segmentcommands.cpp I see no signals involved.
No you're right but have a look at m_document->deleteSegmentItem(m_segment)
in SegmentInsertCommand::unexecute. That method call subsequently calls
all RosegardenGUIView::destroySegmentItem(Rosegarden::Segment* segment)
which then emits a signal down to the SegmentCanvas.
The new Segment or the one to be destroyed are the only things being passed
so in effect this is the same thing as emitting signal from SegmentCommand
and having it caught by the thing that creates or destroys SegmentItem.
Ok, it's isn't as elegant but then again at the moment to make that connection
work you would have to connect signals to signals from rosegardenguidoc through
all possible views, through track editor to segmentcanvas.
This is what I was on about when I was saying that the TrackEditor/SegmentCanvas
is just a big trunk route for multi-stage signals. Signals are just about the
only way in and out of SegmentCanvas at the moment and because it has to be a
two way street (we create Segments from SegmentCanvas and from RosegardenGUIDoc)
it's getting packed in there.
Now there's nothing much wrong with this except that it's very complicated to
follow let alone explain.
Anyway, don't expect any more unreasoned rambling today as I'm off to Birmingham
for an interview in a minute (ouch) and then to see RMS do some rambling of his
own in Mile End tonight.
BTW I've just checked in a new segmentcommands.cpp which means that Segment undo
works better but still crashes occasionally.