On Saturday 14 June 2003 00:42, Chris Cannam wrote:
> On Friday 13 Jun 2003 10:31 pm, Guillaume Laurent wrote:
> > OK, I've reviewed it.
>
> Splendid. Then we're in complete agreement. Or...
>
> > - "developping out" the x,y coords from ViewElement to
> > NotationElement and MatrixElement. Frankly this one appears totally
> > ludicrous to me. You have the same properties in all the child
> > classes, why not moving them to their common ancestor ?
>
> Because that encourages people to do things like you were just doing:
> using the layout x/y as if they meant something.
But they do, even if it's only in the child classes. It doesn't make any less
valid that they should be in the base class. It's just an interface question.
QCanvasItem defines a couple of methods (setSelected(), setEnabled()) which
explicitely have no meaning for the base class, they're here just so that
children classes can give them one. Think of it as pure virtual methods if
you prefer.
> (To be honest I don't find this point particularly distasteful in
> principle. I probably wouldn't complain about it, except that you
> appeared to have done it _solely so that you could do something
> wrong_, namely treat the layout coordinates as if they were canvas
> coordinates. That suggests something very bad about the practice,
> don't you think?)
No, that suggest I wasn't sure about which one to pick and got the wrong one.
The factoring in of the layout coord is still very much valid. It's actually
not relevant to the ControlRuler design anymore.
> > - insisting on the ControlRuler being a Segment observer rather
> > than a ViewElementList observer. I thought we had agreed this
> > wasn't the right way to go.
>
> ??
>
> You posted an email about it. I don't think I replied at the time.
You said in another email that you "just discovered the reason you
describe in your previous email for why you added the view element
observer", I thought you'd come to agree with me on this point.
> You have a point here though. I'm not happy with my version here
> either. (Tangent: when you first implemented this, the
> SegmentObservers really couldn't be relied on to be called in a
> particular order. I changed that, following your lead with the
> ViewElementListObservers, by making the ObserverSet a list instead of
> a set -- that way the order is guaranteed.
Actually I used a std::list here only for performance reasons, because a
std::set is overkill for such a small amount of items. I didn't even consider
the question of calling order.
And while it's true in theory that a list will guarantee a calling order, that
order is dependent on when each observer registers itself. Good luck on
debugging (and, even worse, fixing) a problem there.
> still.) However, I do think (as I said in another email) that you
> want StaffObservers rather than ViewElementListObservers.
That I agree with.
> > I really don't understand what you find wrong with the idea of a
> > ViewElementList observer.
>
> Well actually, I was thinking about it this morning and I wasn't sure
> we needed two separate classes for ViewElementList and Staff at all.
> Why not just Staff as subclass of both multiset and SegmentObserver?
> This is also a logical conclusion of the comment I added at
> Staff.C:85 when fixing that bug yesterday. What am I missing?
Hold on, we're not talking quite about the same thing here. I advocate a
ViewElementList observer as opposed to a Segment observer, not to a Staff
observer. I don't particularly mind a Staff observer. I agree that an
observer mechanism isn't especially fit with a very simple class like
ViewElementList.
> The ViewElementList is a funny class, it's gradually become
> marginalised to the point where it doesn't actually do anything other
> than be a container and receive delegations from Staff.
Yes, but I wouldn't be too comfortable with discarding it and having only
"ViewElement" and "ViewElement aggregate + Layout semantics". Too much of a
gap here, a "ViewElement aggregate" class is needed.
--
Guillaume.
http://www.telegraph-road.org
-------------------------------------------------------
This SF.NET email is sponsored by: eBay
Great deals on office technology -- on eBay now! Click here:
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
_______________________________________________
Rosegarden-devel mailing list
[EMAIL PROTECTED] - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
