werner, thanks. this may give me some valuable clues. seems i've
already started to re-invent the wheel with my own Application /
AbstractApplication / AbstractWindow / WindowHandler / Document /
DocumentHandler classes ;-) but the menu factory thing remains
unsolved so i'll have a closer look at your approach!
the list of problems with menus which i currently have is:
- track focus of document frames so helper palettes change their
content depending on the "active document"
(this already works for multiple-windows mode, for internal frames
mode the focus tracking isn't yet working)
- maintain a window menu with all active documents as a mutex
jcheckbox menuitem
(this already works with a mechanism to automatically update all
menu copies)
- maintain a view menu with checkable items that must be updated for
all menu copies
(this already works)
- have a mechanism to populate one screen menubar with different
menus that are copied to all
menu-enabled windows where no particular windows "knows" about all
menus but gets a copy
with greyed-out items that do not relate to this window
(this kind of works but the implementation really sucks at the
moment)
- be able to share common menu items although their action changes
depending on the window
(typical case : the edit menu with cut / delete / copy / paste)
(this kind of works but the implementation sucks as the
menufactory needs to know about all
these special items and isn't sufficiently abstract / independant)
- now with switchable config between multiple windows (mac os) and
internal frames (windows / linux)
a mechanism to distribute some menus to the outer window, some to
the internal frames.
(a suggested by miguel, maybe the easiest is to stick to one menu
on outer jframe and ignore
the jinternalframes so i'll have to switch the menubar according
to window focus tracking)
- be able to create items in menus and their copies dynamically
(some plug-ins can be created through OSC clients and menu items
have to be dynamically
created very much like document items in the windows menu)
(doesn't work yet due to some architectural misconcepts)
- disable menus for some windows according to their state (e.g. one
document is rendering stuff, so the menu
should be disabled ; when i switch to another doc, the menu should
be normally accessible)
(kind of works but the implementation sucks)
as far as i can judge, these should be common problems for multiple
document applications so it's really strange there isn't any
readymade solution in java for these as the amount of work to get all
these things running is quite high.
if someone has a framework that handles all these things, that would
be really nice. otherwise i guess it's a job of one or two days
(including modification of all classes already existing). but i was
just curious whether people on windows (i don't have a machine at
hand now) expect menus to go to the outer frame or the internal
frames (and in the latter case how to split them up).
best, -sciss-
Am 27.08.2006 um 13:18 schrieb Werner Randelshofer:
Hi Sciss,
I am working on an application framework for JHotDraw/PlasmaDraw
that supports MDI, SDI and the OSX document interface.
The framework makes heavy use of javax.swing.Action objects. Here
is a rough overview over the framework:
- Application knows how to present actions and project windows on
screen (e.g. using a single menu bar or using multiple menu bars,
and using JFrame or JInternalFrame)
- ApplicationModel knows which action can be performed for all
projects and knows how to create projects
- Project knows which action can be performed on the current
project only, and it knows how to present the content of a project
The framework comes with default implementations for applications
and for commonly used actions, such as actions for opening and
closing files, undo/redo, and copy/paste.
ApplicationModel and Project need to be implemented again for each
concrete application.
I don't know, if this framework is appropriate for your
application. But it might be a good starting point.
Especially, because I put some extra effort into the OSX document
interface. ;-)
Best regards,
Werner
On 26.08.2006, at 17:59, Sciss wrote:
what are the strategies for cross platform menubar design in
multiple document interface applications?
at the moment i'm trying to get rid once and for all of the stupid
multiple-windows versus internal frames problem. instead of
subclassing frames i'm using a window factory now which makes it
easy to switch between both modes:
while on mac os x i have used the strategy to make duplicates of
one common menu bar (using screen-menu bar) with different menus
enabled or disabled depending on the focused window, this strategy
obviously fails for menu bars attached to windows.
in multipleframes.jpg, you can see that "regular" windows get
copies of the same menu bar (the main window and the soundfile
waveform window) and floating palettes (the control room palete)
don't. but maybe one shouldn't duplicate all menus here?
in internalframes.jpg, the problem is even bigger. i assume that
standard internalframes applications use one menubar for the outer
frame and context specific bars for the internal frames. but what
happesn for example with the file menu? attaching the menu bar to
the outer frame requires me to disable the fie menu when no
document window has been focused. but maybe the timeline menu
should only be visible in the document frames not in the outer
frame, and maybe the view menu should go in each internal frame
and contain context specific items only?
thanks for suggestions
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
