[Bf-committers] New event system

[joe]

There are different ways to do a non-modal system.  One is where you
implement a generic "state" system that you can plug into a hierarchal
event system.  It also not all *that* difficult to hack things in if
you have a fully state-based, generic UI system (in fact, if you
follow specific code patterns it wouldn't really be hackish at all).

One very *VERY* important thing we need is a generic UI widget/element
structure, that you can build new/custom widgets from, and that also
acts as a container of other widgets.  This just makes things so much
easier (I have some practical experience in this area).

Joe

On 7/1/07, Matt Ebb <matt at mke3.net> wrote:
>
>
> On 6/28/07, Jean-Luc Peurière <jlp at nerim.net> wrote:
> >
> > however we need to :
>
> ...
> > - get rid of all the while loops and define clear communication paths
> >
>
> This is something that interests me greatly. All the tight subloops (eg.
> knife tool) that block all other input have got to go, and be replaced by
> something that works with the main event system. The functionality of being
> able to pick up various tools like that or edge slide is great, but it's
> very silly that upon using them, the entire UI is blocked, and the only
> method of interaction with them is via difficult-to-discover modal hotkeys,
> and the entire range of richer forms of interaction through Blender's GUI
> gets thrown aside.
>
> One thing that I wanted to ask about in this events work is mouse dragging.
> Dragging the mouse is already used in some areas of Blender (moving panels,
> sliders, node connections) and could potentially be used very positively in
> a lot of other areas such as in the outliner or re-arranging
> constraints/modifiers/textures/menu items, if it weren't
> currently so difficult (rather impossible).
>
> I already implemented a form of drag and drop in the outliner [1], and it
> posed some hurdles:
> * The entire outliner data structure was being re-built on *every redraw*.
> Not only does this seem wasteful, especially when you have heaps of objects,
> but it meant that as an item was being dragged around, all of the items
> would flicker in and out, cycling between each one as things were changed
> underneath. To solve this, I added a flag that could be checked to prevent
> re-building if it was inside a drag - like if (!is_dragging) { rebuild }
> * Because there is no global level support for it, I had to make a horrible
> subloop and do everything manually, such as using low-level commands to
> redraw the screen, detecting when drags were started and stopped, keeping
> track of where the start and end points were, displaying something to follow
> the mouse pointer.
>
> It would be great if the events system itself could help here, it would
> simplify things a lot and make it much easier for this sort of thing to be
> used across Blender without having to re-invent the wheel each time. I won't
> say I'm an expert on the best way to implement it, but it would make sense
> for drags to be a proper low-level event. They could be checked at the
> lowest level when processing the mouse inputs ( i.e. if button is held down
> and displacement crosses a threshold, or when it's released).
>
> Then global info could be set, and accessed anywhere in Blender, (perhaps
> similar to get_mbut()), you could have something like get_dragging(float
> *startcoord) that would tell you if the user doing a drag motion, and where
> it started (and ended?). Then tool coders could just use the main events
> system and let it do the hard work of checking input devices, redrawing the
> screen, and life would be much easier.
>
> (as an aside, the main reason the outliner stuff wasn't taken much further
> is that there are no generic functions in Blender for parenting or datablock
> assignment such as object->object or object->list of objects or
> obdata->object, etc. etc. and I would have to rewrite all of that code
> myself, which I wasn't very keen on. Ideally this sort of functionality
> should be split up, or perhaps made as 'tools' in a tool API)
>
> cheers,
>
> Matt
>
>
>
> [1] http://mke3.net/weblog/whirlwind-minus-the-tour/
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
>