Window [aka (Work)Space] become Active handler?

Archive Python API
1

I have struggled with the basics in Python Scripting for maybe a decade, always seems I can’t get past step one.
I look for the most basic thing like a Windows Event Handler and give up pretty quickly thinking “Wow how can you miss that? I guess I’ll try again next year.”

Currently I looked at the API for 2.82.7 for the Base Class Space
https://docs.blender.org/api/2.82/bpy.types.Space.html?highlight=handler

while searching for an appropriate initial handler for the Window events. Often I just want to know when that window has become active so I can start to do things in an efficient way.
A Draw event is as bad as running a timer, completely inefficient and unacceptable to me as a coder since the early 1980s.
I just want to know also when the window is no longer active so there would typically be a bunch of events like WindowActive and WindowRelease.

This seems like as good a subject to start with. Anyway I am hopeful to finally understand the best Community Forum Pipeline (for inquiry, suggestions & discussion, and maybe even contribution) practices to find out where to make suggestions and figure I have found the latest best place for ‘Suggestions’ over here…


I think this must be the best place to ask before doing that there.

I think my issues are going to be mostly API related in someways hopefully if I can find the time to become more active in Blender becoming more in tune with my needs or expectations or visa versa (where I learn what in the world you guys are thinking!?) since what seemed like waiting for the obvious has dragged on for what feels like a decade but is definitely 4 years, since I started falling out of favor for Houdini (probably due to a lack of opensource thinking [note: I wish for a more procedural vision of Blender like Houdini is, however foolish that expectation ultimately really is]).

Okay so if there is not something obvious (you are aware of and someone can point out) about the API missing simple handler hooks for the most basic initial Window Events like ‘it has become active/released’ let me know so I can move forward with asking in the Feature Request area if that could be added, thanks.

2

It would be inefficient if every add-on or built-in feature in Blender was handling events like this. In general, what you should do instead is to register panels, tools, operators, handlers, etc, and leave more low-level event handling to Blender.

For a more useful answer, it’s best to explain which functionality you’re trying to implement. There may be cases where an add-on needs to do something whenever a window becomes active, but in most cases that’s not necessary and can become a performance problem.

3

Thanks for the feedback and comments for discussion.
I disagree with your assessment. The alternative is to have timers firing constantly.

4

Maybe there is something missing in the API to make your feature work without timers, but unless you provide more information about what you’re trying to do we can’t suggest better ways to implement it.

5

Right okay well you all love examples. I think this applies to everything pretty much it is a primary thing you should be able to get events for.

Lets talk about setting the Sculpt mode to be dynamic all the time. Sure this is easy to implement as a feature for a specific issue but it’s a blanket example you need to see the light that all kinds of events should be accessible by anyone anytime.

I this example I would like to say fire this function to toogle the sculpt mode to re-enable dyntopo via bpy.ops.sculpt.dynamic_topology_toggle() this should be displayed in the info as a parameter and not a function or allow an argument but we can see if it was enabled and other problematic poor design issues to discuss later but for now let’s see how we can toggle this back on (why it goes off I will never agree is reasonable either)?

We can call a timer and check and set it constantly, or we could ask the 3DView Window event listener when it comes active to fire this simple check once. We also have to check the when the sculpt mode parameter changes on any view and again that should be monitoring a parameter for changes.

The problem with all toogle functions is they lack displaying to the info panel what parameter is actually being changed so that I can monitor it with a parameter has changed event, so if you/we/it got ride of toggle functions and or displayed what actual parameter is being toggled by all/any toggle function we could now what parameter to attach a parameter changed event etc.

In the end allowing simple ‘window became active’ event listeners is not going to do anything but allow/enable addons or any code to do whatever it needs to do efficiently.
If they don’t need one they don’t add one that is why events are a wonderful paradigm/solution.

We are really talking about a bigger issue in a fundamentally flawed to Blender Developer mindset, once you remove the restriction and allow access to all events you will not find it causing more problems then it does without it. Try explaining how it would be bad? it is not going to slow things try adding 50 function calls to a window event and run a timer and see. Then try it with 50 timers running every 200 milliseconds and see which is causing more problems.

I appreciate your input and hope you have a good solution to this. You can tell I am frustrated with this kind of issue for many years now.

6

Window or 3D viewport editor activation are the wrong event to track dynamic topology changes. That would give a pretty poor user experience, if moving the mouse in and out of a window or editor changes their data.

An app handler listening for depsgraph updates seems like a more correct solution.
https://docs.blender.org/api/current/bpy.app.handlers.html

7

I think you miss understood in this example it is not for all changes to the mesh or any mouse movement. In the simple example. We only want to get one event for the window becoming active (or the sculpt mode changing which is another problem brought up in context that does not get property changes if only the window becomes active) in order to switch the dynatopo mode back on.

8

There is no relation to the window becoming active and sculpt mode changes. A user could work for hours in Blender without the window ever getting deactivated or activated.

Depsgraph update on the other hand will be called when sculpt mode is entered or exited.

9

Okay well let me start there. I was only looking for an example where you wanted proof people in an open source project should be able to add a function call to window events and everything else possible.
I will also come back or repost when I find you another of hundreds if not thousands of examples where real access to the APIs and events makes sense to you. I bet you could think of one if you tried.

Let me go back to the depsgraph update function to monitor when sculpt mode is switching and see if leaving the window triggers that toggle and if it allow one to fix this minor example/annoyance in particular.

Okay so I would need to know what value the toggle is changing right? Like your saying you want to monitor when the value parameter defining sculpt mode is changed.

Let me see if I got this straight and again thanks for your help in setting me straight how this is going to be so much better then the window became active handler.

The link you provided shows the handlers. I have seen that nothing seemed right, and the documentation is spares to none existent there. Maybe there is somewhere that page should link to that is more helpful.

bpy.app.handlers.depsgraph_update_post
or maybe
bpy.app.handlers.depsgraph_update_pre
is better to stop the system from changing it in the first place. Still I would want to allow a user to change it but not the system (unknown where or why it disabled it, so maybe it’s deeper in the code that that has to be fixed).

Here are the first questions I guess I could answer with some testing.
How often is that general function firing. I think I just want one when the window becomes active. Are you saying I would write a function in which it would have to check to see if the window is active every time any parameter on the entire system changes?

Yup I am totally lost here what you think I would do with that?
I will just post this now and come back if anything clicks in the next few hours or days.

I have got some of the answers from this post.

active_object = bpy.context.view_layer.objects.active

if active_object.mode == "SCULPT" and not active_object.use_dynamic_topology_sculpting:
    bpy.ops.sculpt.dynamic_topology_toggle()

This is more what the function would be and not where to put it.

It does help to understand what dynamic_topology_toggle is changing. active_object.use_dynamic_topology_sculpting

Unfortunately following the (3rd unpostable) link shows it is read_only (another limited thing because of some magic mystery in the toggle function. Let’s not get into operator overrides and the better idea of the toggle function allowing arguments. Nor the fact that the info window doesn’t reveal anything useful other then the toggle function.)

I am guessing you are saying we want to monitor that for changes through some other more general function?

There it was also discussed about the also undocumented msgbus?

Searching on that led me to this article

Anyway I am thinking if you monitored that parameter (read_only) you need to know what function is calling it in order to not change it unless the user toggles it from the UI.

Anyway at this point I find myself here
developer blender org D2917?id=9615
which is marked/tagged “Abandoned” but it’s the only thing I can find that makes sense as to what is needed in many cases or any real event type system.
Hmm I guess that the system discussed is in place, regarding 2.80 at least
developer blender org T63157