…stances.
- A single instance of the applet will always manage all windows on all monitors
- More instances, if placed on separate monitors, will manage windows only on that monitor.
- A window list on the primary monitor will always manage all windows *not* managed by secondary
monitor instances. (like, whatever is left over)
- Multiple instances on the same monitor currently results in two applets with identical behavior.
- Dragging windows from monitor to monitor will remove/add appropriately from the applets.
- Currently DnD only works within an instance - you can't drag an item from one instance to another.
I'm not convinced this behavior makes sense, as it would result in the window jumping from one
monitor to another. I'm open to discussion though.
- Removing/adding panels, monitors and instances should update everything appropriately.
- Other-workspace alerts will occur on the same instance as the alerting program would display
on if that workspace was active.
unsolved: the role provider system needs a little tweaking, so traditional minimization effect
can work on the proper window list (it currently only works on one instance, the rest use the
fallback effect).

- Added "infinite" to max-instances in metadata.json - which sets no
practical limit on the number of applet instances you can have.
- Updated many stock applets to be multi-instance capable.
- Fixed applet settings code to clean up obsolete single-instance config
files, so you don't end up with phantom tabs in your applet's configuration.
Notable appplets not updated, which will need more work to be useful in multiple
instances and/or panels
- Window list - should be able to configure between handling only its own monitor's
windows, or the entire screen (current behavior), when there is more than one
of it. Window entries also need to be able to jump to other instances when their
window is moved to its window. Ensure DnD of panel items makes sense (should only
be able to drag within its own instance I think). Figure out how to handle
'traditional' transitioning for mapping/unmapping of windows from their appropriate
window list instance.
- Brightness - should control multiple monitors, or just the monitor it's on?
- ??

Spring branch cleaning...
With this, some basic things like popup menus will be read if orca is running.
Code should now be in place to add support to more complicated items
(like the menu applet, etc..)
Note one issue is that orca does not currently stop itself short if you
change items before it's finished speaking, as it does in gtk. It simply
queues up the items.