<br><br><div><span class="gmail_quote">On 6/28/07, <b class="gmail_sendername">Jean-Luc Peurière</b> <<a href="mailto:jlp@nerim.net">jlp@nerim.net</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>however we need to :</blockquote><div><br>...</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">- get rid of all the while loops and define clear communication paths
<br></blockquote></div><br>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.
<br><br>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).
<br><br>I already implemented a form of drag and drop in the outliner [1], and it posed some hurdles:<br>* 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 }
<br>* 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.
<br><br>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).<br><br>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.
<br><br>(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)
<br><br>cheers,<br><br>Matt<br><br><br><br>[1] <a href="http://mke3.net/weblog/whirlwind-minus-the-tour/">http://mke3.net/weblog/whirlwind-minus-the-tour/</a><br>