[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