I'm currently toying around with Max 6, and so far, the dict-objects seem promising. But the dict.view object is not what it could be:

It doesn't have outputs, so it's really for displaying only. Why can't it be clickable and report the value that is clicked on out an outlet? That way, it can be used as a collapsible tree view.

Even better, why not implement editing and selection functionality so that you can make multiple selections with shift and cmd/ctrl, and edit the contents in-line as you would change the name of a file in Windows Explorer or OS X Finder, or jit.cellblock for that matter.

Maybe even add the ability to put checkboxes before each item, so you can toggle like you can in umenu.

Max6 looks very promising, I understand that it can't be everyone's dream but I wanted to give my feedback anyway, to help make it even better.

limited-use-of-dict-view

Online editing of dict values would be very nice.

At the time of this post, it is pretty ugly when one wants to edit a nested value in a multi-level dict, while it could be so simple with dict.view !

[jit.cellblock] has some of these functions. It can be linked to [coll] just like dictionaries, and allows various Excel type selection, styling, and navigation options.

It doesn't need a bang to update its contents, a big plus when compared to [dict]

One needs to dig into the [jit.cellblock] settings and reference to make it work well, but it's useful for some purposes.

[jit.cellblock] has some of these functions. It can be linked to [coll] just like dictionaries, and allows various Excel type selection, styling, and navigation options.
It doesn't need a bang to update its contents, a big plus when compared to [dict]
One needs to dig into the [jit.cellblock] settings and reference to make it work well, but it's useful for some purposes.


+1 - I'd also like to see a more interactive dict.view that lets you edit/select from the dictionary.

+1 ! come on cycling!
a better dict.view would be a great tool


+1 - I would also really appreciate this. I can imagine this being an ideal view for selecting addresses from a hierarchical OSC namespace, for example (along the lines of j.namespacebrowser, for anyone who's familiar with Jamoma).

where Charles Matthews was looking at doing something like this by getting 

, so when the node object becomes available in Max 8, this seems like it could be a direction to go, but it would also be nice if dict.view could have a few outlets added to get data out when you click on a key name (e.g., full path to key, key name, value). Cycling folks, if you're reading this, what's the likelihood of this kind of functionality being added, either via dict.view or some other object?

There's a thread from 2012 where Charles Matthews was looking at doing something like this by getting  jstree to run inside jweb. jstree is in npm, so when the node object becomes available in Max 8, this seems like it could be a direction to go, but it would also be nice if dict.view could have a few outlets added to get data out when you click on a key name (e.g., full path to key, key name, value). Cycling folks, if you're reading this, what's the likelihood of this kind of functionality being added, either via dict.view or some other object?

Here's a stab at using bach.tree as a UI to retrieve addresses from an OSC namespace (note: requires the bach package, available through the Max package manager):

Still would be great to get this functionality in dict.view, though!

limited use of dict.view?