Transfer from Wiki --> developer docs - not necessarily an improvement

@scottd @dan

There are a bunch of pages that have been transferred to developer docs - such as this one, or this one which no longer have links to them from the Wiki… They should at least have a link from hereBut:

  1. Sending someone to the developer pages when they are just trying to get a handle on how to create a macro or put a script in a toolbar button or alias is not a good idea IMO - it’s very confusing for an ordinary user who lands on this page, the immediate reaction is “I’m not in the right place here” and will probably result in them just leaving the site rather than looking for the right link.

  2. It also means that people like me can no longer edit the pages. There’s a lot of stuff in there that needs updating - the first page above on installing macros dates back to XP days.

I understand the desire to centralize and rationalize this info, but if the result is that it becomes intimidating or inaccessible for some people, I’m not in favor of it. Plus that means that users can no longer contribute.


1 Like

You can edit these pages in a similar way as you did with the wiki (there is an edit on github link at the bottom of each page).

As for the table of contents page, I can see your point. We had a similar “big list” type page on the wiki and it was just hidden well enough that people didn’t typically land there. I would hope that people land somewhere like or instead.

Well, I’m thinking that’s maybe not really the best place to land for someone who just wants to learn how to make a macro or put one in a toolbar button… Already if it says “developer” people will wonder why they’re there…


Not familiar with Github editing, I don’t see any way to upload images or preview the page with them…


Making macros is one of the gateways to becoming a developer :grinning:

We should probably structure our general Rhino help documentation to give a quick overview of macros with links to the pages you mentioned as a way to get more information. That seems like a better route than landing on a random wiki page, developer doc page, or here on discourse.


We probably need to give you editing access first :slight_smile: Same rules apply as we had for the old wiki so the spammers don’t take over.

Will I see different options when you do? I logged in with my Github login, but I don’t see anything different.


Another typical approach that people do is fork the repository into their own github account, make a change and then submit a pull request for us in include this change in the main mcneel repository.

That’s a bit forking complicated… :exploding_head:

I would suggest you give this a try. It may sound daunting at first, but it is how the whole github ecosystem works and is a great way for us to review contributions.

Click the fork button on the repository and then make an edit in your fork.


OK, will do this tomorrow… too forking tired tonight. :tired_face:

Unless they have used Microsoft Office…

Dunno, no developer here…

That’s the point - though totally off-topic…
If you want to work with your macros in Word, you will need to turn on the ‘Developer’ ribbon.
(Word Options > Customize Ribbon > Main Tabs > check Developer)

Sorry, late to the party here. (Oh, so tempted to change the category of this post from “Meta” to “Rhino Developer” :smiling_imp:)

@Helvetosaur do you think it would help if we removed the redirects from the original wiki pages? (I’m not a big fan of this idea because I’m much rather help you and others get up to speed with editing the developer site).

I fully agree that editing the website is not as intuitive and WYSIWYG as the Wiki. This is something that I’d like to put more effort into in the future. That said, to many developers, editing markdown on GitHub is something they may be familiar with (if you had to pick one thing!). But I understand your point…it might be intimidating to land on the developer site. However - at the same time - there is some cross-over between Macros and the developer site.

Let me be more blunt: where do you think the best place is for Macro-related content?

Well, the question is - are you planning on eliminating the Wiki and doing something else in its place? Because there’s a lot of info in there that has nothing to do with “developer”. If you are planning to keep the Wiki, than yes, I think it needs ALL those links. Because I see the Wiki as Rhino “information central” - but maybe I’m too old school now…

Well, there are a couple of types of situations where people might go looking for info on both creating macros as well as implementing/installing them.

  1. The person is genuinely interested in learning how to customize their Rhino interface/workflow. In this case, if the person falls into the developer section it’s probably OK, especially if the landing page is well illustrated and written in language an average user can understand . If there is a nice progression leading the person from the first baby steps up through the intermediate level and even opening the door into some simple scripting concepts, that would be great.

  2. The person has been sent to this page from the forum or elsewhere - because a more advanced user has posted a script/macro to solve their particular problem, and they want to get it installed and running in their Rhino with the least amount of effort. For these people, IMO they need a simple spot to go with some clear basic instructions and nothing else. They will not likely be interested in going further.

As far as Github editing goes, I’m sure it’s not beyond my capability. If I have to do my editing by forking a page, editing the copy and then submit a pull request and wait for it to get approved/uploaded, that does take out the immediacy of it. Sometimes I just want to get some info up there fast. sometimes I spend a lot of time “tweaking” with repeated saves… So there’s another hurdle for me to jump over is all.

I also wonder who edits or adds pages to the Wiki these days - aside from official McNeel people, it seems like it’s only me? I just know there’s a lot of info up there that hasn’t been updated since Rhino 4 or so. From time to time I do edit a page to reflect more current info, but some pages also need a complete re-write. Unfortunately, I haven’t a huge amount of time these days, but who knows, in a year or so, I might…


No. As far as I know, we have no plans to eliminate the wiki at the moment.

With the site, one of our goals was to remove this information from the wiki and centralize it, curate it better, and make sure that it was version-specific (no mixing content from Rhino 3, 4, and 5). We also wanted it to be under version control and open to public editing (pull requests). We have lots of other goals that we’ve not yet attained, but that’s another subject.

Interesting. I see it as just another source of information. But you are old school in the best way Mitch!

For the record, I was not a fan of the idea of including Macro information on the developer site, for the reason you elucidated at first: it’s a little confusing to land on a developer site if all you want to do is automate a couple commands, but I can certainly understand the argument of it being a gateway drug. But I thought: well, we have to draw a line somewhere.

I don’t think so at all. It just takes a lot of getting used to if you’ve not done it before.

I think we need to figure out better ways to remove some of these hurdles.

From what I can tell, it’s a handful of people…mostly internal. But I don’t dispute that it’s easy to edit and has a wealth of information …some of it - as you pointed out - completely obsolete and misleading.

Now you sound just like me…well, I would probably say: “I’ll get to it in three weeks.”


Here’s what I just did:
I removed the redirect that was in place between:

I would suggest that we start moving any macro related content out of the folder. Perhaps we can start a folder. Does that seem like an appropriate spot?

(I’m not removing the macro content from yet because some of the guides you alluded to were written to support other guides on the developer site. If this becomes a problem, we can revisit it.)