Re: [jazzplusplus-devel] More selection stuff

[joakim v. <jo...@ve...>]

I still havent considered all the issues with selection, but just to 
give you some feedback,
I think selections should be separate entities, and there should be one 
instance in
jppProject, item 2 in your list.

One thing that would be useful with a better selection mechanism is
undo or change of specific operations made on a track.

For example, to be able to select a number of note-on events, apply a 
midi echo
operation on them, and later go back and change the midi echo settings 
on the selected events would
be useful.

So maybe thats not exactly like your item 2... I can see that there 
would be a number of problems
with such a selection scheme, to persist it you would need some way to 
identify events uniquely,
which serialization would solve, but I kind of dont like serialization. 
Anyway, its just an idea.

/Joakim

Dave Fancella wrote:

>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
>
>  
>