Page MenuHome

Cannot Execute TOOL_PROPs draw
Closed, ResolvedPublic

Description

System Information
Operating system: Windows
Graphics card:

Blender Version
Broken:
2.80 2018-12-06

Worked: (optional)
2.79

Short description of error
The TOOL_PROPs window does not appear after execution operator via PROPERITEIS Panel Button Click or Python Console

Exact steps for others to reproduce the error

Download and install this add-on
https://github.com/muchasty/Lightmap-Auto-UV/tree/master/SureUVbox-2.80

After clicking button: Properiteis->Object Data->Sure UVW Mapping->[ UVW Box Map ]
the mapping is processed but cannot see a popup window [TOOL_PROPS] on the 3DView with parameters to interactive change.
Only when I execute operator bpy.ops.object.sureuvw_operator(action='box') from PieMenuEtior Addon then this popup TOOL_PROPS window appears ( see attached JPEG image )
But if I try to run this operator from Python Console then nothing appears.

It all worked fine with 2.79.

Details

Type
Bug

Event Timeline

Philipp Oeser (lichtwerk) claimed this task.

This addon is not maintained by blender, so please report the bug to the original author https://github.com/muchasty/Lightmap-Auto-UV/issues

Hold your horses Philipp!

Why is that after changes that have been made in API of Blender cannot show that TOOL_PROPs until the mouse cursor is inside the 3dView area or operator is executed form element related to 3dView (as i.e. menu) ?
It worked with no problems with previous version of Blender.
I think that there could be a problem with API.
Official docs do not mention that changes made for 2.80 API can influence on that TOOL_PROPs appearance !!!!!
If I am wrong then tell me what should I change to adapt to changes you made in new API and update the API changes log for other developers.

Could you be so kind and reinvestigate that case, please?

As far as I can see the reason for that is that the UI for adjusting the Last operation changed in 2.8 (see T55039, T57731).
In 2.79 it was showing in the 3D View for any command [no matter what editor it was executed in]. I think we all agree this was awkward if you had to have a 3D View open to tweak something you were doing in the UVEditor for example.
In 2.8 this is now done per Editor [Image Editor has it, 3D View has it, probably more to come...]

OK, so without relying on your particular addon, lets move the discussion to something more general (in a way you have already done that in your previous post, thx)
The same thing/issue can be observed with the Python Template ui_panel_simple.py that is shipping with blender [in Text Editor > Templates]
(It makes a panel in Properties Editor with an operator button to add a cube)

  • In 2.79 operator settings for adding the cube could be tweaked in the 3d view (even though executed from the Properties Editor)
  • In 2.8 there is no HUD to tweak the settings for the op when being executed from the Properties Editor (Properties Editor just doesnt have it)

Atm. I am unaware of a method to tweak/override the operator context (see here, here) to an extend that it would be thinking it was executed from the 3D view.
(I might have done something wrong but I wasnt able to get it to work when calling an operator from a UILayout, also tried tweaking context in invoke() to no avail...)

As a (workaround) solution you could of course move your UI from the Properties Editor to the 3D view sidebar / N-Panel [but I could understand if this is not desired...]

I will add @William Reynish (billreynish) and @Campbell Barton (campbellbarton) here to discuss further if this is considered an issue to be solved? [or if this can be done right now (and I just dont know how to do...)]

Yes, as you say, the solution would be for the operator to set a different context.

Or even simpler, just move this command into the UV menu inside the viewport where it belongs, and get the correct context for free.

I would say this is an issue with the addon more than an issue with Blender itself.

Philipp Oeser (lichtwerk) triaged this task as Normal priority.

reopening for now...

@William Reynish (billreynish) : reg. setting the different context: do you know of an example that does that [when called from a UILayout.operator() -- sorry, seems I am too blind to see atm...]?

@Philipp Oeser (lichtwerk): Not sure, maybe @Campbell Barton (campbellbarton) knows a way?

But why not just add these commands to the 3d viewport? We already have a menu for UV commands that can be extended.

Thanks for taking care of this!

I could not find other solution so I add all operators to the UI menu in VIEW_3D (look at the images on the github main page).

https://github.com/muchasty/UV-Tools
Now it works fine and seems to be placed right for the UX.

But many old and good add-ons that are abandoned somehow could have similar problems.
If there will be some annotation about changes with the limitations of the UI in 2.80 then we will able to do some adaptation.

@Tomasz Muszynski (muchasty): I would simply add the item to the UV menu. What's the point of adding a panel? I see no reason for that. Just extend the appropriate place in Blender's UI - no need to invent new panels for simply adding more commands.

Like so:

Panel is very handy for me.
But I will try to add it to the UV menu also.
I have to say that I do not use Blenders menu at all. Just shotcuts and panels.
I use menu only if I cannot find a shortcut for desired operation. :)

We use the menus for all commands. If you want quicker access, users can map a shortcut or add to Quick Favourites. Adding UI panels just to add a command is not needed, and not appropriate.

Cheers

Philipp Oeser (lichtwerk) closed this task as Resolved.Dec 10 2018, 9:31 AM

I guess this can be considered "Resolved" now?

It was tempting to put these operators in the Properties Editor [close to other mesh related data], but as @William Reynish (billreynish) pointed out the UV menu provides even more context, so +1 for that [and panel in the sidebar also works...]

Not always one way is suitable for everyone.
We have tested sth like "one-right-way" in the past and it was called - communism. I honestly do not recommend that way for anyone :)
But I am joking now ...
Only one conclusion is that all depends on this what SHOULD and CAN (in the matter of resources and time) BE GIVEN in API for developers to use.
So all depends on you guys and your vision.
Thanks for taking care of it !

For me this case can be closed. Thank you!