Public repository for custom views for Omniscope 2018+.
The views added here are available to install in the view picker of Omniscope.
Visit our forums for more info and discussion https://help.visokio.com/support/discussions/topics/42000001524
Documentation: https://omniscope.me/_global_/customview/v1/docs/
-
Add a folder with a name matching the unique view id (the view name which must not conflict with other view names).
-
The folder should have the following files (all file names have to be case-sensitive):
-
icon.svg
32x32 px SVG icon following the same style as the existing icons.
-
index.html
Main page loaded by the application to show the view.
-
manifest.json
Configuration file for the view that defines the options and limitations. Manifest options should be declared with necessary restrictions (e.g. you should not be able to pick a text field in calendar view) and with descriptions inside them (for tooltips).
-
README.md
Markdown file that describes the view following the same format as the existing readme files. Each view's readme.md file should explain what it's for (typical use case), what data structure you need for it to work, how to configure it / how the options work.
-
thumbnail.png
290x290 px screenshot.
-
test.ioz
Omniscope file to test the view.
-
-
Add an entry to the file views.json:
{ "name": "<<unique view id in lower case>>", "displayName": "<<view name to display in the view picker>>", "tags": [<<list of tags to identify the view with>>], "files": [<<list of additional file names that the view requires>>], "version": 0 }
-
Make sure manifest.json has the entries for "icon", "tags" and "thumbnail". See other view manifests.
-
Update the gallery of views in the README.md to include a thumbnail of the new view that links to the view readme file.
-
Filtering must work. If you filter, the view needs to update cleanly, and if you then reload the page, the view should look the same. Make sure each render is clean, and there isn't some UI effects hanging over from the previous state. This also implies poor man's brushing works properly.
- Selection
- Tooltips/Labelling
- Sizing, colouring, etc.
- Suitability to any data. It's ok for a view to have specific data structure requirements (as long as you it's described in the readme file, and where possible manifest option tooltips)
- Pixel-perfect (minor visual glitches that don't appear in every scenario are ok)
- Proper brushing (note poor man's brushing is perfectly acceptable)