[Bf-taskforce25] [Fwd: Re: Python/RNA high priority TODO's.]

[Michel.Anders at inter.nl.net]

Op Za, september 12, 2009 03:29 schreef Campbell Barton:
[...]
>> Access to the menu class wouldn't be enough IMHO, you would need a way
>> to notify the instances of that class as well (although that would be
>> the responsebility of the menu class method that adds a new entry I
>> think)
>
> Not sure why you think its not enough. Python classes can be modified
> py other classes without having to notify blender. The next time the
> poll/draw functions are called they will show any changes made to the
> class.

You are right, but in order to redraw, the windowmanager should be
notified to check for any necessary polls/redraws. But of course I now see
that that is done *every time* a menu entry is clicked, so I guess normal
workflow more or less guarantees that if something is changed in a ui
class, the changes will be visible when needed.

> An example of how this can happen already is with external engines
> adding themselves to blender internal classes as being compatible so you
> can have some materials panels draw and others be hidden.
>
> I have doubts about this as a way to make all menus, since it could
> make them hard to read nevertheless its one way...

Well, to me changing classes at runtime (other than by subclassing) feels
unclean. Just because it can be done is not a reason per se to do it if
there are other ways possible. I am no purist though, so I have no problem
with it if its the only way, but my main objection is that developers
would need to know the internals of a class to make it work, whereas a
setup where there is a way to add/register a new item would need only
knowledge of a documented interface, allowing for reimplementation of ui
classes without the need for add-ons to be checked for compatibility.

> Rather then the draw function call menu items directly the class could
> store a list of menu items+options as strings. then these could be called
> in a loop when drawing.
>
> The main part I don't like about this is we'd have to somehow have a
> way to check each menu item should be drawn (a per menu item poll function
> ?) - this seems overkill.
> To avoid polling for each item we could have a nested list with a poll
> function at the start of each.
>
> So external classes would only need to import the module and add
> themselves into the classes menu item list (possibly including their own
> poll function).
>
> ...or store a list of functions that can be adjusted externally too,
> since its plain python there are loads of options for this.


why not make each item/submenu an instance of a class, so new items added
by users can be subclassed if needed but would contain the necessary
minimal functionality to make it work properly (e.g. a default poll()
function that always returns True, an icon() function that returns None,
etc.). Like you said yourself, is plain python, so we can use the full
power of OO if we wish :-). Even adding similar menuitems could reuse code
if not the class but an instance would passed to the add/register
function. From a developer point of view this would be quite clean:

import bpy.ui
menu = bpy.ui.getMenu('MENU.ADD') # get a reference to the instance of the
ADD menu

class mymenuitem(bpy.ui.menuitem):
    def __init__ .......
    def __poll__ .......
    ......

menu.addItem(mymenuitem())

-- Michel.