Hi @DavidRutten, i have populated a value list with 700 entries. If i click on the dropdown control arrow, i get a long timeout (hang) but no dropdown appears. Is there a limit on the amount of values ?
If i change it to Value Sequence no problem and all is snappy.
_
c.
I had that same issue with Human.ItemSelector derived from ValueList
@ivelin.peychev, your problem is different, i do not get a list shown at all, only hourglassā¦
EDIT: after waiting a minute without interrupting the focus, actually i get the drop down. But this is very slow.
_
c.
I think the issues are related. As they currently exist, value lists in dropdown mode, (In my experience), seem to bog down around 200+ entries. From a workflow standpoint, I try to avoid that scenario. If possible, can you break up/categorize/filter the values in some way? Category->Family->Typeā¦or something?
Hi @chanley, confirmed, the longer that list, the longer it takes. Iāll see if i can implement a custom combobox instead using a simple text field with AutoComplete etc.
_
c.
For some reason it takes a long time to populate a windows menu. They didnāt write it with that in mind.
On the other handā¦ 700 items, that must be a nightmare to navigate.
Hi @DavidRutten, fortunately i got instant population in a WinForm comboBox using AddRange(items) and it comes with the AutoComplete which helps a lot finding the right value by entering the first letters. Example using fruit names:
Itās for a list of wood coatings. The fun thing using the ValueList component was, when i set it to Value Sequence, it was not possible to quickly click on the left and right arrows, it caused the Enter a search keywordā¦ dialog popup. Kind of an ordeal to reach a value in the middle of the list as you need to click slowerā¦ 
_
c.
That seems like a useful feature to wish for in GH2. 
A ValueList with search bar with auto-completion.
I also noticed a problem with Value List component when there are a lot of values inside. Dropdown is in fact very slow, and any form of navigation is very unpleasant.
Autocomplete search bar would be great!
Also for 700 items, Iād quite like to have a subcategorisation. Like the languages in the Culture parameter menu. If you can split the 700 items up into 10~20 categories, then it should be a lot easier to find the one you want.
I like the look of this one:
I donāt see the point of using the value list for so many values. The selector that has made clement seems to me more suitable for this case. It would be very interesting to have native components to use gh databases.
For many values (less than one hundred) I think it is better to represent them in a table instead of a single column. And with the option of specifying rows and columns (which can be done by adapting it to a resizable capsule). Similar to the ValueList but instead of displaying only the name, have the option to display also an image. As a case of use, I often use the ValueList to parameterize the style in a design element (which is usually to change a profile curve or things like that, using presets or sub-regions of the parametric space that I pre-select), I can represent each style in an icon and this would greatly enhance the experience of clients who just need to adjust parameters of a definition because an image is usually more descriptive than just text.
All of this could be interlaced on a GH support for databases, now that I think about it. Whose unit is an object with unique name or identifier, and native attributes such as image or category or tags and custom attributes (that can be associated with geometry as metadata). This solves many lack of features at once, from generating presets and having a native way to organize them and reuse them easily, through being able to measure and analyze data relationships (well, have the structure to be able to measure them), and ending up being able to organize variations of a design at the production level (you can store the result or just the source parameter values) and not just at the interface level as now with the StateManager. Many features can be unified under the hood. And then use a component like a ValueTable to visualize and choose the data. And another to search on databases using a text search engine, with option to choose a data or a collection. And others to add/change or read data attributes or filter data types.
@DavidRutten I guess youāve already thought about this, Iād like to know your opinion. Iām not interested in this as a way to add information to the geometry, but because commonly the hardest part of machine learning problems is getting a good database, and GH has the potential to be a database generator. It would be very valuable to standardize everything related to saving and retrieving data, but not raw data as can be done now using (Data Input and Data Output components), but data formatted in key-dictionary.
thinkingā¦
Brain dump:
Iām an amateur when it comes to databases, however I do know that unless they get really big or need to support a huge amount of concurrency you can get away with ānormalā data structures like arrays and dictionaries. The core problem with a database seems to be that you have a whole bunch of related data and you need to be able to search the data set using those relationships. This can be brute-forced if thereās just a couple of thousand entries.
The core problem with Grasshopper (de)serialising data is that it does not know at the time of compilation what types it will be confronted with. Obviously it knows about some of them (bools, strings, ints, points, curves, meshes, ā¦) but any plug-in may introduce a new type into this environment. The code responsible for writing and reading this type must be provided by the same plug-in, and if it isnāt (or logically canāt), then that data cannot be stored anywhere. And if it can be written, it canāt be read unless the same plugin (possibly the same version of the same plugin) is loaded.
In GH2 metadata this problem has been circumvented by limiting the number of supported types. Technically since both strings and byte-arrays are allowed, any data can be stored in one of these forms. Metadata is also entirely immutable, which makes it a lot easier to deal with in a multithreaded context.
So a database standard in GH needs to deal with the same problem. It could take the same approach as metadata, or maybe something else?
From a programming point of view, what sort of functionality would you expect to find @Dani_Abalde?
I understand the problem and as a developer itās okay for me to adapt to this for custom cases.
I also prefer to be able to use just text and create any nested structure like in JSON than not having the possibility.
As a fundamental entity (Iāll call this object as āentityā from now on), an interface or abstract class that defines an identifier and a dictionary/sortedlist of key-value pairs with the option of custom sorting. With standardized keys such as name, category/family, icon and some others that are commonly used, but always allowing custom pairs, like this same entity. Edit its content according to the key. With the option of being read only (that identifier cannot be overwritten or the developer of the type can only if he wants to). With methods to be convertible to text in various formats (abbreviated, complete or regular). Also that it can be exported to JSON and other formats.
I donāt think it takes much more, the idea is to share the same base type to store data between different applications (gh ā plugins). I see the arrays or lists as the last link or the leaf node, because they are not intended to be nested to form a tree structure, and for this it is highly necessary. This format allows to go towards abstraction, for example, I can make a collection of profile curves in a list, but if I need a collection of collections (because each type of profile belongs to a different field of use) I need another entity that group all collections. And if I also have other collections of other geometries, I need another more abstract entity to group them. Grouping, or rather, defining these more abstract concepts, we can build knowledge. We need the brick for this type of buildings.
I give you another example. This format also solves how to structure the metrics of the definitions. Each component has one of these associated entities, and its parameters as well, which are child entities, which contain a key with the list of source component/target component pairs and the number of times they have been connected. So, once you have this database of definitions, given a component, you can suggest a whole next process based on the user experience. If processes can be tagged (such as naming a group) and saved, then a sophisticated search engine could be made. For example, if you want to get the most commonly used processes related to the ācurveā tag without using brute force, you need an entity called ācurveā that contains those processes. More semantic modeling.
With respect to the above, there could be other types of objects responsible for launching events in certain circumstances of the software, where we can subscribe and generate new entities of these or update them in existing databases. Iām doing this for Peacock1, I call them statistic collectors, but I look limited in many cases and I think itās a generalist feature that should have GH and not a jewelry plugin, but I want to make it as smart as possible and one of the ways is to measure.
Basically I want to control this type of data in GH as native type, with its corresponding parameter and exportable to/importable from a file. It is not very different from a JSON. And now that I think about it, this is not very different from your GH_IO, right? but the difference is to extend it to an individual entity that is able to generalize the use of the database.
A last example. Imagine that you create a faƧade generator, and suppose there is a controllable pattern of rows (entrance, floors, between floors, roof ā¦) and each row is also divided into several spaces (balconies, between balconies, whatever, no Iām an architect). It should be a quasi-arbitrary mesh/graph and not rows and columns, but itās just an example. Each of these spaces can contain a specific type of constructive element, that is, a label. With this generator, you can easily create a segmentation image that associates a color with a constructive element or label (instead of making a realistic render, it is colored by category), that is, the data necessary for one step of supervised learning of faƧade recognition (real image ā segmentation ā features). Regardless of technical difficulties, GH is perfect for generating databases for this purpose, or expert systems based on data that are a catalyst for learning from real data. Then, for each facade generated, there is an entity that keeps its characteristics of rows, columns, elements, whatever it is, no matter its structure, it is a tree.
Iām not sure I answered your question, but I think I have shown the need for this.
I wish there was a common database between Rhino and Grasshopper.
RhinoGUID and GhGUID along with all the properties that exist only in Rhino would be there. That would make it much easier to get some attribute also it may allow currently impossible/troublesome thing - modifying Rhino objects directly from Grasshopper.
I think you can keep the parent-children relationships even if you transform the datatree into database table structure.
