Re: [jazzplusplus-devel] how to port mididelay dialog to new system?

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

On Thursday 25 March 2004 05:07 am, Patrick Earl wrote:
> On Wednesday 24 March 2004 16:27, joakim verona wrote:
> > I can design the xml resource,  but where should the rest of the
> > code go, in the new improved layered design?
> >
> > this is what it currently looks like:
> >
> > tCmdMidiDelay, a command class that acts on the track structure.
> > Should this go into a "kernel" dir?

I'm envisioning a jppTrack object that stores the tracks and each track's 
selection.  In fact, I'm probably going to start in on that class tonight.  
You would access a given jppTrack through the gProject instance of 
jppProject.  I've got several ideas for that, I'm curious to see how they all 
play out when I get coding.  :)  In any case, I'm thinking that the way it 
should work is you query the jppTrack for data, either the selected data or 
the entire track, then you get a const pointer to that data.  You do whatever 
you're going to do to it by moving it from your const structure to a new 
structure, and then you commit the new structure and the jppProject class 
will organize the new data.  The idea is to preserve the history of edits and 
stuff and ultimately allow unlimited undo, even across multiple saves.

> I haven't thought about the whole command / project structure, so
> anyone is pretty much an expert compared to me.
>
> > tmidiDelayDlg, a dialog class. Should it be broken out, and put in
> > the dialogs dir?
> > Or, since the code will be trivial, just handled in a function?
>
> I've been trying to answer that question myself, but I haven't come to
> any conclusions.  I do think it would be nice if the bulk of the
> dialog code could be placed in the dialogs dir in many small files.
> That said, the dialogs often need to execute some sort of code
> related to the window they were spawned from.

I don't see any reason this has to remain so.  If you consider that everything 
is an "Action" or a "command", then there should be an interface in the 
jppProject class for performing actions or commands.  So you open your 
dialog, get data from the user, then pass that data to jppProject and tell it 
to execute this action or that command or whatever, and jppProject does the 
execution.  It can use callbacks or events to inform the GUI about its 
progress so the GUI can draw progressbars and so forth.

> One possible solution is to have the dialog act independently, but
> have it call a function defined in an interface.  See
> tButtonLabelInterface for an example of how tMouseCounter interacts
> with the piano window through an interface.   If interfaces were
> used, the dialog file would contain the interface and any code for
> the dialog itself.  The main source file would implement the
> interface in the form of a function, performing whatever
> manipulations were necessary.  In fact, if the interface was
> implemented by something in the kernel, an upper level class could
> simply hook the dialog and the kernel code together though the
> interface.  Am I making sense?  Do I sound sane?  If you think my
> ideas are flawed, I really want to hear about it.

The last half of the paragraph is exactly what's in my mind.  :)

Dave

>        Patrick
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> jazzplusplus-devel mailing list
> jaz...@li...
> https://lists.sourceforge.net/lists/listinfo/jazzplusplus-devel

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

History is on our side (as long as we can control the historians).