Friday, 29 October 2010

and this means I need to do what exactly!

I have to document this here, otherwise I lose track of all the todos and tasks in the code - must look at eclipse task management stuff one day.

Next steps:

  • refactor component names to be PageLevelComponent (for ease of reading)
  • implement drag lock switch in the page level component
  • implement menu to toggle page layout mode (View -> Page Layout maybe)
  • implement border highlighting on main view panel when in page layout mode
  • implement snap to grid for page level components when in page layout mode
  • implement page level component border visibility based on mouse enter / leave when in layout mode
  • create ability to constrain the component resizing to certain directions only
  • create ability to always retain aspect ratio when resizing a component
  • implement image resizing within image component (retaining aspect ratio)
  • allow drop of images from external sources
  • get default serialization working for a score (save/restore the view)
  • get File -> New / Open, Save, Save As ..., Close menu actions working
  • implement drag images when DnDing, or at least the right size rectangle
  • figure out DnD cursors, only works on copy rather than move at the mo'
  • implement paper size metrics etc, borders / gutter etc
  • get a print infrastructure working (delivers PDF out of the box on a Mac)
  • implement export action, with pdf initially as only target, maybe png too?
  • implement app preferences handling, saving to user dir etc (paper type, fonts blah)
  • implement splashscreen on startup
  • figure out packaging, e.g. jar, mac app etc
Enough to be getting on with? Should mean the whole app infrastructure is in place up to the page level components. What's left after that is the interesting musical notation bits, which, when it comes down to it, is when we will have something beyond the extensible doc handling app the above should deliver.

Pause for breath

Reworked the code for the abstract base class that sits under the page level components, i.e. the text, image and score line widgets. Having taken reference from many different examples it needed harmonising a bit. Bottom line is I now have a component which sits in a JPanel which is DnD draggable and can be resized by the user. Still lots to do though and I stopped to think through how the mouse interactions were all going to work.

At the page level you want to be able to move those components around and drop new graphics or text in but you don't want them moving when you're manipulating the individual note elements, either dragging them about or creating a selection of a group of notes with the mouse by dragging a selection rectangle across the page. If the component which represents the score line is draggable then clicking and dragging within it's bounds would mean picking it up and moving it rather than drawing a selection rectangle - and how would the code tell the difference? Maybe the user was dragging the line about!

I thought of a couple of ways of approaching this. Firstly I thought we could set an "anchor" property on the line so that it locks it in place thus interpreting any mouse drags as select attempts This would be achieve by having a border which became visible when the mouse entered the component area which would hold the lock / anchor icon. User can then "unlock" the component and move it about, then lock when finished. OK, could work, bit of a funny sort of paradigm for a drummer to have to learn.

Next thought was to create the ability to lock all page level components. This could be achieved by menu action, or properties dialog of some sort. The paradigm then becomes "OK lay out titles, authors etc and any graphic logos etc, plus all the lines you want on the page then exit page layout mode and go into score editing mode" or words to that effect. I think that seems easier from a user perspective, i.e. consciously take an action to lay out the bits and pieces then switch to doing the score content itself.

I'm going to code up the latter one I think. Should be a case of setting a property in each page level component (of which there won't be too many) whenever the menu selection is made to switch modes. Could even put a special border or something round the page if in layout mode so it's easy to see.

Further thoughts included snap to grid functionality, i.e. when in page layout mode there's a faded grid in the background to which all component align themselves as they are being dragged (or more accurately as drop zones are tested by DnD). Could be interesting to figure out if that's something best implemented using a custom layout manager or if the components become aware of their position relative to the parent panels grid lines, i.e. code it up in the drop test function.

The component abstract class is becoming quite complex having to implement all the DnD interfaces, plus mouse handling and clipboard etc. Jeez not even gone anywhere near copy and paste yet! Or keyboard interface!

Am probably thinking ahead too much but the note elements could be implemented in the same way as Docs are in the swing text components ..... needs research as I've not really done anything with those components before, just read how they work.

Should probably post some of the component code up here to show how I've managed to make this work, seems to be a common problem on the forums. One thing I have had to stick on the backburner is zooming the view - turns out using AffineTransform is really easy to implement the scaling but you can't invert the scaling for mouse handling in the Swing DnD system - there's just been no thought put into that in the design of DnD or if there has, it's not apparent to anybody out there. Plan B is to iterate all components and apply resize ratios on zoom - expensive task in capacity terms as it's a piece of batch work that needs to complete before the user has a perspective again - think this is going to be one of those heavy GUIs when finished! Or at least until someone discovers how to make scaling a point and paint pastime ...

Anyway if anybody reads this stuff, and wants to see the code please just ask so in the comments.

Sunday, 17 October 2010

Rockin'

So the approach of start again in a streamlined way has really worked. Storing everything in objects derived from Swing components is working, we have the main panel up and running, can do text based objects, jpegs and other panels, although the panel within panel piece is going to take some time. It will represent the line on which notes and bars are stored, so it's a container, needs to be dragged around, it's a drop target, needs to be resizable, phew!!

Head down time ....

Friday, 8 October 2010

Dragging and Dropping

Cooking with gas now I think. Just implemented Java DnD in the template GUI app. Glad I wrote one of those as it's easier to model and try new techniques in something thats lightweight compared to the drumscore code. In fact, what's becoming obvious as I model ways of doing things is I can simplify the original code now I understand better how to use the facilities of Java and Swing. I'm not feeling very charitable toward the original code I was using as inspiration as it avoided using many of the native features and tried to slavishly follow MVC when Java / Swing doesn't lend itself to that paradigm.

I can feel some slashing and cutting through the drumscore code soon to grossly simplify. And I must stop getting distracted by trying to Apple Mac everything - must stick to the discipline that says write the basic app then add the bells and whistles. Discipline? Huh!!

Monday, 4 October 2010

Click! Eureka! Boom!

Sometimes it just happens like that. Not through any form of higher advantage, but it simply just comes together. In this case I believe it's come together as a result of the journey, of hand cranking attempts to implement function, not quite knowing how it all works, taking it to a serious level of frustration and detail. Then take a break. How many times has it happened for me like that - dive in deep, take a break, come back to it and with the right focus it falls into place.

I can now see end to end how to implement the software I want. I can now say I see how Swing can meet the needs of the gui I want to write, and without going off piste.

It's a recipe involving no layout manager (absolute positioning), JLabels as the the container for text items and with custom painting they can host the notes and other elements too. JPanels can host the lines, or bars or however I want represent them. Swing Drag and Drop with custom dataFlavors will implement most of the drawing needs.

One last little bit, perhaps even the desire to store in XML can be handled to through XMLEncoder although I have to figure out the Beans stuff first before design can seriously get under way.

Think I'll freeze the code I've built so far, and start a new project from scratch using the lessons learned and perhaps even reusing some of the better code from the trials and tribulations to date.

Happy days

Sunday, 3 October 2010

And we're off again

Good progress, removed the control window stuff and turned that into a form of application controller object for all the stuff that needs to be maintained centrally. Also added code to cascade new windows and add a serial number to each new window as per style guides.

Seemed to get up to speed fairly quickly with the app, the overall structure of it and it's all a bit more familiar than when starting it up 9 or 10 months back.

Next is the widgets in the document, need to get a strong framework for them in place