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

[Campbell Barton]

If we go the OO way you suggest this can be done entirely in python
using the existing C api internally.
to me its important that it stays python only otherwise we end up with
a lot of c/api code which is hard to manage.
IMHO using the C/register system us overkill too since it would make
an StructRNA class for every menu item which would clog up bpy.types.*

But there's been no input on this from anyone else.
any opinions on weather we should have a way that any python defined
menu can be extended by other scripts?

On Tue, Sep 15, 2009 at 1:15 AM,  <Michel.Anders at inter.nl.net> wrote:
> 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.
>
>
>
>
> _______________________________________________
> Bf-taskforce25 mailing list
> Bf-taskforce25 at blender.org
> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>



-- 
- Campbell