Rhino for Windows
willem — 2013-09-10T04:46:24-04:00 — #1
For many to most projects I make dedicated Scripts and Macro's.
Often this makes me wish for a way to store them inside the Document rather than externally and having to either open them when needed or create Aliases and Buttons for just that project.
What I imagine to be a very useful feature set, is a means to store those tools inside the Document. Lets call it the ScriptBox
In Basis is just like the current way Notes, Linetypes, DimensionStyles, etc can be (defined) and saved inside the file.
My quick brainstorm on how this should function GUI wise is to have a panel to manage, create, edit, load, export, and run various text-based automations.
One can create a new item
- New Macro
- New VBScript
- New PythonScript
One can select them from a list and Edit or Run them. Load or Export them.
Different types of scripts have different colors/icons to easily distinguish between types
and individual items have their own name. Editing is done inside the existing dedicated editors
yet from their they can be saved back into the ScriptBox
A typical workflow would be to start a project and at some point create a script in the Scripteditor.
Yet instead of saving that script to a .rvb or .py on my harddisk, I can also save it in the document.
File -> SaveInFile
This creates it as an item in my ScriptBox.
Next I can select that item in the ScriptBox and hit the run button.
What are your thoughts?
P.S. this reminds me of an old wish; to store display modes inside a file.
eg: sharing files with layouts in custom display modes is currently impossible.
pascal — 2013-09-10T11:48:31-04:00 — #2
I think this worth a look. @dale, is this feasible, do you think?
dale — 2013-09-10T13:41:37-04:00 — #3
Yep, this all sounds feasible. Might be a nice project for someone who want to learn how to write plug-ins.
willem — 2013-09-10T15:31:00-04:00 — #4
Sorry to start nit-picking immediately, but I think this should be properly implemented and integrated from the start. Especially the back and forth connection with the existing script editors is essential IMO.
So that requires an adaptation of existing features as well.
My reason for jumping at it like this, is that I know of too many features added to Rhino that still lack this type of integration or lack finishing touches, rendering the functionality and workflow with a feel of being half-finished.
I'm referring to things like the library panel that has a very minimal feature set and buggy behaviour. Unfortunately the same goes for the way Layouts/Pages and their Details are implemented; after 2 versions they still lack basic functionality like thumbnail views and drag-drop ordering of pages. Maybe this is due for an overhaul and extension for V6 already, but I prefer existing functionality to be finished, before new features like my ScriptBox are added.
pascal — 2013-09-11T17:11:36-04:00 — #5
Hi Willem- your comments seem to circle around to the understanding that it would take quite a bit of UI design and so on for your feature request, and that starting in on such a thing would not be justified by the demand, however reasonable the idea. So, in short, I think what Dale is suggesting is that you, or anyone with the need for the tool, and the scripting skills, could make something that would accomplish what you suggest, before we are likely to bring this to the front burner.
stevebaer — 2013-09-11T17:42:34-04:00 — #6
Yep, I'm not exactly sure I would approach this problem in the same way as originally suggested. It seems like there may be some other ways to have referenced scripts that don't specifically have to have similar copies sitting inside of documents.
willem — 2013-09-13T04:52:14-04:00 — #7
I think I got that feeling, but I needed to re-read your post a couple of times to understand the wordings.
When both my skills and time would suffice I'd give it a go myself. However setting up a UI like this is beyond my current skills. Dropping it here was merely a way to communicate a wish that could spark someones enthusiasm (be it someone from RMA or other).
willem — 2013-09-13T05:09:08-04:00 — #8
When you suggest that there need not to be copies inside the document, does that not imply that the document is not portable from one system to another? Can you elaborate how you would approach it?
My wish originates from the current situation that lacks an option to package scripts together with a file.
I think it is best compared with the option to save support file in 3dm feature.
However I'd not wish for these support files to be unpacked and copied to disk upon operation.
Or better: like currently dimension styles, linetypes and hatches are defined and stored inside a file rather than being externally referenced data. That makes the files fully portable with respect to those features.
(apart from the lacking font or otherwise)
If I now want to provide a client with a template file to process their geometry, there is no easy way to provide my custom display-mode, or scripts involved. If however these could be embedded in a file, all I needed to do is email the file and instruct to go to this or that panel, select the script and hit run.
No hassle, the display-modes would be as I have it and their systems would remain "vanilla" without clutter from my or others' previous display-modes and (aliased)scripts.
For my personal in-house use it would mean that many projects would not need to have extra folders with scripts, as I can now manage them inside the 3dm project file itself.
stevebaer — 2013-09-13T11:50:20-04:00 — #9
All I was trying to get at was that something like this seems like it should take a bit of design and thought before just blindly implementing that feature as a script packed in the file.
I'm not saying it isn't a bad request at all. There are just other ways to go about storing code than having a zillion copies floating around in every model file. If you find a bug in your script, it then becomes difficult to keep things synced if you want to.
willem — 2013-09-13T12:38:31-04:00 — #10
I see your point.
My request was about a script or macro in a single file without there being a way to manage any other copies. More complicated or less dedicated scripts are not suitable for that and we have ways to handle that already.
sampage — 2013-09-13T17:28:56-04:00 — #11
Perhaps something like linked and embedded blocks? Update the embedded version and are asked if you want to change the original, not embedded script file.
stevebaer — 2013-09-13T18:01:27-04:00 — #12
Yep, that's what I'm thinking about. Some sort of easy to use version controlled system that you could store scripts in a personal internet based account and the embedded scripts could be updated to reflect the more recent versions (or not).
willem — 2013-09-14T07:22:57-04:00 — #13
I see, sounds good, much more sophisticated than my initial thoughts.