I think this is something Grasshopper really needs, it would be very useful for organizing Gh stuff.
Nested tags allows to organize things in several different ways at the same time.
Like in this app:
And ability to also reorganize default components (and from plugins) in your own way would also really nice
So are these tags assigned by the developer or the user? And are they assigned to components or to data?
The idea here is about organizing components menu (which is currently the ribbon ui on top).
Both. Tags can be created and assigned to components by both developers and user.
So Gh itself and plugins will have their components pre-organized by tags, but user could freely rename\add\remove\move(to different parent tag) tags and assign\deassign them from components if he wants. Same for user objects
Oh I see, it’s a UI organising thing, not a document organising thing.
I’ve added a panel scripting feature to the Grasshopper 2 ribbon (“scripting” is possibly overselling it a bit, it’s just some text commands). The default layout is harvested from the component properties (tab, panel, section, hidden or not, etc.), but can then be post-processed by running a set of commands.
For example:
Move Vector.Field.* To Maths.Field.*
Hide Maths.Time.*
Move *.*.*Colour* To Display.Colour.*
This can be used to merge panels or tabs, split panels into multiple ones, hide elements, or even hide everything and then show specific components, which is what the current Layout UI does/did:
Hide *
Show Params.Geometry.Point
Show Params.Geometry.Vector
Show Params.Geometry.Line
Show Params.Geometry.Circle
Show Params.Primitive.Boolean
Show Params.Primitive.Integer
Show Params.Primitive.Number
Show Params.Primitive.Text
Show Params.Input.Number Slider
Show Params.Input.Panel
Then you can store any number of these layout scripts and switch between them at will.
What you see in the video, which I also proposed something very similar long time ago, is a graph search engine. The problem is that there are thousands of components with the capacity to be many more thousands, a literal word search engine like the current one is not good enough (and less with data so semantically related) because it forces you to know all the exact names to find them , instead of resorting to the intention (that the user does know for sure). The search should not be literal, but a semantic query, where each tag is linked to other tags, so that you can find a component (or a snippet) using a controlled natural language instead of technical names, and instead of ranking the results by word similarity it is ranked by proximity in a semantic graph. For example, typing “filter”, the only current valid result is “Stream Filter”, but this should also suggest “Cull Pattern” or all those that have a Boolean pattern as input because they work as filters, not “Fillet” as it currently returns. Not only that, but by typing “filter > Z”, it returns a snippet (parameter point, deconstruct point, greater than, and Cull patern) as the first result because this snippet was saved (native or per user) and tagged with the pre-existing (or not) “filter” tag, but also should return other types of existing filters or components associated with the filters, it doesn’t matter if they are not called Filter something. Or if not, as the video shows, the filter tag allows you to select other associated tags until you reach a component or snippet. Another example is that typing “Create”, it should offer you all the components of primitive geometries ordered by frequency of use, and if you put an incomplete sentence like “Create P” it would return the most common components to create points and planes, but just those related with the Create tag. It’s like doing a query within a query within a query… which is based on relationships, not on literals.
I know that Aliases exist to tag components, but it has the same problems, there is no relationship or way to reuse existing alias and this graph based tag database is (it should be) too dense for each user to do it from scratch, it must be native.
What there should be is an additional file representing a tag graph (with name, id, type, family, synonyms, relations, frequency, etc) and the search engine could be something more than a text box (as shown in the video for example). But you could also use everything you have developed to create graphics to do your magic.
If you do this, you will open the door to NLP (natural language processing) with GH definitions as well, to have a semantic search engine where you can convert sentences in GH definitions. Although to implement the idea above you do not need ML, only to support a graph database (and the closest to a knowledge database, the better). I started working on this months ago, also for Rhino, but I couldn’t dedicate enough time to it, nor could I offer it as I would like if it is not native, because at the end of the day it is creating a taxonomy and an ontology that needs to be standardized, or at least have a shared basis and measure user action to improve it to the next level.
But in short, what that video shows is a graph-based search engine and is a must have in GH and also in Rhino IMO.
In meantime we can store tagged .gh files (with single node in each) in Tags4info, and drag-drop to Gh to place them on canvas