Webdialogs for SketchUp ......RIP!

icehuli

I don't think ruby is the one to blame. It is very flexible. With the possibility to write ruby extensions in c/c++, on a Windows PC, one can also write it in C++/cli. Thus one can easily integrate any .net stuff. If one do not like webdialog, any other gui library can be linked through the extension. E.g. one can build c# plugin via p/invoke [DllImport("msvcrt-ruby18", CallingConvention = CallingConvention.Cdecl)]...
For stuff like Visual Programming the most challenge thing is parametric model. In sketchup this is not easy, since entities can easy be manipulated. I mean e.g. if you simply delete the area of a face, it becomes 4 lines. The entities are not consistent. They are so flexible. And if this is not a issue, one can make some effort and create a Visual Programming interface for su.

jolran

@unknownuser said:

if you simply delete the area of a face, it becomes 4 lines. The entities are not consistent. They are so flexible. And if this is not a issue, one can make some effort and create a Visual Programming interface for su.

That is why I use Open GL objects through a tool's draw class to visualize entities for "Visual Programming interface". It is to sketchy to try to alter Sketchups entities parametrically. Subdivide a face with a slider and youre toast, as you mention.

The biggest problem, as I see it (so far) is that a webdialog freezes during any Ruby operation. Making webdialogs only really usable being used as a form-submit type of thing. One have to write very efficient Ruby code that masks that behavior.

I wonder how other type of GUI's, you mention behave during Ruby operations..

icehuli

One can use c# wpf or winform for the GUI. One can create another thread for the GUI. And use dispatcher for the calling, something like:
in the ruby thread do
wpfWindow.Dispatcher.BeginInvoke((Action)(() =>
{
wpfWindow.Show();
wpfWindow.Activate();
}), System.Windows.Threading.DispatcherPriority.ContextIdle, null);
to open the window and call other functions in the gui.

and in gui thread do
using VALUE = System.Int32;
ruby_extension.BeginInvoke(DispatcherPriority.Input,
(Action)(() =>
{
VALUE state = 0;
VALUE rb_mKernel = rb_eval_string_protect("Kernel", ref state);
rb_funcall(rb_mKernel, rb_intern("puts"),
rb_eval_string_protect(Encoding.UTF8.GetBytes("Hello, World!" + '\0'), ref state));
}));
to call ruby functions or evaluate ruby scripts.

jolran

Oh, I wish I'd taken up on C or C++...

Anyway, I gather Windows only ?

Both plattforms ought to be provided to keep people happy.

jiminy-billy-bob

Jolran, what do you use for your JS node-based interface ? I was wondering about something similar for a material editor (For vray and friends) like 3dsmax's.

JSmaker ? http://jsmaker.com/jsmaker/

icehuli

@jolran said:

Oh, I wish I'd taken up on C or C++...

Anyway, I gather Windows only ?

Both plattforms ought to be provided to keep people happy.

I think the same method can be applied for c++ gui, e.g. qt, as well. A new thread need to start for the GUI to avoid it being frozen while ruby scripts are being evaluated.

jolran

@unknownuser said:

I think the same method can be applied for c++ gui, e.g. qt, as well. A new thread need to start for the GUI to avoid it being frozen while ruby scripts are being evaluated.

Great! It's just the small detail of learning c++ then

Seriously though, I was under the impression these kinds of 2 way Communication was not possible outside webdialog-World.

I would really like to know more.

jolran

JSmaker is not an option I think.

I use JsPlumb. It's depended of Jquery UI, which is a bit sketchy when dealing with CSS3 transforms. It does not recognize them So zooming is very fun to deal with
Anyway one have to write nodecreation functions oneself and where endpoints should be added. Jsplumb is only a view technology. Does not do any type of layout (yet).

I've been looking into D3, and it's an awsome framework! But also very low-level so it would take ages to come up with something that's even close to where Jsplumb is now.
But still very interesting...

edit: Removed some off topic ramblings..

jolran

@unknownuser said:

A new thread need to start for the GUI to avoid it being frozen while ruby scripts are being evaluated

So, the dialog does not freeze during Ruby operations ?

How about window modal behavior. I mean how do one activate a dialog through Ruby plugin, must the C# program or whatever being used already be up and running?
I assume you already have tried this in practice.

Sorry bout the noob questions

icehuli

@jolran said:

@unknownuser said:

A new thread need to start for the GUI to avoid it being frozen while ruby scripts are being evaluated

So, the dialog does not freeze during Ruby operations ?

How about window modal behavior. I mean how do one activate a dialog through Ruby plugin, must the C# program or whatever being used already be up and running?
I assume you already have tried this in practice.

Sorry bout the noob questions

Yes, one can activate a dialog through ruby plugin. The c# thread is started within the plugin. I have tried something already. check out https://github.com/icehuli/suWpfExt.
Although it is a alpha version, it should give you a hint how to do the trick. It currently uses swig, which is not necessary. I am working on a version without swig. The plugin is separated in several dlls.

myExtMain.dll is the main dll in c++, compiled with /clr, so it can load .net dlls.
suWpfUI.dll is the UI dll in c#, witch implements the WPF GUI.
suExtMainWrapper.dll is the wapper linked by the GUI to call c++ functions in myExtMain.dll. (This one seems not necessary, the reason to have it is that c# can not be linked to with myExtMain directly. However one can use P/Invoke in c# code
using VALUE = System.Int32; using ID = System.Int32; [DllImport("msvcrt-ruby18", CallingConvention = CallingConvention.Cdecl)] private static extern VALUE rb_funcall_(VALUE recv, ID mid, int argc, __arglist);
to directly call ruby functions, thus the suExtMainWrapper is not necessary.)
Another issue is that suWpfUI and suExtMainWrapper are not explicitly loaded by ruby require so it needs to be placed inside Sketchup.exe directory. I haven't figure out how to avoid this.

icehuli

@jolran said:

@unknownuser said:

I think the same method can be applied for c++ gui, e.g. qt, as well. A new thread need to start for the GUI to avoid it being frozen while ruby scripts are being evaluated.

Great! It's just the small detail of learning c++ then

Seriously though, I was under the impression these kinds of 2 way Communication was not possible outside webdialog-World.

I would really like to know more.

In windows C++ should be not much more difficult thanks to visual studio and .net. However in mac os it is more difficult since the default system gui library is cocoa, which require object-c. Once upon a time, one can use carbon to build cocoa GUI, but it is deprecated since OS X 10.8. Automatic Reference Counting, or ARC makes things more complicated. I am not familiar with other c++ or c libraries. If one does, one can try to use multithreading‎ tech. I tried qt yesterday. It is just not straight forward, since in qt every gui needs to be created and maintained in the main thread. And only one QApplication is allowed, thus multiple plugins using qt may cause problems.

jolran

Many thanks for the valuable information, really
And the link too, much appreciated.

Looks like you know what youre talking about.

I'm probably not gonna dig into this just yet. Maybe if I reach a dead end with the Webdialog class.

I wan't to build an opinion if it's worth the effort first.

icehuli

@jolran said:

Many thanks for the valuable information, really
And the link too, much appreciated.

Looks like you know what youre talking about.

I'm probably not gonna dig into this just yet. Maybe if I reach a dead end with the Webdialog class.

I wan't to build an opinion if it's worth the effort first.

I reached the dead end a year ago, when I implemented heavy optimization operations. I tried ruby thread, which is a fake in ruby 1.8. It did not solve my problem so I looked into c++ and than realize the extension can be compiled with /clr that opens the door to the wide .NET world.

jolran

Aha, interesting. Will chew on it a little..

My brother is a .net developper with quite a bit of knowledge of C++, so I could probably get a big kickstart and set up. Otherwise I woulden't even consider trying..

Anyway, thanks again! I'll keep an eye on you projects

icehuli

@jolran said:

Aha, interesting. Will chew on it a little..

My brother is a .net developper with quite a bit of knowledge of C++, so I could probably get a big kickstart and set up. Otherwise I woulden't even consider trying..

Anyway, thanks again! I'll keep an eye on you projects

Actually you can still use WebDialog without being frozen by heavy operations. The way is similar. Just put all the heavy operations to a new thread that started in the c++ code. The trick part is communication between threads (that's the point I started to look into .net, since it is much easier to handle multithreading‎ thing with .net libraries ).

jolran

That doesent confuse me less

About threads, I was under the impression Sketchup threads was a bit shaky ? Although I can't really tell the outcome from this topic.

http://sketchucation.com/forums/viewtopic.php?f=180&t=51701&p=467287&hilit=threads#p467287

icehuli

@jolran said:

That doesent confuse me less

About threads, I was under the impression Sketchup threads was a bit shaky ? Although I can't really tell the outcome from this topic.

http://sketchucation.com/forums/viewtopic.php?f=180&t=51701&p=467287&hilit=threads#p467287

Sorry, I can not see the post:
"The requested topic does not exist."

The issue for thread is that, Sketchup uses ruby version 1.8.6 (1.8.5 on mac), which does not implement native threads. It means they are not actually "parallel", only one thread is actually running at once, ruby controls the switch. I once tried to open a new thread in ruby to do the operation and check if the operation has finished within a loop in another thread. However the result is not reliable. One can not tell when it does the checks.

In my case my operations are independent from Sketchup. So when open it in another thread in c/c++ it does not freeze the webdialog. If the operations are Sketchup things, e.g. drawing, modification, etc. it will not help. In that case it's better to have the GUI in a new thread different from the ruby thread.

jolran

Strange I don't seam to be able to paste the link properly. Never mind. The topic was called UI.timer or something like that.

From what I understand the outcome from that topic was about the same as you says.

I think I misstook c++ threads for Ruby threads. You could probably say anything regarding C code, and I believe it..

thomthom

@icehuli said:

I think the same method can be applied for c++ gui, e.g. qt, as well. A new thread need to start for the GUI to avoid it being frozen while ruby scripts are being evaluated.

Isn't the work being done in the work being done in the new thread while the main thread remains control over the UI?

(Though this would not work in SU if the "work" is manipulating entities.)

thomthom

@jolran said:

Strange I don't seam to be able to paste the link properly. Never mind. The topic was called UI.timer or something like that.

From what I understand the outcome from that topic was about the same as you says.

http://sketchucation.com/forums/viewtopic.php?f=180&t=51701

People has been using timers to manually slicing up work that interact with the SketchUp Ruby API. It makes the total process take longer, but you can cancel the operation IF you manage the slice it down small enough.

Though I'm not so sure how much gain you'll get in the long run.

If it's calculations being done then I'd recommend you do that in C threads if you are able to. Though, it might run so fast in C that you might need to fiddle with threads and the possible horrors of deadlocks and race conditions. When I ported Vertex Tools' soft-selection calculations to C it ran hundreds of times faster than the ruby version - no need for threading.