SketchUp RUBY API Wishlist [way of coding wishes, please]
-
@david. said:
Jim,
Nice idea. Also, I'm curious if you mixed in the Singleton module to implement your singletons? I've found that I can't require a library module like Singleton unless I point directly to my Ruby installation directories. I realize that this isn't required to implement singletons, but it seems the most simple and consistent.
Hi David,
Yes, I used the singleton class from Ruby. I copied singleton.rb from the Ruby language installation to a 'ruby' folder in my Sketchup/Plugins folder. The Ruby singleton is very easy to use, and was simply the best and fastest solution. I think there are a few other files from the installed Ruby files that I needed also.
-
Hello
Inside SketchUp it works fine but when creating an AVI file with Export -> Animation
the - Sketchup::Pages.add_frame_change_observer - is not firing between frames.Is there anything i should change or another observer i can use between frames in Export Animation ?
http://www.sketchucation.com/forums/scf/viewtopic.php?f=180&t=10926
Thanks
-
One of the more important things that could be done using the Ruby API, and which would benefit nearly all users is a unified API for menus and toolbars. I don't mean being able to lock toolbars; I mean the possibility to provide menu and toolbar customization using a "Menu & Toolbar Editor" within SketchUp.
The need is apparent in CadFather's Toolbar plugins; where he creates a collection of scripts and adds toolbar buttons for them. Although these are nice toolbars, they are going to prove difficult to maintain as scripts are updated and obsoleted.
Really, there would need to be some registry that would:
- "install" a plugin so that is is not located in the Plugins folder, and so not automatically loaded.
- allow un-modified plugins to continue to function.
- allow new/modified plugins to create new, or be added to, existing menus, submenus, and toolbars.
- handle the creation of menus and toolbars at startup.
The possibilities are fantastic, if you let your mind run wild:
- allow menu/toolbars "sets" to be created.
- allow plugins to be downloaded as-needed, or used online. (zero install: net_require "progrsssbar.rb")
- check new versions of plugins online, and upgrade.
Of course, I do not mean to remove the ability for developers to create their own menu or toolbars. But even if it's just for the numerous scripts that are single-menu, or single-button plugins, this would be an improvement.
-
Hi guys !
I wish one day, we would have access to print parameters via ruby... One day... -
An important wish for ALL exporters, I believe:
- a method to read a cropped region in 2point perspective view.
As far as I am aware, currently there is no way to read it!
Please!
- a method to read a cropped region in 2point perspective view.
-
A Ruby method that will give us a real UVW coordinates of a projected texture, so exporters could use a single, original texture, instead of say 200 small textures of a photo mapped terrain.
-
A switch (if it does not exist) to activate a ruby on selection of an entity or entities to allow interaction with a webdialog.
See:
http://www.sketchucation.com/forums/scf/viewtopic.php?f=180&t=14299Thanks
Chris
-
@chrisglasier said:
A switch (if it does not exist) to activate a ruby on selection of an entity or entities to allow interaction with a webdialog.
See:
http://www.sketchucation.com/forums/scf/viewtopic.php?f=180&t=14299Thanks
Chris
Search v7..............
-
@unknownuser said:
A Ruby method that will give us a real UVW coordinates of a projected texture, so exporters could use a single, original texture, instead of say 200 small textures of a photo mapped terrain.
Agree!
-
Hi ScottLininger.
Not realy a ruby way of coding, but almost...
I mentionned it in an another post: It would be so nice to retrieve a variable from a model into a dynamic component's attribute instead of the opposit (right now, if I understand well, it is only possible to "export" and to make a code to fill the DC's attribute).By the way, I would be very glad if we could learn from your famous animated "sprite" code
Thanks!!!
-
-
hello Scott,
Thanks for your interest in helping out. That game you made was pretty cool.I would like to see some convience methods like in the Blender API. This may not be appealing to Gurus but might be quite helpful to the new rubyist. Something like...
obj.LocX --> (0,0,0) obj.LocX += 20 obj.LocX --> (20,0,0) obj.loc = 0,0,0 #set loc obj.getMatrix()
i am also wondering why there is no way to do simple and dirty animations, like...
Loop obj.LocX += 10 sleep(.02) SU.Redraw()
I really like most of the SU API's layout compared to Blender, except the Transformation module, it seems a little clumsy. But i might be missing something important. I am not an engineer, just a real brave lad, thats all.
So if you want to enlighten me, feel free
-
I'd like to be able to specify the font size for text objects.
-
I would like to see a GUI added to the Ruby API. This has been sadly lacking from when the Ruby API was first added to be the scripting language for SU. Please add this to your SU8 wish list. Failing that, perhaps an easier task maybe to add a Python API with GUI to SU. I see no reason why SU can't function with 2 scripting languages.
-
A GUI to the API what do you mean? As oppose to Webdialogs?
-
I think what tomot wants is a GUI toolkit built-in for SU scripting. Web dialogs are quite lacking. Scriptwriters need widgets!
Text, Listbox, Entry, Button, Frame, Toplevel, Spinbox, Label, Scrollbar, Dialogs, RadioButton, CheckButton, Menu, Scale, LabelFrame, Canvas, OptionMenu, PanedWindow, Image Support
Python has all this built-in to the language as Tkinter(Tk widgets) An easy to use GUI builder with every thing a script writer/SUupper needs, amoung others.
I will also volunteer to do most of the dirty work to grow a Python API(and i could get others to help also -- SU DEV would not have to do much).
One of the best things about Python as compared to Ruby is the tons and tons of great documentation. This would be very appealing to those who wish to script but cannot find good docs for Ruby. And the built-in GUI is just icing on the cake!
-
@jessejames said:
I think what tomot wants is a GUI toolkit built-in for SU scripting. Web dialogs are quite lacking. Scriptwriters need widgets!
Text, Listbox, Entry, Button, Frame, Toplevel, Spinbox, Label, Scrollbar, Dialogs, RadioButton, CheckButton, Menu, Scale, LabelFrame, Canvas, OptionMenu, PanedWindow, Image Support
Yes that's exactly what I meant. Here is a Google definition of Webdialogs:
By using powerful cross-browser Javascript and CSS, WebDialog renders dialogs, windows and even modal dialogs inside the browser window. It avoids the problems caused by restrictive popup blockers and gives you greater flexibility when designing your web application's user interface.
That's not going to help my scripting endeavors without now also having to learn Javascript and CSS.
JJ you put a generous offer of the table, I would like to contribute where ever possible. Lets hope we can get ScottLininger on board? Because without some support from Google I can't see this going very far.
-
Coming from a webdesign background I forgot that HTML, CSS and JS is also a thing to be learnt. I see your point. I was just confused because you allready have most of the controls JJ mentioned. But as you say, it a new set of languages to learn.
As for the lacking set of widgets, there are many frameworks that can easily be added on to extend the widget collection.
But I'm puzzled by another thing, tomot; you would be willing to learn Python to make a GUI, but not CSS+JS?
-
@thomthom said:
But I'm puzzled by another thing, tomot; you would be willing to learn Python to make a GUI, but not CSS+JS?
It may surprise you Thomas; I'm not a Ruby programmer or a LISP programmer nor GDL http://en.wikipedia.org/wiki/Geometric_Description_Language programmer.
I could not sit down with a text editor and bang out a new Ruby without at the same time having open on my Desktop at least 2 or 3 existing Ruby's whose content may help form the basis of a new ruby idea I'm trying to bring into being. Then through lots of cutting and pasting of code and many trials and errors of loading and reloading the same script into the console, over and over again, I eventually arrive at the solution. The programming related lines I can't solve I usually bring forth to this forum for help from those that have real programming knowledge, and I'm always grateful for their support. The following piece of code was provided by Jim Foltz.normal = useanamehere.normal normal.length = -$xxx tr = Geom;;Transformation.translation(normal) group.transform! tr
This small piece of code has been invaluable, its used repeatedly to offset distances that make 2d lines into 3d, planes, without it Window and Door Tools could not exist.
Its also one of the reasons I'm grateful that not each Ruby contributor decides to use obfuscation on their code. Obviously if everyone did this, this community would not have benefited from my Window and Door Tools scripts.
If this Python API works out, I will approach scripting with it the same way I do with Ruby. Firstly I would ask for some simple existing Ruby's to be converted to Python. I would use that as a springboard to start scripting in Python.
-
@tomot said:
...I could not sit down with a text editor and bang out a new Ruby without at the same time having open on my Desktop at least 2 or 3 existing Ruby's whose content may help form the basis of a new ruby idea I'm trying to bring into being. Then through lots of cutting and pasting of code and many trials and errors of loading and reloading the same script into the console, over and over again, I eventually arrive at the solution.
I agree tomot,
The work flow for writing scripts in SU is frustrating. This must be improved. Nobody(pro or not) has the ability to write bug free scripts in one go.1.) A built-in text editor(very simple) with syntax highlight so a new scripter can get started easily
2.) a multi-line Console(for testing snippets with proper indentation) to replace the single line Ruby Console
3.) a real GUI toolkit(Python has TK built-in to the language)
4.) a good SU specific scripting tutorial.( most important )These are the key to happy SU scripting.
The current work flow is painful and a real determent to all who wish to learn, or write scripts for SU. Something must be done. Scripting must be made available to all, not just a few professionals at the top.
SU design is flawless everywhere but this area. Once we can fix this, the full power of SU will be available to all.
Advertisement