[Bf-taskforce25] windowmanager issues

[Brecht Van Lommel]

Hi,

On Wed, 2008-11-19 at 19:21 +0100, Ton Roosendaal wrote:
> > * There seems to be no way to specify "any key", or "any modifier key"
> > in keymaps.
> 
> For time being we should avoid hotkeys to be that flexible. When would 
> you do that?

Fair point, I needed "any modifier key" for detecting mouse movement in
the UI operators I added, but if that becomes a handler it's not needed.

> > * 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?
> 
> Can't the modal-handler store a subwindow index, so it can check/set 
> context?

Right, it can save the context the operator was invoked in and restore
that when calling the modal() and cancel() callback for the operator.

> > * 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.
> 
> I'll document that better; but in theory the operator was meant to be 
> called by anyone, on operations on data, and especially possible 
> without handlers.
> Your examples:
> 
> - timeline play = notifier (UI stuff)
> - shift+p previewrender = notifier
> - autosave = operator with timer handler
> - opening a file dialog to set an image path = notifier

What I'm unsure about is who is calling these notifiers. Take timeline
play for example, who advances the time, calls that notifier and gets
the esc event to stop it? Is it the region where the play button is,
some built-in window manager thing, ..?

> > * 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?
> 
> Not sure what this means... isn't this example just a timer handler?

Suppose I wanted to write a continuous exporter to a game engine in
python. That could be based on a timer handler indeed, but how can a
python script create this handler and receive the events? For an
operator you can create an operator and then creating python functions
for poll/exec/modal/cancel, and that is then what is called by the
window manager. What does the windowmanager call to execute the timer
handler, does that also have a TimerHandlerType or some other way to
specify callback functions?

> > * 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.
> 
> If we want to extend this to a built-in console, some global (or
> Main) 
> can store this?

Indeed some global can store this, it does not need to be the
windowmanager itself. This is more of a context issue maybe, I don't
know if G will be kept, or this type of contents will end up in the
context, or somewhere else.

> > * 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?
> 
> You probably picture something that's depsgraph based?
> Notifiers/Listeners are only UI stuff... and don't have to be very 
> picky?

The way I see it is that you would need a datalistener() callback (can't
think of a good name currently), that areas/regions could have. Similar
to UI notifiers and listeners it would have multiple types of
notifications, like blendfile_changed, datablock_changed, with some
subtypes that are more specific like datablock_removed,
datablock_added, ..

On the other side, typically an operator would call for each of these
types a function saying what it just changed. For example when changing
a material it might do something like:

data_notify(DATABLOCK_CHANGED, DATABLOCK_REMOVED, (ID*)ma); 

Since materials aren't part of the depsgraph currently it can call
datalistener() only for that material, but for objects indeed it would
call it for itself and objects depending on it (or maybe once with a
list of objects).

The code in datalistener() can then be as specific as it wants. If you
just want to monitor material changes, you just check datablock_changed
and see if it is a material that changed, doesn't matter if it was
added/removed or which specific property changed. Other places might
check things more detailed.

Brecht.