Rhino.Inside.Revit Docs
Contributing to the Docs
- Applying Minor Changes Using the GitHub Editor
- Clone, Revise, Submit Pull-Request
Online Experience
Understanding Docs Source Files
Docs Formatting Conventions
Sample Pages
Data Sources

Rhino.Inside.Revit Docs

This repo contains the contents of https://mcneel.github.io/rhino.inside-revit/

The site is hosted on GitHub Pages which uses a static site generator called Jekyll.
The page are written using Markdown (specifically Kramdown) syntax
The contents of the Docs are stored under pages/ and are grouped by locale (e.g. en for English) and Rhino.Inside.Revit versions e.g. en/beta/getting-started.md for Getting Started article in English for Beta release.
All static resources, e.g. image or Revit models are stored under static/
Front-end assets are under assets/. Please coordinate any changes with the authors

Contributing to the Docs

There are multiple ways to edit the pages hosted in this repo. There are pros and cons to each approach. Each of the items listed here, is described in detail in sections below.

Edit the Markdown (*.md) files directly on GitHub using the GitHub online editor
Clone the repository on your machine, edit the Markdown files, and commit back to the repo

Applying Minor Changes Using the GitHub Editor

This approach is great for making minor changes to a few pages on the wiki (e.g. fixing a typo or a broken link). However, you need to have write access to the repo to be able to change the pages directly on GitHub.

To quickly edit the page, browse to the page on GitHub, then click on the pencil button to start the edit process:

Make your changes, following the document structure and the Markdown syntax. Then scroll to the button of the page, fill in the title textbox (single line) with a short description of the changes, and then fill in the extended description textbox with detailed information about the change if necessary.

Finally, you can either choose to commit to master, or commit to a separate branch and create a pull-request. In most cases it is safer to create a new branch and submit a pull-request.

Clone, Revise, Submit Pull-Request

The most popular, and by far, the most flexible approach is to clone the repository on your machine and make the necessary changes to the content. This approach is great for making lots of changes and adding new content to the wiki (e.g. if you want to translate the wiki to your own language).

This step requires basic knowledge of git and GitHub. The initial setup for this approach might also look a bit complicated. The steps below will take you through the one-time initialization that is required to be able to test your changes before committing to the source repo.

Getting git

git is a utility library and has an official command-line-utility (CLI) that could be downloaded from the git website. The git library is used in many Graphical User Interface (GUI) to provide a more approachable interface to git. A few of these utilities are listed here:

Original git CLI
- git Cheat Sheet will be helpful when working with the git CLI
SourceTree
GitKraken
Git Fork
GitHub for Mac
GitHub for Windows

These utilities have very comparable feature sets. Choose one that you are comfortable with. For the sake of this tutorial, we focus on the git CLI.

Cloning the Repository

Once you have installed the git CLI, open a shell (e.g. PowerShell in Windows, or bash in macOS) and navigate to a safe directory. Then clone the repo using the command below. If you do not have write access to the original repo, you need to fork the repository using GitHub and then clone your own forked repo on your machine. This will allow you to make the changes and publish them back to your own fork on GitHub, and create a pull-request from your fork, to the original repository.

git clone https://github.com/mcneel/rhino.inside-revit.git

Installing Ruby

Jekyll is a static site generator that is written in ruby. We need to install Ruby first

Windows

Download the latest Ruby installer for your machine architecture (x86 or x64). Make sure to download the installer that includes the Dev kit. See the links under WITH DEVKIT section on the download page.Jekyll won't be fully functional without the dev kit.
At the Installation Destination and Optional Tasks dialog, make sure to check the Add Ruby executable to your PATH box.
Install Ruby to the default path (usually C:\RubyXX-xXX)

After the installation is complete, open a shell and navigate to the install path and run the commands below to initialize the developer kit.

cd <ruby-install-path-on-your-machine>
ruby dk.rb init
ruby dk.rb install

macOS

macOS is shipped with Ruby, however it's not wise to mess around with this installation. macOS has a pretty awesome package manager called Homebrew. We will use this package manager to easily install Ruby. First install homebrew using the directions on the Homebrew homepage (macOS will prompt you to install the Xcode Command Line Tools, if you have not already installed. This is normal)

Now we can install Ruby.

brew install ruby

Installing Jekyll

Now we will install Jekyll. GitHub provides the same version of Jekyll as exists on the GitHub Pages servers. This ensures we aren't accidentally using features that have either been deprecated or simply don't exist yet! We will also install a few utilities that are provided by GitHub to make the process easier.

Navigate to the clone directory and run the commands below.

gem install jekyll
gem install github-pages
gem install wdm

Building the Docs using Jekyll

In this step we will ask Jekyll to parse the wiki source files (e.g. Markdown files and configurations), and build the final static website.

Using a shell, navigate to the local clone directory. Then run the command below.

jekyll build

Alternatively, or in case of errors in command above, you can also run

bundle exec jekyll build

Jekyll will parse the file and will build a static version of Docs into _site/. GitHub later uses this directory to serve the Docs to the users. To preview the website, run the command below

jekyll serve

Alternatively, or in case of errors in command above, you can also run

bundle exec jekyll serve

Jekyll will build the website, and will run a local web server and, by default, starts listening to http://localhost:4000. You can open a browser and navigate to this address to see the website preview. Remember that this is a preview, built from your local changes. We still need to publish the changes to the source repo.

Shutdown the server by pressing CTRL-C in terminal.

Make Necessary Changes

Now you can make the necessary changes to the Docs pages

Spell Check

This Docs has been edited using VSCode with Spell Right extension for spell checking. There is a spell check dictionary under .vscode/ directory named spellright.dict and contains the excluded words and phrases for the spell check extension.

Publishing the Changes

Once you are done with your changes, submit a pull-request through GitHub. If you don't have write access to the repo, an author will review your pull-request and will merge or comment. Please follow the pull-request until your changes are completely merged into the master.

Online Experience

This Docs is the first node and the official landing page for the project. See the sketch below to see the overarching ideas that helped designing this Docs.

Docs homepage is the official landing page
Docs helps:
- Getting started
- Learning how to tackle Revit challenges using Rhino.Inside and provides easy to access samples
- Provides the in-detail documentation on various aspects of the project
Docs then
- routes the user to Forums for more questions
- and routes the advanced users to the repo
The Repo
- provides the source code
- provides the files for the Docs

Understanding Docs Source Files

As mentioned above, the wiki is built using Jekyll and is hosted on GitHub Pages

The structure of the source is as explained below:

_layouts/ contains Jekyll page layouts of various types (e.g. full-width page vs page with sidebar)
- ltr/ contains layouts for Left-to-Right (LTR) languages
- rtl/ contains layouts for Right-to-Left (RTL) languages
_includes/ contains Jekyll page fragments used across various page layouts
- ltr/ contains fragments for Left-to-Right (LTR) languages
- rtl/ contains fragments for Right-to-Left (RTL) languages
pages/ contains the Docs contents grouped by language and wiki version
assets/ contains all front-end assets
- css/ contains all front-end stylesheets
- js/ contains all front-end JavaScript
- img/ contains all front-end images
static/ contains all static files
- images/ contains all images used across the wiki contents
- samples/ contains sample data files
- ghnodes/ contains Grasshopper component files
- src/ contains all source files used to generate the files under static/
_data/ contains data files used to generate special pages
_config.yml Jekyll site configs file (see the config file for more information on each available setting)
GemFile* Ruby gemfile listing the ruby dependencies
index.md Root of the Docs. It redirects the visitor to default language and Docs version (defaults are set in the site configs file)
readme.md: This Markdown document
update_components_data.gh: This is a Grasshopper definition file, used to generate component data file under _data/

Page Metadata

Each page must contain some required metadata at the top of the page.

---
title: Components for Revit
order: 2
group: Modeling    <- this is optional but provide on most pages
---

Required metadata are

Title
Order set the order only for sections that have ordered articles e.g. Guides
Language Set automatically by site configuration. do not set manually
Version Set automatically by site configuration. do not set manually
Category Set automatically by site configuration. do not set manually
Layout Default layout is set automatically by site configuration. override only when your page layout is different from default. See site config file for default layout
TOC All pages are set to toc: true so they will be included in Side panels. Set to toc: false to omit the page from side panel lists e.g. samples/index.md` is omitted from the side panel this way.

Page GH Definition

For some pages a GH definition is used to generate screenshots. The page can provide a download link to this GH definition (stored under static_src/gh-screencaps/) using the key below:

...
ghdef: revit-walls.ghx
---

Page Layouts

There are there main layouts created for this wiki. You can specify the layout using the layout: directive on the page metadata e.g. layout: page-h2-toc

_layouts/page-fullwidth.html fills all the horizontal space of a wiki page
_layouts/page-h2-toc.html page with sidebar listing h2 (##) and h3 (###) elements inside page contents
_layouts/page-list-toc.html page with sidebar listing all pages of the same category, version, and language. Each active page also lists h2 (##) elements inside page contents as secondary links

Adding a New Language

To add a new language to the Docs, a translator generally starts with the English version of the wiki and translates the content. Copy the pages/_en content to a new directory under pages/ with your ISO 693-1 language code. For example to translate the English wiki to Persian, copy the pages/_en content to pages/_fa

Now open the site config file and add the new language to the Jekyll site collections:

collections:
  en:
    output: true
    permalink: /en/:path

  fa:
    output: true
    permalink: /fa/:path

Instead of adding language: fa to the metadata for every single page, we will edit the site config file to add this metadata to the new pages automatically based on their location in directory structure.

Open the site configurations and add a new scope under defaults: for the new language:

defaults:
  - scope:
      path: ""
      type: en
    values:
      language: en

  - scope:
      path: ""
      type: fa
    values:
      language: fa

Jekyll site config file automatically sets the correct version and categories on the new page.

Once the new language directory is created, open each page under each version and translate the page contents. And finally when all the translations are completed for all the content, notify the developers by creating an issue on the GitHub repo to incorporate the new language into the website.

Adding a New Docs Version

To add a new version to the Docs, browse under the site contents for your language and create a new version directory following the X.X format. For example to add version 1.5 to the wiki for English language we need to create pages/_en/1.5/ directory.

Instead of adding version: 1.5 to the metadata for every single page, we will edit the site config file to add this metadata to the new pages automatically based on their location in directory structure.

Open the site configurations and add the new version to the list of site versions. You also need to provide the download links to Rhino.Inside and Rhino installers for the new version:

# site versions. ordered from most recent to oldest
# id: use a valid id for each version. this id is used to retrieve info about
# the version in liquid tags e.g. {{ site.versions.one.rir_download }}
#   version: version directory name
#   name: version pretty name e.g. v1.0
#   rir_download: download link for rhino inside Revit
#   rhino_download: download link for Rhino
versions:
  onefive:
    version: 1.5
    name: v1.5
    rir_download: 
    rhino_download:

Add a new scope under defaults: for the new version:

defaults:
  - scope:
      path: "pages/*/1.0"
    values:
      version: 1.0

  - scope:
      path: "pages/*/1.5"
    values:
      version: 1.5

Jekyll site config file automatically sets the correct layout and categories on the new page.

Copy the wiki contents from the previous version to this directory and edit the pages as desired.

Adding Button-Specific Documentation

Each button can have its own documentation page. The contents of this page is inserted after the button name and information, on the button reference list. To create a new button documentation page, create a markdown file under the pages/<language>/<version>/reference/buttons/ and set the name of the file to the title of the button.

For example page pages/_en/beta/reference/buttons/Rhino.md contains the English (_en) docs for the beta version of the button with title Rhino which is the main Rhino button in the interface.

Make sure to provide the minimum metadata for button-specific pages. See below. Notice that toc: false to avoid listing these pages in side panels.

---
title: Rhino Button
toc: false
---

Adding Component-Specific Documentation

Each component can have its own documentation page. The contents of this page is inserted after the component name and information, on the component reference list. To create a new component documentation page, create a markdown file under the pages/<language>/<version>/reference/components/ and set the name of the file to the UUID of the component.

For example page pages/_en/beta/reference/components/273ff43d-b771-4eb7-a66d-5da5f7f2731e.md contains the English (_en) docs for the beta version of the component with UUID 273ff43d-b771-4eb7-a66d-5da5f7f2731e which is the Material.ByColor component.

These component-specific pages can be directly access as well. For example the component page discussed above can also be directly accessed through http://.../en/beta/reference/components/273ff43d-b771-4eb7-a66d-5da5f7f2731e

Make sure to provide the minimum metadata for component-specific pages. See below. Notice that toc: false to avoid listing these pages in side panels.

---
title: Material.ByColor
toc: false
---

Adding Release Notes

Follow the steps below to add new release notes. Most recent release should be on top:

Open the Reference / Release Notes page
Copy the release notes block from previous release and add the new build info to version= and time= attributes
Write down a list of notes related to the release
Add images if necessary. Place images under static/images/release_notes and name by the release e.g. 0073256343_01.png is the first image (_01.png) for release 0073256343

Docs Formatting Conventions

Frequently User Terms

The site configuration file has a list of frequently used terms. When adding or modifying content, ensure that you are using liquid tags instead of typing these terms. This allows for modifying the terms later on without having to chase down all instance of the term across the Docs.

These terms are stored under terms: in site config file:

terms:
  mcneel: Robert McNeel & Associates
  rhino: Rhino WIP
  rir: Rhino.Inside.Revit
  revit: Autodesk Revit®
  bim360: Autodesk BIM360®

You can refer to these terms using liquid tags. Jekyll will automatically place the correct term when rendering the page. In the example below {{ site.terms.rir }} will be replaced by Rhino.Inside.Revit

- **Reference** This sections contains advanced and detailed documentation on various aspects of the {{ site.terms.rir }} project

Linking Other Pages

You can use the format below in your pages to point to other pages on the Docs. Never refer to a page from another Docs language or version. All the inter-page links should be restricted to pages of the same language and version. This helps keeping the Docs in clean containers.

{{ site.baseurl }}{% link _en/beta/reference/rir-interface.md %}

You can combine this with markdown link convention so the link has a title

[Rhino.Inside.Revit Interface]({{ site.baseurl }}{% link _en/beta/reference/rir-interface.md %})

Linking Images

You can add images to your page using the standard markdown image links. Make sure the source image is properly organized under the static/images directory.

![]({{ "static/images/started/revit-doc.png" | prepend: site.baseurl }})

The Kramdown syntax also allows for applying inline attribute overrides to the image elements. In the example below, the {: class="scale-half"} part after the image tag (notice no spaces between the two) applies the CSS class scale-half to the image element:

![]({{ "static/images/started/revit-doc.png" | prepend: site.baseurl }}){: class="scale-half"}

Grasshopper Screenshots

When discussing abstract concepts or specific functionality of Grasshopper components or groups of components, avoid including the Grasshopper background in screenshots for a more pleasing image. You can use the hi-res screenshot export tool in Grasshopper to generate a PNG with transparent background from your definition.

For example:

Looks better than:

It is okay to include the Grasshopper background if the image is about a specific definition or feature. That way, the background can help providing context to the reader. In this case make sure to use the default Grasshopper background. The image below shows a specific part of a definition and has the default Grasshopper background included.

Linking Videos

You can use the predefined html fragments to easily add videos to your pages. Currently fragments for YouTube and Vimeo has been implemented under _includes/. Each fragment takes the video Id as an argument and imports the necessary html elements into the final rendered page.

{% include youtube_player.html id="DZ4y-ZbBkM" %}

or for Vimeo,

{% include vimeo_player.html id="280080233" %}

For YouTube playlists use:

{% include youtube_list.html id="DZ4y-ZbBkM" %}

Referencing Grasshopper Components

To reference any component that is part of this project, use the pre-defined block shown below:

{% include ltr/comp.html uuid="15545e80-" %}

The 15545e80- is the first part of the component uuid. This information is stored in the component data file generated from the actual components in this project.

The site builder, automatically finds the component data based on the provided uuid part, and places the component title and icon instead. The image below shows how the Query Materials component reference looks like on the wiki:

extended= to show component description in front of title
no_version= to hide the "added since" and "removed since" version tags

Referencing Grasshopper Parameters

To reference any parameter that is part of this project, use the pre-defined block shown below:

{% include ltr/misc.html uuid="15545e80-" %}

It works exactly the same as the reference components block.

Adding Email Links

Emails links (mailto:) need to be obfuscated to avoid crawlers to extract email from the Docs pages. Use the method described below:

Open developers tools in your browser.
Open JavaScript console tab
Create the mailto: link string e.g. mailto:test@website.com?subject=Email Subject
Type in btoa('put link string here')
Save the result base64 string into data-dump= attribute in link format below
Change anchor link title (Email Link Title) to desired title
Place the html anchor element in your page

<a href="#" data-dump="put generated base64 string here" onfocus="this.href = atob(this.dataset.dump)">Email Link Title</a>

Pre-defined Blocks

There are a couple of pre-defined blocks that you can use in your content by using the {% include} tags. These blocks and their usage example are listed below.

Note: Notice that some of these block have been placed under ltr/en for English (Left-to-Right). If you are translating content for your own language, duplicate and translate the content of the block. Make sure to place the new block file in the appropriate directory structure.

Note: Some of the blocks can accept arguments. You can use the {% capture tags to capture a larger piece of content and use that as the value for the arguments (e.g. note= in example below):

{% capture api_note %}

In Revit API, all the built-in parameters are represented by the {% include api_type.html type='Autodesk.Revit.DB.BuiltInParameter' title='DB.BuiltInParameter' %} enumeration

{% endcapture %}

{% include ltr/api_note.html note=api_note %}

Work-in-Progress Block

This block is meant to show upcoming content on your page. Make sure to replace with actual content and don't leave these blocks on the Docs for too long.

This is how you would insert a WIP block into your page.

{% include ltr/en/wip_note.html %}

Revit API Link Block

This block generates a URL to the desired type on apidoc.co. This block takes two parameters as input:

type= the target type to generate the URL for
title= the title of the generated link

The example below generates the URL for Autodesk.Revit.DB.BuiltInParameter enumeration type:

{% include api_type.html type='Autodesk.Revit.DB.BuiltInParameter' title='DB.BuiltInParameter' %}

This block uses values shown below in site configuration to generate the URL:

# revit api version used to generate api links on apidoc.co
revit_api: 2020

Warning Note Block

This block is for showing alerts and warnings in your content. Below is an example of using a warning note block:

{% include ltr/warning_note.html note=api_note %}

This block can accept two argument:

note= for the note message
image= for the header image above the note

GitHub Issue Note Block

This block is for showing code-related issues on the GitHub repo. Below is an example of using an issue note block:

{% include ltr/issue_note.html issue_id='142' note='Add Views to category pickers so an {% include ltr/comp.html uuid="d08f7ab1-" %} can be used to list views' %}

This block can accept two argument:

issue_id= for id of the GitHub issue e.g. 142 in https://github.com/mcneel/rhino.inside-revit/issues/142
note= for the note message

Bubble Note Block

This block is for showing tips in your content. Below is an example of using a bubble note block:

{% include ltr/bubble_note.html note='Note text' %}

This block can accept two argument:

note= for the note message
image= for the header image above the note

API Note Block

This block is for comments related to the APIs. These notes are usually used to explain how APIs work in specific cases. Below is an example of using an API note block:

{% include ltr/api_note.html note='Note text' %}

This block can accept two argument:

note= for the note message
image= for the header image above the note

Locale Note Block

This block is for comments related to the various languages supported by the host software. Below is an example of using a locale note block:

{% include ltr/locale_note.html note='Note text' %}

This block can accept two argument:

note= for the note message
image= for the header image above the note

This is the code used to generate the example locale block shown in the image above.

{% include ltr/locale_note.html note='Since we are specifying the name of parameter in a specific language, the definition will break if opened on a Revit with a different language. A better way (but a lot less intuitive) is to specify the API integer value of the built-in parameter as input value. You can get this value by converting the DB.BuiltInParameter value to an int in python.' image='/static/images/guides/revit-params06.png' %}

Filter Note Block

This block is to add string filtering documentation, particularly for components that take a string input that can also act as a string filter:

{% include ltr/filter_note.html note='Note text' %}

This block can accept two argument:

note= for the note message
image= for the header image above the note

This is the code used to generate the example locale block shown in the image above.

{% include ltr/filter_note.html note='The Class and Name inputs accept Grasshopper string filtering patterns' %}

Download Package Block

This block is for buttons to download packages (Zip, ...)

{% include ltr/download_pkg.html archive='/static/archives/column-family-along-curve.zip' %}

This block can accept two argument:

archive= link to the downloadable file
title= for the button title (Optional: defaults to Download Sample Files)

Download Component Block

This block is for buttons to download Grasshopper components (GH Clusters, ...)

{% include ltr/download_comp.html archive='/static/clusters/Type Family.ghcluster' name='Type Family' %}

This block can accept two argument:

archive= link to the downloadable file
name= of the Grasshopper component
panel= name of the panel in Grasshopper interface formatted as Tab name > panel name (Optional: defaults to Revit > Custom). Panel name shows up on the note below the button.

Download Definition Block

This block is for buttons to download Grasshopper definitions

{% include ltr/download_def.html archive='/static/ghdefs/AssetsPlayground.ghx' name='Assets Playground' %}

This block can accept two argument:

name= name if the downloadable definition

Release Header Block

This block is release headers on Release Notes page. This block can accept two argument:

version= release version (without prefix v)
time= build time

{% include ltr/release-header.html version="0.0.7317.30902" time="1/13/2020 17:10:04" %}

Keyboard Key (Inline)

This block generates keyboard key images. Use this for showing single keys inline with text. This block has one required argument:

key= keyboard key e.g. Ctrl

{% include ltr/kb_key.html key='Ctrl' %}

Keyboard Shortcut Block

This block generates keyboard shortcut images. This block can accept three argument:

keys= key combination for the shortcut following KEY+KEY... format e.g. Ctrl+Shift
click= set to true to show + Click after the shortcut for keyboard and mouse combinations
note= a note that appears in front of the shortcut image

{% include ltr/kb_shortcut.html keys='Ctrl' note='Launches Rhino window only' click=true %}

Sample Pages

To create new sample pages, follow the formatting of samples/_template.md page. You can duplicate this page and create your own sample document:

Keep it short and to the point. This page is ONLY about the sample
Include a banner image for the sample. Choose an image size to be consistent with other samples. This banner might be used to show as cover in sample galleries
Make sure the sample files are archived as a ZIP file for easy download and organization. Modify the download_pkg button block to point to your sample archive
Under Files section, provide a list of sample files with description. After that provide instructions on how to open the samples
Under Description section, provide a detailed description of how the sample is structured. Any information about how the generic components work should be included in the Guides and not in sample article. The sample description is intended to help the user understand that specific sample and not the underlying concepts
Sample pages are un-ordered. There is no need to define order: on page metadata
You can set the authors: [ 'your-name'] page metadata and provide your name or handle
Only use H3 headers. The sidebar should only list Files and Description and subsections.

Data Sources

_data/ directory contains data files that are used to generate special content on the wiki. e.g. components.yaml file contains a list of all components in the project. These data files may be automatically generated by other tools.

Rhinoceros Tab Button List

buttons.yaml file contains a list of all UI components in Rhinoceros tab (inside Revit UI) and is generated automatically on every new build. The wiki uses this information to generate a documentation page for all the available UI components.

This is how the data file is formatted:

  # revit panel name
- title: Rhinoceros
  # list of ui components under this panel
  comps:
      # ui component title
    - title: Rhino
      # ui component description
      desc: The Rhino icon will start Rhino to run inside Revit
      # ui component icon image file, or icon tag name (e.g. "G") for automatic icons
      # only specify one of these
      iconsrc: /static/images/ribbon/Rhino.png
      icontag:

Grasshopper Component List

components.json file contains a list of all components in the project and is generated automatically on every new build. The wiki uses this information to generate a documentation page for all the available components, and to safely reference the components on the wiki pages, using the uuid:

This is how the data file is formatted:

  {
    "desc": "Picker for physical material type options", 
    "iconsrc": "/static/images/GH/StructuralAssetClass_ValueList.png", 
    "icontag": null, 
    "panel": "Material", 
    "tab": "Revit", 
    "title": "Physical Material Type", 
    "typename": "StructuralAssetClass_ValueList", 
    "uuid": "6f5d09c7-797f-4ffe-afae-b9c0ddc5905f"
  },

Currently, the Grasshopper definition update_components_data.ghx is used to generate this data file and perform other necessary tasks to update the components list for the wiki.

Misc List

misc.json file contains misc information e.g. hidden parameters, etc. The wiki uses this information to safely reference this data on the wiki pages, using the uuid:

This is how the data file is formatted:

    {
        "desc": "Represents an asset property that can be connected to a texture map as well",
        "iconsrc": "/static/images/GH/AssetPropertyDouble1DMap.png",
        "icontag": null,
        "panel": "Params",
        "tab": "Revit Primitives",
        "title": "AssetPropertyDouble1DMap",
        "typename": "AssetPropertyDouble1DMap",
        "uuid": "49a94c44-26ec-4ee8-b9e7-37581968c3bf"
    },

Currently, this file is generated manually.

Files

readme.md

Latest commit

History

readme.md

File metadata and controls

Rhino.Inside.Revit Docs

Contributing to the Docs

Applying Minor Changes Using the GitHub Editor

Clone, Revise, Submit Pull-Request

Getting git

Cloning the Repository

Installing Ruby

Windows

macOS

Installing Jekyll

Building the Docs using Jekyll

Make Necessary Changes

Spell Check

Publishing the Changes

Online Experience

Understanding Docs Source Files

Page Metadata

Page GH Definition

Page Layouts

Adding a New Language

Adding a New Docs Version

Adding Button-Specific Documentation

Adding Component-Specific Documentation

Adding Release Notes

Docs Formatting Conventions

Frequently User Terms

Linking Other Pages

Linking Images

Grasshopper Screenshots

Linking Videos

Referencing Grasshopper Components

Referencing Grasshopper Parameters

Adding Email Links

Pre-defined Blocks

Work-in-Progress Block

Revit API Link Block

Warning Note Block

GitHub Issue Note Block

Bubble Note Block

API Note Block

Locale Note Block

Filter Note Block

Download Package Block

Download Component Block

Download Definition Block

Release Header Block

Keyboard Key (Inline)

Keyboard Shortcut Block

Sample Pages

Data Sources

Rhinoceros Tab Button List

Grasshopper Component List

Misc List