Tuesday, 29 December 2009

high level overview

Going to restrict this to be very simple, if I had a clue about what I was doing with object oriented GUIs we would call this post the design :-)
  • Create a JFrame for everything in main(), then run the New score event.
  • The New score event will usually be triggered by a File->New menu action. It will close any open score, then create an empty one.
  • The Open score event will be triggered by a File->Open menu action. It will close any open score, create an empty one, pop up a dialog to have the user select a file, then read it into the empty score. A future option might be, if a filename is specified on the command line run the open processing.
  • The Close score event will be triggered by a File->Close menu action. It will close the current file asking the user if they want to save it if the score has been changed.
  • The Save score event wil be triggered by a File->Save menu action. It will simply save the open, edited score to it's original filename.
  • The Save As score event will be triggered by a File->SaveAs menu action. Will prompt the user for the new filename, saving the score to it, rename the current open score to the the new filename.

Given we don't really know what the Edit and View menu's need to have on them yet, we're not really sure what events will be required, and so don't know the processing required.

The score class itself is the model central to everything. It will store the elements which define the score, e.g. title, style, eg strathspey, author then a list of musical attributes, e.g. a time signature, bar start, group start / stop, note start, crescendo start / stop, unison start / stop.
Each note will have attributes, eg accidentals (drags, flams), accented or not
Given the purpose of the app is to edit and print manuscripts, the model has to also store attributes which define where the elements in the list should appear on the bar lines. Also needs to define how many bar lines per page the author wants, whether its landscape or portrait.
The score class needs to know how to save itself to disk, and how to populate itself from a file.

There's a view needed to appear in the app so the user can actually visualise the contents of the model. Whenever the contents of the model change it will tell the view.
Need another view I guess (wish I knew how to design GUi apps properly!!!) to render for printing to a PDF - that can come later when I've figured out how to create PDFs, ie I know what we need lol!

The other concept is there's a controller which can send edit actions to the score, e.g. setting current insert point, selecting elements, cut and paste, insert a new element, change the attributes of an element, basically act upon all the elements of the model. This is going to need much more thought but will include events triggered by menu commands and mouse gestures!

No comments:

Post a Comment