matt_e if you have the time to look at the patch, I would love to know if there is any other needed change other than move it to interface http://www.pasteall.org/10317/diff dfelinto: the main logic of it seems pretty reasonable the ppoin stuff is nasty, but that's how it is i guess dfelinto: I'm mostly looking at "I'll" it's never used on it's own. matt_e, yes Ctrl+C, Ctrl+V'ed from the original functions thanks :) matt_e, in view2d_ops or interface_handlers? handlers, I think yes view2d != UI handlers aren't exactly operators, they're just interpreting events but hopefully there should be somewhere nice to slot it in ui_do_button() might be a good place to start looking interface_ops no? interface_handlers ok hey Ctrl+Z even work to revert the cutting :) cool matt_e, it doesnt fit in interface_handlers. I need it running as a modal (therefore as an operator) I can obviously be wrong here agree on removing from logic_buttons. But it would be nice (aka easier) if it could still be an operator i don't think operator is the right way to do it it's possible to to modal stuff like that for example the ui_do_but_LINK need some way of triggering the click-down and the click-release events BUTTON_STATE_WAIT_RELEASE is what do_but_LINK uses here matt_e MattyMatt matt_e and does Ctrl+Z works for them? i don't see why it wouldn't, you can undo making a link join link join? dragging one link to another you might have to do some additional check after finding if there is a button highlighted in that block from what I tested you cant. if you link the same bricks twice (to remove it) itś not UNDOable not sure if this is what you meant by link join eg. if there is no button highlighted, then check to see if there are any link buttons in that block, and if there are, then handle the drag dfelinto: if i drag one link to another, i can undo that even so that's not an argument for making it an operator operators are not supposed to be modifying the UI i know you want the feature, but you also have to work with what we have I know. the argument to make it an operator is my lazyness :) and the fact that the Node space is doing this as an operator i realise its old crappy code with the link buttons etc but that's what we have, and the solution to it isn't to add more hacks, especially not in 2.5 where we're supposed to be doing the opposite :) matt_e, what does highlight buttons has to do with removing the links? they make sense to the linking. but unlinking should deal with the link I think I think highlight is just a general term to indicate that the mouse is over the button, and it's activated but currently when you unlink you drag from a link button, right? noyes yes* it runs the same function twice yep (for noth linking or unlinking) I'm guessing what happens is this both* you move mouse over a link button, it highlights since it's highlighted it now can react to a mouse event, so you click the left mouse and hold it down you cant see this in 2.5.but that may be "invisible" this activates the state of that button 'BUTTON_STATE_WAIT_RELEASE' line 3334 so the button is now kept highlighted, the highlight hasn't been cleared yet so next time there's an event to be handled by the UI handler (eg. a mouse move) it checks all that stuff again and updates the new link position as you drag (line 3329) then when you release (line 3342) it clears everything, and changes the button to BUTTON_STATE_EXIT which gets handled and then back to square one but then (not to be repetitive and not to interrupt) is there a way to make it as a knife? (like in nodes) * dfelinto just realized the UNDO works well only for one link. multiple links unlinked at the same time mess with that (w/ patch) what do you mean make it as a knife? matt_e, I actually didn't like the old "highlight" system for LB. that's why I was looking for knife solutoins that's for you to handle no, i dscribed a possible method for that above in the bit where it processes the block, looking for highlighted buttons to send events to your method runs from the LINK no, i'm describing how link works a ok matt_e, I will have to save this log and think again with a fresh mind in the bit where it processes the block, looking for highlighted buttons to send events to after checking for highlighted buttons if there are none highlighted (ie.. the mouse isn't over a button) ahh you can then perhaps do an extra check if ther are none highlighted AND there are link buttons in that block then switch to your knifey handling code how to do that exactly i don't know right now but that could be a possible means matt_e, but this will run per button, no? it'll run every time the block is checked that looks a bit hacky IMHO no, that's how the UI system works every time it's updated, it iterates over all buttons in all blocks and checks their states but since it's modal it will run multiple instances of the "knife" at the same time. that's what I meant (what I meant by per button) no it's not an operator its just handling events though it might need some data to be added to blocks to know if it's in the middle of a 'brush stroke' or not, and the stroke data maybe that could be done with a dummy button even can't this be "global" ? what do you mean? nvm Matt I promise to take a look at that. if I can't "fix" it by monday I send the patch to the tracker and may assign it to Campbell. thanks for the help I'll save this talk for later good night hah, campbell since you know i'll reject it? :) no, since he may have the time to fix it while I'm off :) hehe unless you want to do yourself :p what I bet you dont i know this stuff isn't an easy thing to do here and i sympathise I have a "work done" feeling anyways :) I didn't I would suceed in that (it's a hacky but it's a working hack :) work acomplished*