2.5

Proper integration of File-selecting in WM. The communication
flow was flawed. :) Main problem was that filewindow can change
the screen context entirely, and should not do this directly on
a call inside an operator. Another problem was that the operator
ownership was handed over to SpaceFile, which is asking for 
problems if you want to execute the operator with proper context
later on.

Solution is simple; window handlers already are valid owners of
operators and can manage context, so instead of directly talking
to the 'file space', you give the operator to a new handler this
way:

    WM_event_add_fileselect(C, op);

This handler then listens to events (OPEN, EXEC, CANCEL) sent
by the WM or by the filewindow itself. This way local context
operators (like "open new image in imagewindow") will survive
a full-window fileselector fine, and in future also secondary
windows browsing files.

Two bugfixes included in this commit too:
- Add sequence menus in Sequencer used wrong context.
- When handler executes operators, it sets stored context now
  by first checking if this is still valid.

1 files changed, 4 insertions, 1 deletions

diff --git a/source/blender/windowmanager/wm_event_system.h b/source/blender/windowmanager/wm_event_system.h
index d6899d47471..930f20dfa63 100644
--- a/source/blender/windowmanager/wm_event_system.h
+++ b/source/blender/windowmanager/wm_event_system.h
@@ -59,6 +59,9 @@ typedef struct wmEventHandler {
 	struct ScrArea *ui_area;			/* for derived/modal handlers */
 	struct ARegion *ui_region;			/* for derived/modal handlers */
 	
+	/* fileselect handler re-uses modal operator data */
+	struct bScreen *filescreen;			/* screen it started in, to validate exec */
+	
 } wmEventHandler;
 
 
@@ -71,7 +74,7 @@ typedef struct wmEventHandler {
 /* custom types for handlers, for signalling, freeing */
 enum {
 	WM_HANDLER_DEFAULT,
-	WM_HANDLER_TRANSFORM
+	WM_HANDLER_FILESELECT
 };