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!

Monday, 28 December 2009

Getting there

And why I ask myself, just develop it with the menus in place for a standard swing app and then figure it our later .... no, last attempt at this went down that route with it developed in a windows MDI style which doesn't work at all on the mac, so, continuing to try and figure out something that works for both, then develop the payload.

Got Xcode installed, then finally found a link that said /Developer/Extras/Java, lots of reference code being studied!

Wednesday, 23 December 2009

Hmmm, app level menus

So reading since last post, it seems in the Swing library, menus hang off a JFrame, in the Mac world an app has menus, and if its focus they appear. How do you do that if there's no frame, because the frame is there when a doc object is created.

Probably an easy answer somewhere but the same reading tells me that trying to do this with Eclipse is OK, but Xcode is the Apple dev env, and it comes with examples of how to answer all of life's problems, or at least, the ones I know about at the moment.

I am thinking one day I'll read this back and wonder why it wasn't all so obvious!!!

Sunday, 20 December 2009

So where to begin ....

Looking for the software to have menus that behave as you'd expect,  i.e. if there's no score window open, then there's just the basic menu items needed:

-> Preferences
-> Other standard Mac stuff
- New
- Open
- Save (dim)
- Save As (dim)
- Quit

When a score object exists and has the current context then the menus need to be extended to include those items necessary for a score. Need to go think this through.

Day 1

Well not exactly day 1. For over 10 years I've been wanting to write this piece of software. I've started twice and finished neither. What did I learn? Walk before trying to run. I was trying to do too much in one go, so simply put, my goals for the first cut are:
  1. Learn to write a GUI in Java properly. I've dabbled here and there and never quite got it
  2. Be able to create new, save and open existing files containing drum scores
  3. Export a drum score to a high quality PDF file. Leave the complexities of managing printers to someone else for now
The drum scores themselves must be complete, i.e. any time signature, handle anacrusis, highlighted chips (forte), irregular groupings etc etc.

What I'm not going to do is figure out lots of cross-platform stuff, but I will write this on a Mac so tier 1 platform is Mac and I'll make it work on Windows afterwards. The plan is to do Mac things like put the menus at the top of the screen, use Mac lingo like Quit instead of Exit etc.

Having started on version as an MDI application I've learned that's absolutely the wrong thing to do, tabbed panes is probably right, but not for now - if I build the software correctly, then the objects should be able to live in a tabbed pane container later, once we're over the basics.