posted 22 years ago
The complexity of this undertaking depends greatly on the complexity of your interface.
How many windows are we talking about? Fixed set? Arbitrary? How many types of windows? How many types of actions?
Let me explain a bit about what my company's software has done.
Our product interface was somewhat akin to a web browser. You could visit all sorts of content in different locations. Each type of object you could browse had a set of similar actions, but then also aditional actions unique to that object type. Some objects were container-like, which displayed a tree table.
The menus in our menu bars had to be enabled/disabled not only based on what you were looking at, but also on various permissions you have, and (more trickily) what items were selected from (for example) a tree table.
Our original design involved defining Actions that went along with the various GUI-level panes (as opposed to the data cache objects), so that they could be sensitive to GUI issues such as selection. It was easy to make the Actions (and menu items created from them) enable/disable themselves in popup menus, because those were also defined in those classes.
It was harder to hook up these actions to the main menu of the frame. We did this by creating an Actionable interface and some top-level JPanel subclasses that implemented this, and then derived subsequent panes from that. Then, when a user opened a new object, there was a series of calls through each conceptual GUI layer to get the set of Actions, map it to the main menu, and listen for changes in selection (and other events).
This worked for a while but was a little painful to maintain, because we had to provide call-through methods every time we added a GUI layer in between the top-level parent pane and the specific object pane. It was also a pain (pun intended) to hook up user-defined actions written with our plugin API by customers or internally to the main menu.
We later changed to a totally different framework.
First of all, our interface switched to more of a windows explorer/web browser combo (tree on the left, browsable content on the right). The menus had to be sensitive not only to what the selection was, but also where the selection came from.
We implemented a Global Selection Tracker which could be queried for the currently selected object(s), and could be listened to for changes (including active window changes).
We implemented Dynamically Propertied Components, which is a fancy way of saying that you could sum up various properties from various objects together.
Basically, the system uses the GUI containment hierarchy (e.g. one JPanel is parent to another) to go through every component and gather all of its actions.
So instead of being tied through conceptual classes, the actions are delivered to the main menu via global selection tracking and component hierarchy utilization. This system is certainly more advanced to code, but much more flexible and maintainable in the long run, and friendly to user-defined actions.
I wasn't the one who implemented it, so I don't know too much more detail as to how it works.
Hope this gives you some ideas.
Bill
