Wednesday, 10 February 2010

Freakin' text drawing stuff

It got tricky - trying to make the text component in the model aware of the rectangle it sits within for hit testing for mouse actions. Took time out to read the J2SE Graphics2D tutorials etc, some other stuff on the now Oracle / Sun site. There's AttributedStrings, there's TextLayouts, there's simple Font and drawString, but there's nothing that discusses the best widget to use.

I've gone for simple Font and draw, using FontMetrics to get the real estate it covers. Unfortunately every widget I've looked at needs to have the graphics object available which is only there it seems on the draw method - not sure how to get it any other time so am using the opportunity when draw() is called to update some statics about size, rectangles etc.

When a string is drawn the coords aren't the top left of the logical rectangle it occupies but at the bottom left of the first character, but not quite the bottom, there's Ascent, Descent and other stuff I need to get more familiar with but needless to say there's some more complexity going in to the object to cater for this and maintain the concept of a hit rectangle with other adornments, eg jpeg etc.

Nearly there ....

Monday, 8 February 2010

Working on the mouse actions design

Thinking the objects in the model need to store their selected state, and when it changes fire out so the view knows to redraw. The object needs to know how to draw itself in a selected state too, so the user can see it's selected.

Maybe we need a Set which allows the editor to quickly navigate through which objects are selected, e.g. if user clicks the mouse with the shift key down, then the object at the co-ords gets added to the Set, aswell as changing its state. Then any action triggered, through either menu or other means is applied to all items in the Set of selected objects.

This then allows moving a number of items together for example, or deleting them. If all the items are of the same type then maybe we can format them to eg same font or size - adds tricky stuff so maybe v2.

Saturday, 6 February 2010

Mouse moves

Getting the mouse motion and clicks into the app turned out to be quite easy in the end - as always, once you know how. Got to think through the details carefully now of which objects should handle which actions and how, carefully separating the roles of the model, view and controller.

Have to say my hearts not in it right now, head is swimming with other stuff so this may have to take a back seat again for a while. Will see if I can concentrate on thinking it through at least, as a distraction to focus on something other than whats floating around in the head right now, a little relief maybe!

Monday, 1 February 2010

Focus on adornments

Here's where I have to set some design in stone for v1.

So adornments are all the non-musical elements that make up a score, i.e. text strings the user might use for say the author, a copyright statement, the title, the setting (march, strathspey etc), name of the band written for, date. Approach is not to dictate any requirement except the title, you got to have one of those!

The storyboard for a new score is to create an empty A4 document, give it a title of Untitled, define a distance from top of page for staff line start, and create 8 staff lines in portrait mode and hand it over to the user. (V2 note: define header area, footer area and implement ability to create more than 1 page; implement choice of paper size)

So what can the user do next? Select File->Properties to set page orientation and number of staff lines on the page. Warn user if number of lines reduced and it would mean deleting a populated line. If user increases number of lines (more than 8? good luck) then they'll be appended at the end and all the lines proportionally spaced on the page, below the defined header space.

Now adornments - we've already created one - the title string, which is located at a default position. User needs to be able to move it, change fonts, bold, underline, italic and of course change the content. Also will need the capability to create a new one!

Moving an adornment
User selects the adornment by pressing and holding the (left) mouse button down. Next the mouse is moved (while still holding the button down), and the adornment follows, i.e. dragged to the new location, as determined by where it is, when the mouse button is released.

Changing the content of an adornment
User double-clicks the adornment, dialogue box opens.

Deleting an adornment
User selects the adornment with a single click (enables Cut menu item), hits delete, backspace or Ctrl-X as accelerator to Edit->Cut menu item
User right clicks adornment, triggers pop-up menu, include Cut, Delete menu items
No difference between Cut and Delete in V1
(V2 note: implement undo / redo and Copy, Paste capability)

Creating an adornment
Not sure what menu item this needs to be on, e.g. Insert->Label->Text
User right clicks mouse button, triggers pop-up menu with Insert->Label menu items
Not happy with this! Seems clunky. If the create is triggered by the mouse then we have the location to create the adornment. From the menu, we need to think of where we create it - if we default to say somewhere need top left, the next thing the user needs to do is move it.
The create action pops up a dialogue box appropriate to the adornment type.
Am only formally supporting text adornments in V1, will include a jpeg logo adornment with in V2 or before if it helps build the code framework for extensibility. (i.e. factory methods which select class to create at run time)