Re: [Rosegarden-devel] OK, you were right...

[Guillaume Laurent <glaurent@te...>]

On Saturday 16 February 2002 19:33, Chris Cannam wrote:
> BarButtons is a composite thing at the moment (an hbox containing
> vboxes, for some reason, each of which contains a label).  We need
> to decide whether we're going to give it any actual buttons; if
> not, it might as well be a simple widget like LoopRuler.

This reminds me : since I now know that there isn't any problem with 
displaying regular widgets over a QCanvas, this means that we can make the 
various loop and position pointers widgets, which should also considerably 
simplify things (no need to deal with their interactivity at the EditView 
level).

-- 
					Guillaume.
					http://www.telegraph-road.org

Re: [Rosegarden-devel] hey

[Chris Cannam <cannam@al...>]

Richard Bown wrote:

> I overrode [MappedComposition::]clear() to explicitly
> delete the MappedEvent members and then clear down the iterator (which it wasn't
> doing before - ouch).  This worked fine and so I added the clear() to the destructor
> and this appears to be the problem. 


No, I think that's fine.  I think your problem is a bit more
complicated than that.

Check out RosegardenGUIApp::getSequencerSlice.  This gets a
pointer to a (shared) MappedComposition from the SequenceManager,
and then it expensively copies the whole thing when returning by
value only to see the result streamed out via MCOP and then
thrown away.  That seems wasteful, but it's not the problem --
the problem is that MappedComposition has no copy constructor,
so the return by value does a shallow copy and when the copied
version is destroyed, so is the integrity of the original.

At least, I think that's the problem.

Obviously you could write a copy constructor (and should anyway,
or else declare it private) but mightn't it be better to return
a pointer from getSequencerSlice and then have a stream operators
that take pointer rather than reference arguments?  Or I suppose
you could return a reference from getSequencerSlice, whatever.
There surely must be a construction that works well with MCOP
without having to copy the entire thing just after making it.

btw, your MappedComposition::operator= has the classic C++
interview-question bug: if you assign a MappedComposition from
itself, you lose the lot.


Chris

Re: [Rosegarden-devel] OK, you were right...

[Guillaume Laurent <glaurent@te...>]

On Saturday 16 February 2002 19:33, Chris Cannam wrote:
>
> As a comment of mine notes (trackeditor.cpp:139), the horizontal
> QHeader is not even used for any real purpose any more (it's been
> superceded by the RulerScale).

Yes, I'm about to remove it.

> BarButtons is a composite thing at the moment (an hbox containing
> vboxes, for some reason, each of which contains a label).  We need
> to decide whether we're going to give it any actual buttons; if
> not, it might as well be a simple widget like LoopRuler.

Let's look at that when we're done with tidying up around.

> That apart, I'm pretty much in agreement.  I don't think it'll
> conflict much with anything I'm intending either.

OK.

-- 
					Guillaume.
					http://www.telegraph-road.org

Re: [Rosegarden-devel] OK, you were right...

[Chris Cannam <cannam@al...>]

Guillaume Laurent wrote:

> We maintain 
> two headers (a QHeader and a TrackHeader) just for size computing purposes


As a comment of mine notes (trackeditor.cpp:139), the horizontal
QHeader is not even used for any real purpose any more (it's been
superceded by the RulerScale).

> 		BarButtons


BarButtons is a composite thing at the moment (an hbox containing
vboxes, for some reason, each of which contains a label).  We need
to decide whether we're going to give it any actual buttons; if
not, it might as well be a simple widget like LoopRuler.

That apart, I'm pretty much in agreement.  I don't think it'll
conflict much with anything I'm intending either.


Chris

Re: [Rosegarden-devel] OK, you were right...

[Guillaume Laurent <glaurent@te...>]

On Saturday 16 February 2002 18:53, Guillaume Laurent wrote:
>
> Theoretically, we should have only this :
>
> MainWindow
> 	Grid
> 		TrackButtons
> 		BarButtons
> 			LoopRuler
> 		TrackEditor
> 			SegmentCanvas

Make that :

MainWindow
	TrackEditor
		SegmentCanvas
			TrackButtons
			BarButtons
				LoopRuler

-- 
					Guillaume.
					http://www.telegraph-road.org

[Rosegarden-devel] OK, you were right...

[Guillaume Laurent <glaurent@te...>]

The whole main GUI is a mess in dire need of refactoring. Before worrying 
about signals, the whole widget tree is just too damn complex. We maintain 
two headers (a QHeader and a TrackHeader) just for size computing purposes, 
even though we don't show them. There are QScrollViews all over the place for 
no good reason either, etc...

Theoretically, we should have only this :

MainWindow
	Grid
		TrackButtons
		BarButtons
			LoopRuler
		TrackEditor
			SegmentCanvas

I'd like to take on with that, which means heavy editing in these files 
should wait a little.

Do you guys agree ?

-- 
					Guillaume.
					http://www.telegraph-road.org

Re: [Rosegarden-devel] SegmentCanvas restructure

[Richard Bown <bownie@bo...>]

Chris Cannam wrote:

> I guess it's mostly helpful for people who program more by
> intuition than methodical rigour.  I'd rather like to hear
> Bownie's opinion, 'cos he's the very model of an intuition guy.

Erm.  Well I've kind of gone the crap way - I've used signal.. and
slot.. when I'm reusing the name in a class and haven't worked out
how get around the horrible mess I'm about to create.  Also I think
somewhere along the way I have a basic misunderstanding of signals -
do they just percolate up like exceptions if you don't explicitly
connect them or do you _have_ to connect them at every layer they
pass through?

If the former then things could certainly become a lot easier almost
instantaneously.
 
> (btw, for some reason I have more of a problem with slots
> than with signals -- I'd be happy to see all the slots called
> slot-blah even if the signals weren't called signal-blah.)

I think we should be consistent - I do tend to agree that we should
use the signal and slot names at the beginnings of the relevant 
methods.  Although for a neat, short little method name point of 
view it doesn't look very elegant it does make us think about 
where we're using them.

R

Re: [Rosegarden-devel] hey

[Richard Bown <bownie@bo...>]

> Is it me, or does something to do with setPointerPosition prevent
> the thing from building in the first place?

I'm going to move setPointerPosition to doc now anyway and get rid of
that nasty signal business which was a horrible hack anyway.  We'll
see if that clears it up.

R

Re: [Rosegarden-devel] hey

[Richard Bown <bownie@bo...>]

Chris Cannam wrote:

> Looks like a buffer overflow to me.  It's in an allocator,
> possibly the "new EventData()" in the Event constructor; the
> data otherwise appears to be sound; it happens unpredictably.
> I think a malloc chain has become corrupted.  Have you
> recently made changes to the way memory is allocated and
> filled when sending mapped event slices, or some such?

I have - probably wrongly - in MappedComposition.  I overrode clear() to explicitly
delete the MappedEvent members and then clear down the iterator (which it wasn't
doing before - ouch).  This worked fine and so I added the clear() to the destructor
and this appears to be the problem.  If you remove the clear() from MC's destructor
then everything starts working - but are we not leaking?

R

  M.C. Destructor

Re: [Rosegarden-devel] SegmentCanvas restructure

[Guillaume Laurent <glaurent@te...>]

On Saturday 16 February 2002 12:47, Chris Cannam wrote:
>
> > I'm working on how to put widgets the rulerscale above the scrollbar
>
> Groovy -- and it'd possibly be a good idea to do the same thing
> with the top LoopRuler as well,

That was part of the plan. And the tracks sidebar too. I've found how to do 
it, it's actually quite simple, just put the widget where you want it to be 
and it works.

> because presumably that way we
> could more easily ensure it was the right length (at the moment
> it stops scrolling a bit before the canvas does) and keep it in
> sync with the canvas scroll without those signals.

Yup.

-- 
					Guillaume.
					http://www.telegraph-road.org

Re: [Rosegarden-devel] hey

[Chris Cannam <cannam@al...>]

Chris Cannam wrote:

> Yes, fascinating.  It's not at a predictable moment, but it
> always does it.  Hmm.

Looks like a buffer overflow to me.  It's in an allocator,
possibly the "new EventData()" in the Event constructor; the
data otherwise appears to be sound; it happens unpredictably.
I think a malloc chain has become corrupted.  Have you
recently made changes to the way memory is allocated and
filled when sending mapped event slices, or some such?


Chris

Re: [Rosegarden-devel] hey

[Chris Cannam <cannam@al...>]

Richard Bown wrote:

> Is it me or is the GUI crasing in setPointerPosition after a few notes of playback?

Yes, fascinating.  It's not at a predictable moment, but it
always does it.  Hmm.


Chris

Re: [Rosegarden-devel] SegmentCanvas restructure

[Chris Cannam <cannam@al...>]

Guillaume Laurent wrote:

> signals are always used with 'emit', and having a 'signal' prefix in 
> front of their name would be really cumbersome.

Yes, and of course you don't have to give them definitions --
much of the problem is in knowing how the method will be used
when you're editing the .cpp file rather than the header.


> I'm working on how to put widgets the rulerscale above the scrollbar

Groovy -- and it'd possibly be a good idea to do the same thing
with the top LoopRuler as well, because presumably that way we
could more easily ensure it was the right length (at the moment
it stops scrolling a bit before the canvas does) and keep it in
sync with the canvas scroll without those signals.


Chris

Re: [Rosegarden-devel] hey

[Richard Bown <bownie@bo...>]

> Is it me or is the GUI crasing in setPointerPosition after a few notes of playback?

Actually even if I get rid of the dodgy looking QObject stuff in SequenceManager
I still get a spang at getElapsedTimeForRealTime() in setPointerPosition().

R

Re: [Rosegarden-devel] SegmentCanvas restructure

[Guillaume Laurent <glaurent@te...>]

On Saturday 16 February 2002 11:16, Chris Cannam wrote:

> There are a few reasons I can think of why that naming scheme
> is useful:
> [....]

I don't particularly disagree with any of these, plus we're already halfway 
there, so let's bite the bullet and go all the way. It would be better to 
wait for the code to stabilize a little first, and that we've reviewed all 
the slot/signals for possible removal.

> (btw, for some reason I have more of a problem with slots
> than with signals -- I'd be happy to see all the slots called
> slot-blah even if the signals weren't called signal-blah.)

OK. signals are always used with 'emit', and having a 'signal' prefix in 
front of their name would be really cumbersome.

BTW, I'm working on how to put widgets the rulerscale above the scrollbar in 
matrix and notation view. This could also be applied to the track editor and 
would also help reducing the number of signal/slots firing around.

-- 
					Guillaume.
					http://www.telegraph-road.org

Re: [Rosegarden-devel] SegmentCanvas restructure

[Chris Cannam <cannam@al...>]

Guillaume Laurent wrote:

> On Friday 15 February 2002 21:31, Chris Cannam wrote:
>>in segmentcanvas.cpp; it seems overkill to have all the tools emitting
>>signals that are simply re-emitted by the canvas
> 
> these signals would better be directly connected to the track editor.

I thought so to, but it wasn't apparent to me how to do that
without putting lots of junk into SegmentCanvas or telling the
tools about the TrackEditor, both of which would be nice to avoid.


Chris

Re: [Rosegarden-devel] SegmentCanvas restructure

[Chris Cannam <cannam@al...>]

Guillaume Laurent wrote:

> The pb with signals is that they make it non obvious to know what 
> happens next, but how they're used is fairly unambiguous.

There are a few reasons I can think of why that naming scheme
is useful:

  -- You need to know whether a method is a signal or slot or
     neither, because if it is, you can't change the signature
     without silently breaking the connections.  (And it took me
     ages to work out why none of my signals was working, when
     all I'd done was put the Rosegarden:: namespace prefix in
     the header but not in the connect call...)  You obviously
     can find out if a method's a signal or slot by scanning
     back through the header, but a naming scheme is clearer
     especially with headers like notationview.h that have
     dozens of slots.

  -- We sometimes have the same method, or similar methods,
     appearing more than once but only sometimes being a slot:
     a nasty example is TrackEditor::addSegment which appears
     as a DCOP call and a slot, although that example is one
     that should probably die anyway.

  -- If your slots are all called slot-something, you have a
     bit of a head start in resolving the "what happens next"
     problem because at least you know it's going to be one
     of those slot things.

I guess it's mostly helpful for people who program more by
intuition than methodical rigour.  I'd rather like to hear
Bownie's opinion, 'cos he's the very model of an intuition guy.

(btw, for some reason I have more of a problem with slots
than with signals -- I'd be happy to see all the slots called
slot-blah even if the signals weren't called signal-blah.)


Chris

Re: [Rosegarden-devel] hey

[Chris Cannam <cannam@al...>]

Chris Cannam wrote:

> Is it me, or does something to do with setPointerPosition prevent
> the thing from building in the first place?


Oh, forget I asked, of course, it's going to be that stupid, stupid,
stupid, stupid, stupid, stupid, stupid moc thing that means I need
to run the configure script rather than just clean and rebuild.
Sorry.


Chris

Re: [Rosegarden-devel] hey

[Chris Cannam <cannam@al...>]

Richard Bown wrote:

> Is it me or is the GUI crasing in setPointerPosition after a few notes of playback?

Is it me, or does something to do with setPointerPosition prevent
the thing from building in the first place?  Lots of

/home/cannam/rosegarden/gui/rosegardengui.cpp:1120: undefined reference 
to `Rosegarden::SequenceManager::getTransportStatus(void) const'

and virtual table, and similar.  I did a make clean and rebuild
yesterday (I think -- the machine crashed at some point, but I'm
pretty sure that was after the make clean).


Chris

[Rosegarden-devel] hey

[Richard Bown <bownie@bo...>]

Is it me or is the GUI crasing in setPointerPosition after a few notes of playback?

R