Tuesday, 13 April 2010

Squashed a bug

As I add functionality, it exposes bugs in the code I started with. For example the attributes dialog for a text item was good, the implementation was tested, however it highlighted the way I was changing text attributes by using deriveFont was flawed, as it remembers the attributes from before.
Implemented the right click menu infrastructure in the software, looking good, so started writing actions, starting with one to create a new text item. Was interesting as I wasn't sure how I was going to do it from a menu item as I couldn't answer the question "how do I know where it's location should be on the page". Answer was implement a first-click infrastructure by storing an action away in the mousecontroller to execute, ie user says Insert Text, mouse cursor becomes a crosshair, next click causes configure dialog for a new text item to show at that point. Simples - I expect more bugs from this later as it gets exploited more!!

Friday, 9 April 2010

Coming together

Abandoned my hand-crafting of zooming the view when my knowledge levels got sufficiently high to understand AffineTransform. Now all the drawing bigger or smaller is handled by the graphics library. Some tricky bits around scaling the drawing canvas and margins etc but all done now.

Things on the to-do radar include:
  • configure text item dialog box (bold, underline etc)
  • pop-up menus (right click)
  • more work around constraining movement of text adornments, still "sticky" in places
  • file open / save dialogs and code (will we use xml as the format????)
  • new score dialog, let's discuss!
Currently a new score is created blank with only one feature - the title text adornment. Question is do we want the user to manually insert staff lines or an initial dialog which lays out the number requested? My opinion is we code up context sensitive menus which allow insertion of new bar lines. The Insert menu item can be created for the top level menu too, inserting a new staff line at the start of the list if empty or before the current active staff line, i.e. the insert point is before the current object.

You'd expect a replace functionality too, ie if a whole staff line was selected, then a new one would replace it. Not sure that's important as you're unlikely to want to lose the contents of an existing selected staff line. Must go and look at my music theory notes too as I want to get the names right.

Also prominent by omission is the ability to choose portrait or landscape. That's just a code it up issue, i.e. if it's one and you want to go to the other do you shrink / stretch spacing between notes as appropriate? Probably not that many lines of code but it's going on the laterz list.

Saturday, 3 April 2010

Preferences version 1

Simple dialog box now in place, got tied up trying to replicate the look and feel of the pref dlg in Eclipse, confusing my inner being with GridBagLayout etc. Enough already!! Job is to get a working app going then prettify it.

Decided not to allow change of orientation at the moment as it raises too many questions and therefore probably lots of code! If you change the shape of the page then all the objects on it need realigning to fit within - code code code. So am going to do a New Score wizard dlg that asks this at creation time and that's it. So we're restricted to 1 page and get the orientation right at creation time. I wouldn't pay money for that.

Back to the main app now, dlg box for changing properties of a text widget can come later. I think I've decided the score graphic objects on the page will have their real world dimensions translated to logical page dimensions (using dots per inch) when they are loaded up so they are always stored in ready to use dimensions. Should take the overheads off zooming, moving etc. I really want to solve the moving problem I have at the moment where if the mouse moves too fast off page the last few moves aren't sent to the app. Perhaps making it quicker to process the moves will help. Certainly putting additional unit conversions on the critical path won't help.

So the only time real world units get used for say the distance between notes is when saving to disk, and of course converted back when read in. Let's see what that decision brings us!!