[Bf-taskforce25] windowmanager issues

[Brecht Van Lommel]

Hi,

This is a list of things that I either don't understand or think need
to be changed in the window manager code and design. Some of this may
just be a matter of making it clear in the upcoming docs. It was
intended as a list of things to discuss with Ton, but I though I might
as well send it here.

* wm_apple.c: should be moved to ghost?

* Keymap storage: they are currently as ListBases in wmWindowManager. 
Maybe this needs a wmKeymap struct with name + the ListBase, so it's 
more extensible.

* There seems to be no way to specify "any key", or "any modifier key"
in keymaps.

* wm_event_system.c. "MVC demands to not draw in event handlers... for
now we leave it.". I think we should be strict here and not allow it.

* The exact function of the area/region refresh() callback is not
clear to me. comment says external bContext changes, but i'm not sure
what that means, also compared to init(). For example size changes
causes an init() call in which the area repositions regions so that's
not refresh(). Other things may be handled in listener(). So I'm not 
sure what kind of things that would be handled there.

* The area init() callback seems to be doing region registration,
setting up callbacks and such. Maybe regiontypes should get registered
with their callbacks, keymaps, etc more like for areas with a unique 
name in an initialization when Blender starts, not repeatedly?

* Will Panels be regions? Makes sense if you do this and then allow
regions to be free floating, or 'docked', etc. Maybe not a wm topic 
per se, just trying to think of what functions a  region would have, 
i.e. if a you would be able to drag them around, or tab them, add 
regions from a menu etc. Also if the regions can basically be opened 
and closed at will then you will need most code in the regions and not 
in the area because the area will know little about it's contents.

* Areas have spacedata, do regions need something similar? I've added
a void *regiondata; pointer since I needed it for the UI code, which
is used by the region. Should this be a list like spacedata (imagine
tabbed regions)?

* Modal operator context vs. handler. A transform operator wants to
handle events for the full window, blocking. However it still works on
the data in it's area/region. I've added a convention now that the
window/area/region where the operators was invoked 'owns' it as long
as the operator is running (in the modalops list) and will cancel it
if it the window/area/region is deleted. That may not be ideal, and
it's still not clear which window/area/region should be in the context
when the modal() callback is used, the one where the handler is or
where the operator was invoked?

* Operators vs. handlers. My initial interpretation of operators was
that they would be doing things that seem to be intended for handlers
instead. My idea of handlers was that they were just a way to 'hook
up' an operator somewhere and operators might keep running for a
while. Now i'm not sure anymore what would be a handler or an operator
or something else, for example: the timeline play, shift+p preview
render, autosave, opening a file dialog to set an image path.

* Operators have an interface with callbacks and defined lifetime, for
handlers this does not exist, so it's not that extensible currently
for python or for decoupling things. Think for example a verse
handler, continuous exporter for a game engine. Do handlers need a way
to make new handlers without changing the windowmanager code itself
like exists for operators?

* Timers, are they events, notifiers, or something else? Can a region
get a timer event for shift+p preview render, or is that a handler,
operator, .. ?

* Error reporting. I've added a way to report errors and warnings
generally and add them to a list in the windowmanager, this can be a
way to make that non-blocking, but it may not be ideal. Many places
that want to report errors or warnings may not have a
context/windowmanager pointer available.

* Notifier/listener. Still not sure about the types of notifiers that
will exist. Redraw and changed are clear to me, but what is the
purpose of an area_split, area_drag, gesture_changed notifier?

* Notifier/listener. How can we avoid allqueue(REDRAWX, 0) everywhere? 
Since object_change, material_changed type notifier don't work well 
with the delayed nature of listener if you wanted to find out if a 
specific object changed for example, how do areas and regions find out 
that this data changed? Immediate notifiers? Notifiers that don't pass 
any specific information about which data changed, just that some 
material changed for example?

Brecht.