Webdialogs for SketchUp ......RIP!
-
If Web dialogs & Ruby are not they dead yet, they really should be soon. The only reason they may not be dead yet is too many people have invested too much time in this approach, and hence don't want to change, or lose their jobs. There is a new framework called Visual Programming & Scripting. All of them are Python based. Many 3D programs use Python scripting, furthermore Visual Programming & Scripting is making it easier to engage the casual user of 3D to make his or her own visual scripts, without much investment in learning programming.
Current examples of programs that use Visual Programming & Scripting:
-
Vasari & Dynamo for AutoDesk Revit: http://wikihelp.autodesk.com/Vasari/enu/Community/Tutorials/Vasari_Talk_-_Design_and_Analysis_Webinars/Session_20%3a__Augmented_Parametric_Design_with_Dynamo
-
Grasshopper for Rhinoceros: http://www.grasshopper3d.com/
I realize most users don't like change, unless it offered by politicians,
But I would suggest a new Python API be developed. I'm not sure if both a Python API and the Ruby API could get along together. If they can't, offer 2 versions of SketchUp one with either API. It wont take long before users will prefer to change to the new Python API. Particularly when they start seeing the advantages over the old Ruby API methods.I hope Trimble has the courage to take a look this proposal.
-
-
Hi,
Saw one of the videos you posted and was really impressed. The ideal situation is for both Webdialog and Visual Programming & Scripting be available for us to use.
Cheers!
-
This suggestion is not new.
YEARS AGO some people asked to use a Python API instead of Ruby.
YEARS AGO some other people asked to use a Java API instead of anything else.
Both of these camps used the same arguments.
So it really just comes down to preference. People who know and love a certain scripting language do not want to use any other.
Most of the people making these demands have gone away because they hate Ruby so much.
Oh Well... no tears for them. There are plenty of other software packages that use their preferred scripting language.
I LOVE RUBY and want SketchUp to continue to use Ruby
Anyone who hates Ruby.. can just go and use some other software.
%(#BF4000)[If you trash Ruby.. I TRASH YOU !
] -
@dan rathbun said:
%(#BF4000)[If you trash Ruby.. I TRASH YOU !
]That made my day!
Didn't realized that Ruby had to be eliminated for Visual Programming & Scripting to work.
If maybe there was a way to make SketchUp compatible with both then maybe Dan Rathbun will approve.
-
I doubt that more than one scripting interface can be used at a time.
It would cause twice the slowdown.
-
@dan rathbun said:
%(#BF4000)[If you trash Ruby.. I TRASH YOU !
]I can appreciate that for 1.9.x or 2.x, but for 1.8.6?
-
@tomot said:
IThere is a new framework called Visual Programming & Scripting.
Link to this framework?
-
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.
Advertisement