[Bf-committers] Pie/Radial Menus design

Ton Roosendaal ton at blender.org
Mon Dec 9 10:05:18 CET 2013


Hi,

New type, definitely. Radial is not a "user preference" that would automatic switch. It's an interesting (but limited) input type that has to be carefully constructed to work well.

-Ton-

--------------------------------------------------------
Ton Roosendaal  -  ton at blender.org   -   www.blender.org
Chairman Blender Foundation - Producer Blender Institute
Entrepotdok 57A  -  1018AD Amsterdam  -  The Netherlands



On 8 Dec, 2013, at 19:41, Antony Riakiotakis 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