Webdialogs for SketchUp ......RIP!
-
I thought Visual Programming was more of a concept. Like "flow-based programming" and it's likes.
I don't think neither Grasshopper nor Dynamo where created in Python ?
Don't know diddly about Python but here is a link:
I'm working on a node-flow based "thingy". And I think it's quite doable in Sketchups enviroment. Nothing fancy as Grasshopper, but maybe some modest usable plugin.
-
I think WebDialogs are far from dead, and that you have more chance of achieving the functionality of grasshopper [ ironPython when I tried it ] with a Ruby/Js combination.
with projects like http://jsmaker.com/jsmaker/ javascript is becoming the language of choice for cutting edge development, and it works well with ruby.
john -
Yeah, I'm not finding any references of such a python framework - let alone just a framework in any language.
And considering the advances of HTML5 and CSS3 - not only on the web but in apps on both mobile and win8 I don't see WebDialogs as a dead end. However, WebDialogs needs a cleanup and ship with a custom webcontrol independent from the OS and consistent across platforms.
This whole thing after to rather be a UI concept, which would be limited to language.
Sent from my LT25i using Tapatalk 2
-
@thomthom said:
Yeah, I'm not finding any references of such a python framework - let alone just a framework in any language.
And considering the advances of HTML5 and CSS3 - not only on the web but in apps on both mobile and win8 I don't see WebDialogs as a dead end. However, WebDialogs needs a cleanup and ship with a custom webcontrol independent from the OS and consistent across platforms.
This whole thing after to rather be a UI concept, which would be limited to language.
I think having the ruby<->js interactions done through
XMLHTTPRequests would be great too, because then we know for certain it's asynchronous can can use existing frameworks to aid the communication. -
hmm... I can see times where async can be useful, but more often I want synchronous communication.
-
Sometimes I want a method to wait until a webdialog is closed to give a return value. But all tries so far have frozen SketchUp and then also the webdialog. (Example usage: unit tests or API methods that don't work with async Proc callbacks)
WebDialogs are more cross-platform and scale better than SketchUp's own antique UI. Text fits on buttons. Following best practices makes them easily work with any dpi.
-
@aerilius said:
Sometimes I want a method to wait until a webdialog is closed to give a return value. But all tries so far have frozen SketchUp and then also the webdialog. (Example usage: unit tests or API methods that don't work with async Proc callbacks)
Can you not just set a semaphore in the closure?
-
Do you have an example code snippet? When I search for a ruby semaphore, I find threads etc.
-
actually, I don't think you even need atomic structures like semaphores.
All I'm saying is that in your *on_close()*or add_action_callback() methods, just set a flag.
So your (pseudo-) code is:
dlg.show
<wait until your flag has been set by the dialog callbacks>
... -
I will experiment again, but as far as I remember the single thread of SketchUp's Ruby freezes so that either the flag can not be set (because it is busy waiting) or whatever I do to wait never gets time to notice the changed flag.
-
@thomthom said:
hmm... I can see times where async can be useful, but more often I want synchronous communication.
How often does it actually need to be synchronous though? That is, the code must be executed before the next line. Also, how often can that not be turned into a async form (callbacks, promises, ...)?
My main point is that predictability and expectations are important in API design. Also, the current implementation (
window.location = ...) can have side effects - for example it will block/cancel any current requests, such as redirects or xhrs. -
@unknownuser said:
Also, the current implementation (
window.location = ...) can have side effects - for example it will block/cancel any current requests, such as redirects or xhrs.Oh - haven't noticed that yet! ...that should be in the Lost Manual... that's important stuff.
-
I vote for python. I work with it in cinema4d; ironpython - revit, robur(road software). And small [highlight=#ff4040:1yirh56j]c[/highlight:1yirh56j][highlight=#4000ff:1yirh56j]ythoning[/highlight:1yirh56j]
and it has 64bit framework or anyCPU type...if current sku team can not port ruby to x64.
-
I forgive Dan, he was probably off his meds again, although you can always count on him to give you his undivided attention when one is looking for a problem that needs solving.
I'm not talking about dumping Ruby.You can see the Visual Programming, in the attached pic, the underlying Scripting is what makes the 3d surface appear, but its not something the user has to concern him or herself about. If you want to experiment you can replace a DIV module with a MULTI module and see the 3d result instantly, or replace TAN with a COS module, etc. etc.
In addition, Download a free copy of Houdini from http://www.sidefx.com/index.php
and you will see the same principles as grasshopper. Houdini calls it Procedural modeling, as opposed to Visual programming. The process is the same.other examples of what grasshopper can do generating experimental Architecture. http://formularch.blogspot.ca/
-
Well, yea. Procedural modelling is a mighty interesting topic. However, there is nothing preventing that being done with the current Ruby API and WebDialog we already have.
Procedural modelling can be implemented in whatever underlying scripting or programming language is available.
I'm all for procedural modelling and I'm mighty interested in whatever project jolran is plotting.
-
Yet another Grasshopper framegrab...
One thing not discussed here regarding visual-flow-mombo-jumbo-programming is the complexity behind evaluating the chain of hierarchy, and when or what to update as soon as something changes in the gui.
I'm not sure Python would have any advantages over Ruby solving that computation..
But I guess that discussion is OT.
The GUI part is all very possible with webdialogs. In fact it's already happening
-
-
What I've produced after months of work you or some of the others JS-nerds around here(you know who you are!) could probably have duddled together in a weekend or less, Thomthom
Although the connector framework took some time to get acquainted with..
-
@tomot said:
I forgive Dan, he was probably off his meds again, ...
Or ON them. Sinus cold this past week!
@tomot said:
I'm not talking about dumping Ruby.
It's not feasible to have the app engine making two callbacks into 2 different scripting sub-processes.
IN truth... I am so weary of waiting for the Ruby API to be fixed, that I no longer care what language it is.
As long as it is fixed and kept updated.
If it's not Ruby, it is more likely to be Javascript IMHO.
-
@unknownuser said:
Javascript IMHO.
Especially since such a partly implemented API already exists, and even a first plugin.
Even if JS is not a beauty of a language, it's benefits are the wide-spread and the billions that have been invested into its speed optimization (although Python/Ruby&Co. have also benefited from such developments).For the original topic of this thread, neither webdialogs nor SketchUp's choice of scripting language matter. Node-based interfaces (previously mentioned as visual programming) are neither a replacement nor conflicting with webdialogs.
Advertisement