[jazzplusplus-devel] More selection stuff

[Dave F. <dav...@co...>]

All,

Ok, I went to implement selection finally, and hit another wall.  ;)  
Basically, it's the 'how' that's getting me.

I intend to implement it in a fashion that isn't dependent on the tracks 
appearing in any specific order, so that the GUI won't have to know how the 
project organizes the tracks and vice versa.  I figure the GUI needs to be 
able to layout the tracks in a more or less arbitrary fashion.  So here's the 
options as I see them:

1.  Each track has its own selection.  There would be methods such as 
"HasSelection" in tTrack, SetSelection, and ClearSelection (with SetSelection 
automatically calling ClearSelection), GetSelection, GetSelectedEvents, and 
so forth.  The main disadvantage here is that selection code will be spread 
out and jppProject will have to go through and clear every track when making 
a new selection.  The main advantage (and it's a big one) is that there would 
be a GetSelectedNotes method added to tTrack that would return a list of midi 
events contained in the selection.  The other methods require 
GetSelectedNotes(track) to be part of jppProject, which they arguably don't 
belong there.

2.  jppProject stores selection.  The big advantage here is that all the 
selection code will be kept in one place and tracks don't have to know about 
selection.  The disadvantages depend on implementation.  I figure there's two 
ways to implement this.

2a.  A list of tracks that are selected with a single Filter object storing 
the position/duration of the selection.  In this option, you'd have 
SetSelection in jppProject which would ClearSelection and set the 
position/duration of the select.  ClearSelection would clear all selection.  
AddSelection would add the selection to a track, so the GUI would have to 
iterate through all selected tracks saying "AddSelection(track)".

2b.  A list of tracks that are selected with position/duration as part of the 
list.  The main disadvantage here is that SetSelection would be 
SetSelection(track, beginning, ending) and the GUI would have to explicitly 
call ClearSelection every time a new selection is made.

3.  This is the most transparent and also the least.  :(  You pass a list to 
jppProject containing a track identifier (currently numbers), beginning and 
end of selection for each track to jppProject, and jppProject stores it 
however it wants (easiest to just copy the list to internal members to start, 
but could easily be changed later on).  Probably create a jppSelection class 
for this to manage the list.  SO the GUI would create a jppSelection 
instance, then SetSelectionPosition(start, end) and AddTrack(track 
identifier).  When it finishes making the list it would call 
jppProject->SetSelection(mySelectionObject) and jppProject would handle it 
from there.  It's the most transparent because the interface doesn't reflect 
how it's stored, but the least transparent because the GUI maybe shouldn't 
have to deal with a jppSelection object, it only needs to give start/end 
times and tracks.

Of the options I've come up with, I'm favoring 2a, which would provide the 
simplest interface, but not necessarily the easiest code to read.  It also 
doesn't provide complete transparency to selection to the GUI, but I think it 
would satisfy the needs, in any case.

I also intend to move the global Filter object into jppProject.  After 
selection is rewritten, I don't know if we'll need a global Filter object, 
but I can't justify getting rid of it completely.  Never know, and it might 
be a damn useful thing to have around anyway.  :)

What do you guys think?

On another note, I don't recall if I mentioned this or not, I made jppProject 
inherit from tSong.  So everywhere you call the global tSong should be 
changed to call the global gProject, and it should 'just work'.  That 
simplified making a track interface in the jppProject class without having to 
stupidly rewrite all the code to do it.  :)  We should be able to 
re-implement as needed to support whatever new backend we want for the thing, 
and ultimately get rid of tSong.  We may never need to get rid of tSong, 
though.  SO I didn't see a point to re-implementing the track interface, 
anyway, since my goal was to just put it in jppProject, not necessarily 
rewrite it.  ;)

Dave

-- 
Visit my website!
http://www.davefancella.com/?event=em

Sign my PETITION.