Saturday, 2 January 2010

The first JFrame and beyond ....

More reading reveals that the right way to do this for a Mac, is to create a main window which the menus are attached to. It then sits there as almost a main control window, so when a new score editor is created it gets added to the list of windows the app has open, so they get listed in a Window menu.

That main window though doesn't really have any content, we'd want the new score editor windows to be JFrames in their own right so they can operate independently. Where does that leave us with menus though? I can see with this concept of a main control frame, it owns the top level menu for a mac, and so things like File->New, Open and Quit, Window, Help etc all get managed via code in the associated class.

But each separate score editor window needs to have code which owns the Edit, Save etc menu items, ie the ones which impact the score itself. I know you can switch the code that gets executed from a menu when a window comes in context, maybe thats the way to do this, but thats menus for that JFrame, how does this work on a Mac where the menus belong to the main control window. Maybe it's irrelevant, and the whole menu comes in to context but inheritance means it can let the parent window handle the main control stuff and override the ones it wants. Bet there's a posh name for that in Java / OOP.

So perhaps the constructor for the main editor class builds the required system menus but the class for the actual score editors extend the main editor class and override the constructor, "knowing" the parent object will handle the main menu stuff. Hey I know what I mean!!

So you end up with JFrame derived object which is the main control window and it has many child windows, which are also JFrame derived, because you want them all to be operate almost independantly, ie so you can line them up against each other on the screen.

Maybe there's something other than a JFrame thats the right way to do this. Need to check. In the meantime there's no harm in cracking on and getting this up and running. Should even be OK on MS Windows I think, in that case the menus will just be in each JFrame.

It does leave us with this master JFrame, to which menus are supposedly attached which is just a window doing nothing. Maybe by not making it visible we can get over that but I doubt the menus will be shown at the top of the screen if the frame isn't visible. Hey maybe it doesn't need to be a JFrame, it just has code that is run by the concept of the main control objects menus, but they get run in the context of the child objects, which are JFrames. Problem with that is there might not be any open windows but the app should still run, ie the way the Mac apps work. Maybe I just say when we start up we create a New blank editor window, and if we ever end up with no windows open you just close the app? Not very Mac.

It feels like investigating having the main control process being a somehow non-intrusive or invisible window, ie just a menu - won't work on other platforms though - boo!

OK maybe I just build the app from the perspective of getting the editor class working, and worry about the wrapping later? Nah, can't put it off, it's too central to the whole notion of the thing. More reading and research I think as I still don't really get how to make this all hang together.

No comments:

Post a Comment