[Bf-committers] proposal for better integration of addon functionality

[Sjoerd de Vries]

>
> Message: 11
> Date: Sun, 3 Mar 2013 13:02:03 +1100
> From: Campbell Barton <ideasman42 at gmail.com>
> Subject: Re: [Bf-committers] proposal for better integration of addon
>         functionality
> To: bf-blender developers <bf-committers at blender.org>
> Message-ID:
>         <
> CAEcf3NxhCzkpZaCc8J1+qPJGqGsUous4WYj5yXhnpkCkka_vmA at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Sun, Mar 3, 2013 at 4:16 AM, Gaia <gaia.clary at machinimatrix.org> wrote:
> > On 26.02.2013 15:44, CoDEmanX wrote:
> >> The addon's name could be added to the tooltip, but screencasts wouldn't
> >> benefit then...
> > Adding the Addon Name to the tooltips sounds good.
> >> for video tutorials it would make sense to indicate
> >> whether users need an addon or if need just the built-in functions
> >>
> >> append_after(bpy.ops.*) looks ok, but shouldn't it rather be
> >> append_after("mesh.foobar") ?
> > yes, good.
> >>
> >> And what to call the other function? prepend_before (I dislike)?
> >
> > maybe: name add_after() and add_before()
> >
> >> One problem is still not covered: what if someone uses an addon with
> >> older blender, addon works but the given op / op name of a built-in
> >> function doesn't exist in that version?
> >
> > Isn't that a general problem ? We face this sort of issues a lot.
> > Blender developers told me they mostly just provide the "addon per
> release".
> > So in that case there should be no problems.
> >
> > And when an addon shall span over multiple blender versions,
> > a lot of extra work needs to be done anyways (potentially) .
> >
> >> Am 26.02.2013 14:04, schrieb Gaia:
> >>> Basically to help users to understand what comes from Blender
> >>> and what has been added from outside. Especially the first part
> >>> of my proposal about getting the ability to add menu entries
> >>> "inbetween" the standard entries might make it convenient to
> >>> know that "this" is from blender, and "that" is from an addon.
> >>>
> >>> Well it may be useful to distinguish between system addons
> >>> which are distributed along with blender (and can be considered
> >>> as part of blender), and the rest of the world.
> >>>
> >>> And ok, so lets make it a system option "mark addon elements" in
> >>> user preferences. then a screencaster can enable that to give visual
> >>> hints to the users. and users can decide to not care and disable the
> >>> visual mark...
> >>>
> >>> On 26.02.2013 13:36, Bart Crouch wrote:
> >>>> On Tue, Feb 26, 2013 at 10:41 AM, Gaia <gaia.clary at machinimatrix.org>
> wrote:
> >>>>
> >>>>> Currently you can not tell if a button or a panel has been added by
> an
> >>>>> addon.
> >>>>>
> >>>> Could you perhaps explain why it would be desired to make a visual
> >>>> distinction between add-ons and built-in functionality?
> >>>> >From a user-perspective I don't think it is very interesting to know
> >>>> whether a tool was written in Python or in C. And from a
> >>>> developers-perspective, I like the integration I can get when writing
> an
> >>>> add-on.
>
> Not sure its really needed to identify addons as being different to
> built-in functionality.
>
> As for adding items in the middle of a menu, this can be done already,
> but the menu its self needs to be modified.
>
> so rather then...
> bpy.types.SOME_MT_menu.append(draw_func)
>
> you could do...
> bpy.types.SOME_MT_menu.my_section.append(draw_func)
>
> Where `my_section` is simply a list defined in the class which the
> menu draw function calls.
> The main problem with this is we need to add these sections in blender
> releases, so addon devs can't just insert themselves into the middle
> of any menu.
>
> Its possible to do python tricks with intercepting the class & draw
> function to insert your own logic, but these are so horrible I
> wouldn't recommend them.
>
>
Blender could have a simple menu tree stored as text or data in user
preferences:

View 3D:
  Object:
    Transform:
      Origin to Geometry
      Origin to Active
      Randomize transform
  Edit Mode:
    Tool Shelf:
      Tetrahedron Maker

Every Blender version would ship with such a menu tree structure.
When registering an addon, a key for that addon is parsed from
bl_info["name"] and bl_info["location"],
 Blender looks up the key inside the menu tree, and inserts the addon at
the found location.

The menu tree can have lots of missing keys: for any entry key that is not
found in the menu tree, current behavior is simply followed.

cheers

Sjoerd