[Bf-committers] Pie/Radial Menus design

Brecht Van Lommel brechtvanlommel at pandora.be
Mon Dec 9 07:28:40 CET 2013


Hi,

I would not add a new Menu class subtype, rather I think it should be
possible to define both a regular menu and a pie menu with a single
class. That doesn't mean it has to be automatic, there can be if
pie_menu: ... else: ... in the draw() function for example, to
customize it. But it's important that you can invoke a menu from an
operator or bind it to a key shortcut, and not have to choose which of
two classes you want at that point, the operators or keymaps shouldn't
have to know if it's a pie menu or regular menu.

There could be a bl_something member variable to indicate if the menu
supports drawing as a regular menu, pie menu, or both.


I think having the pie menu layout stuff as part of the layout engine
as you did is correct. It seems you could create more advanced pie
menus by extending this further, I'm not quite sure how far this goes.
I saw all kinds of floaty buttons in the mockups/screenshots and it's
not quite clear to me yet what kind of layouts there would be, if the
layout engine would somehow understand all these or if there would be
absolute positioning of buttons.


I would not have totally separate layout system for pie menus and
regular menus if we can avoid it. A layout basically has two callbacks
to provide, an estimate of its size, and then the actual layout of
items in it. That's pretty generic and may fit for pie menus as well?
In practice of course a pie menu layout may only be able to accomodate
a certain amount of buttons in each slice, it's not useful to combine
every type of layout. It seems to me the estimate/layout callbacks
make sense for pie menus also, but I haven't thought about it very
long.


Brecht.

On Sun, Dec 8, 2013 at 7:41 PM, Antony Riakiotakis <kalast at gmail.com> wrote:
> Some thoughts on the pie design, with some WIP code as well for review and
> to check possible directions
>
> I am going to take into consideration the work done by Sean Olson and
> Patrick Moore [1] and Matt Ebb [2].
>
> There are two approaches on the technical level here:
>
> - System uses current python definition of menus, overrides the layout
> qualifiers and simply arranges the subitems in a manner as explained in
> [2]. This would allow to just pass an operator option to WM_OT_call_menu
> and spawn a popup as a radial menu instead and would allow users to set
> their keymaps easily.
>
> or/and
>
> - System uses a new type of python Menu class subtype and a set of new
> layout operators to set and define the regions that buttons can reside in
> (as done in implementation of [1]). That would simplify the system since
> only the few new layout qualifiers would need to be implemented and the two
> systems would not interact. This forgoes the option to spawn existing menus
> as radial menus, but seems like most people would write custom radial menus
> anyway?
>
> Needless to say, both systems need different mouse intersection testing and
> draw routines, (the latter actually being the meat of the implementation).
> In fact, abstracting those two makes it quite easy to have different styles
> of pie menus (see for instance [1] for some ideas)
>
> My current incomplete implementation [3] (missing intersection code + bugs
> and using rounded widget drawing) uses first option, overriding the popup
> menu creation routines with custom menu styles that can either enforce a
> radial, popup or use the global preference for a menu style. Some popups
> (such as undo history) can enforce use of the popup style, while others can
> use the user preference or even enforce a radial style (Enforcement for
> some of the menus is debatable but I tried to provide some sane defaults on
> the first implementation).
>
> Also it may be good to have a way to support more than 8 items in menus
> Personally I was thinking doing it by automatically adding a "more" item if
> there were more than 8 present which would spawn the additional items if
> selected.
>
> On the previous developer meeting though, design was leaning towards the
> second option mostly.
>
> There have been discussions with Sean Olson to also have some Graphical way
> to create pie menus (with drag'n'drop probably?), which would be really
> nice to have, but for a first implementation I think it could wait. Seeing
> how everyone has his own opinion on where goes what in blender I think it
> might be good to have.
>
> [1]
> http://blenderartists.org/forum/showthread.php?267414-Pie-Menus-%282-66%29-Update-01-28-13
>
> [2] http://mattebb.com/weblog/radiation/
>
> [3] https://github.com/Psy-Fi/blender/tree/pie-menus
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers


More information about the Bf-committers mailing list