VL: Groups and Categories

July 5, 2018 posted by: tonfilm

Dear patcher,

as an avid vl user by now you’ve understood that in vl there are different kinds of patches. While colloquially we just call them all patches for simplicity and because they all allow you to patch in them, we can easily distinguish two main types of patches:

  • Datatype Patches: patches defining a process node and/or datatype
  • Structural Patches: patches that only help you structure your programs

While datatype patches more resemble what we had in vvvv, structural patches are new in vl. We just reworked this part a litte and ended up with 3 structural patches which make things much more clear:

  • Group
  • Category
  • FullCategory

But before we go on let’s make sure we are on par regarding the term “Category”:

Obviously. (Yeah, just wanted to make sure)

What we had so far was a not so clear mix of all three. Let’s see what we have in latest alpha:

Group

Group patches simply allow you to create more space in a patch by opening a new canvas. The groups name is merely used for human readability, vl doesn’t care about it at all. Create a group by typing “group” in the nodebrowser. Groups is what you will be mostly using in your daily project-patching work.

Inside a group patch

Group patch from the outside

Category

A Category patch looks quite similar to the group, only its name has a meaning: The name appends itself to the category of its parent patch. That way you can build up any category hierarchy, that you then see in the NodeBrowser. Multiple category levels are allowed with dot notation. e.g. MyCat1.MyCat2.

Inside a category patch

Category patch from the outside

Full Category

A Full Category patch is similar to the Category patch, only that it doesn’t add its category to the parent. By that you can place nodes in any category, regardless of the parent patch. It’s considered bad practice to do that, but is useful to add nodes to an existing category like Collections.Spread, for example. Multiple category levels are allowed with dot notation. e.g. MyParentCat.MySubCat.

Inside a full category patch

Full category patch from the outside

Each vl document can directly start a category, which you can define in the angular brackets in the top left corner of the document patch.

“Voo” specified as a documents category

Changing the Patch Type

You can easily convert a group patch into a category patch and vice versa by the patch type enum. Note how the label changes and represents the actual category structure:

Converting a group into a category

Setting Categories on Node-Definitions

As if the above didn’t offer enough options already there is one more way to specify a category for an operation or a datatype definition:

Setting a Category on an datatype or operation-definition

Happy node sorting!


Comments:

Comments are no longer accepted for this post.

velcrome
05.07.2018 - 18:00
is there a way to express any of the three as a region?
tonfilm
05.07.2018 - 18:29
@velcrome not yet, we thought about category regions but it didn’t make it high enough in the todo list. you can set a category on individual type or operation definitions (see last .gif). that was close enough and can solve all special cases.
velcrome
05.07.2018 - 18:55

Yes, the last gif is nice, but nothing new in vl. Even before you could set the category for individual patches (from inside, that is).

I have been using Groups for structuring before, but never really felt comfortable with them, because it hides stuff (instead of only encapsulating). So eventually I tend to remove them in favour of readablility, once I seriously start to clean up.

One thing I disciplined myself to: never mix different namespaces (what you call category) into one Group, because that’s a recipe for confusion. Seems to me like your solution attempts to maximize the potential for confusion ;-)

I really like the way you can now use absolute and relative category naming, the rest, unfortunately, not so much. Three different ways to save a few keystrokes while setting the category (and still not enforcing them) seems overly complex while not addressing some things that are important (at least to me, like first-glance-understanding).

If I were to make a shared project or even a lib, I would rather use the new regions and individual category settings for each patch, than to resort to these new features. Simply because I care for the patcher that has to read my patch one day.

tonfilm
05.07.2018 - 22:24

@velcrome it sounds like you want the document patch to reveal the whole document structure to you. this is of course only partly true if you only see top level categories in the document patch. but like this it is organized in the way you will find it in the NodeBrowser, which is a plus for library developers.

as a project patcher you will mostly use Group and sometimes a Category, just to get smaller patches. and since you can define multiple category levels with one category patch you can place all categories flat into the document patch, if that is what you like to see. so just a question of style and personal preference.

for a document overview you should use the ProjectExplorer more often (CTRL+J). there you will see how groups and category patches structure your document in a folder like tree structure. you can also use it to navigate via double click and it shows you where nodes are used:

so i think we found a very clean solution for document structuring and sorting nodes into the NodeBrowser. it seems that your critique is mostly about it’s flexibility and that it allows to make messy documents. but i think that’s always possible, no matter how little options you have.

microdee
06.07.2018 - 13:01
what was the problem with the name “Namespace”?
u7angel
06.07.2018 - 21:49
@microdee, i join this question
tonfilm
09.07.2018 - 18:08

@microdee and @u7angel we chose category over namespace mostly because its nicer for humans and we have a history with it.

namespace is a term from textual programming and has nerd factor level 9999. it’s purpose is to have symbols with the same name in one context and be able to distinguish them, not to sort and browse symbols.

category is known by all vvvv users and the term can be easily understood by non-programmers. it’s also more natural to explain that the node browser is ordered in categories (3D, Math, Collections etc.) than in namespaces. and programmers will get it in no time.

u7angel
09.07.2018 - 18:55

@tonfilm, i can understand the intention but don’t you borrow a lot of terminology from .net languages and OOP ? it feels a bit inconsistent to name the starting point differently. in vvvv it was totally ok to work with categories, since they didn’t have a deeper meaning (e.g. namespace scope in OOP)

but since VL tries to be the OOP visual language (and of course more), it confuses more than it helps to choose right here, a different naming. reading articles about OOP and having a similar use of terms, helps you to relate things you learn across languages.

remembering learning vvvv, it took really long to relate concepts to other languages. not just because vvvv is one of a kind but also the naming did not help. e.g. spreads aka arrays aka lists…

tonfilm
11.07.2018 - 14:35
@u7angel yes it’s true that we borrow and actually implement a lot from the OOP and .NET world. here we kept the vvvv name for the reasons mentioned above. if that creates too much problems for beginners and programmers that know other languages we can change that terminology at a later point. as for all new features we observe, learn and then react if it doesn’t work out as expected.

Contact


Imprint

vvvv - Dießl & Gregor GbR
Oranienstrasse 10
10997 Berlin/Germany
VAT: DE275566955

groupӘvvvv.org

Follow us

Mastodon.social
Pixelfed.social
Github
Vimeo
Youtube

Sign up for our Newsletter

Your subscription could not be saved. Please try again.
Your subscription has been successful.