@sr20vet said: Yep, I've taken the native threads path. Got the thread running, got even an http server running in that thread. But now, GIL is killing me. Can't call ruby from that second native thread... May I ask what exactly you are trying to do? I think you can call ruby from that second native thread. One important point is that the ruby function needs to be involved in the ruby thread, i.e. the SU thread. So in the c-extension there should be two threads, one is the same SU thread, the other is your second native thread. All ruby codes need to run within the SU thread.

Ok, thanks for the workaround. You should expect that no mather you use rb's or rbs's, they behave the same way...

The two main problems we have: (1) Menu object references on the C++ side are garbage collected quite quickly, and the references on the Ruby-side become invalid. We can live with having to recall UI.menu() to get new valid references to the 9 top level menus, but ... (2) the menu#add_submenu method should return a new valid reference to the submenu IF IT ALREADY EXISTS, or create the submenu if it does not. Currently it just creates a duplicate submenu. I am sure that this issue has already been logged. I so much hope that SketchUp v2013 will fix this (if no more updates to v8 will be released.) So.. for now... once the startup cycle is complete, we cannot add items to ANY of the previously created submenus.

@thomthom said: For timer delay you should immediately stop the timer in it's block - because if a modal window appear within the block, like a messagebox or an error message (which you get when you start SU) will make the timer repeat until the modal window is closed. <span class="syntaxdefault"><br />timer </span><span class="syntaxkeyword">=</span><span class="syntaxdefault"> UI</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">start_timer</span><span class="syntaxkeyword">(</span><span class="syntaxdefault">0</span><span class="syntaxkeyword">,</span><span class="syntaxdefault">false</span><span class="syntaxkeyword">){<br /></span><span class="syntaxdefault">  UI</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">stop_timer</span><span class="syntaxkeyword">(</span><span class="syntaxdefault">timer</span><span class="syntaxkeyword">)<br /></span><span class="syntaxdefault">  </span><span class="syntaxcomment"># ...<br /></span><span class="syntaxkeyword">}<br />&nbsp;</span><span class="syntaxdefault"></span> Hi Thom and TIG, that's exactly how ì solved it. Noticed the fact that a UI.messagebox in the block will make the timer repeat too. Never used UI.start_timer before but I can think of some nice implementations of it.

draw2d and Chunky_png could accomplish the same result with some dynamic options.

@thomthom said: Do you stuff in the Tool's activate callback. That should trigger after deactivate. Initialize triggers when you create the tool instance - not when it's activated. You can reuse a tool instance - where activate is the one that will trigger when your tool activates. (How do you activate the tools btw? model.select_tool or model.tools.push_tool ?) Hi Thomthom. Man, such a stupid error of me. I did use the initialize method instead of the activate method. Btw, I use select_tool ToolName.new Thanks for the answer, funny I didn't saw the error myself

Perhaps start from a different angle... A manifold solid group has the following properties... It contains only faces and their edges. AND these edges can only have two faces - no fewer, no more. So this is start - you can eliminate all other faces/edges ? The number of permutations will always expand exponentially... What is it you are trying to do, exactly ?