FR: Canvas features for a set of canvases, instead of each one.

[thecookiemomma]

Would it be possible to extend your "canvas" features to any canvas that fits criteria, such as tags, or in folders? I am loving the new stuff. Thank you!

[mdelobelle]

It is already possible with the "matching files" settings. try with dv.pages("#yourtag"), it should work

[thecookiemomma]

Oh!! Thank you!!

[mdelobelle]

I think I've misunderstood your request. You'd want the criteria set to apply to every canvas in a folder or matching a tag right?

Another question: how do we set a tag on a canvas?

[thecookiemomma]

Yes, that's what I'm thinking. I don't know yet. Let me look into that and ask around. At least in folders would be nice.

[mdelobelle]

There is a user experience question at stake. In case there's a conflict between two edges in two different canvas we'll have to decide whether we add the link in case one of the edges matches the criteria (OR), or in case both edges match the criteria (AND).

As of now, it can also be the case in a single canvas, I've chosen to include the file's link in the field's values in case one of the edge the conditions (OR).

But if we were to gather all edges from a set of canvas (totally feasible) it could be difficult for the user to know in which canvas is (are) the edge(s) that match the condition so that a given file's link belongs to the field value. As far as one canvas is involved it looks to me that it is still manageable from a user perspective (browsing the canvas to visual check for edges and so on) but if the user has to crawl many canvases, it could become overwhelming really fast.

WDYT?

[thecookiemomma]

Ok, I can see that. It just means recreating a class for each writing project I'm working on. Maybe a means to create a file class based on another file class? Like "Import from x" or something? So that I can just template it. Or, maybe I create a template of it and make an input of the canvas name... That'd be a workaround, but definitely considerations (sorry I got rambly).

[mdelobelle]

Wrapping up the discussion we had:

One way to avoid creating one fileClass per project could be to associate the Canvas field with a File field pointing to the canvas where those connections are to be searched in.

Let's give an example with writing Projects composed of Chapters and Scenes the Scene fileClass would have three fields: Chapter : updates with nodes belonging to Chapter groups in a canvas (this is a Canvas, CanvasGroup or CanvasGroupLink field) Project : udpates with nodes belonging to Project groups in a canvas (this is a Canvas, CanvasGroup or CanvasGroupLink field) CanvasFile : link to the canvas where these connections/belonging are to be searched. (this is a File type Field where you would put the link to the canvas)

Then in the Chapter and Project fields definition, you would set the option CanvasLinkField to CanvasFile This option would be mutually exclusive from (or of higher priority than) the current "Path of the Canvas" option in the field settings.

So you could keep the same fileClass for different projects' scenes:

Scene.md (the fileClass)

project:: {"type": "CanvasGroup", "options":{"CanvasFile": "project canvas", "nodeColor": "1", ...other options}}
chapter:: {"type": "CanvasGroup", "options":{"CanvasFile": "project canvas", "nodeColor": "2", , ...other options}}
project canvas::{"type": "File"}

Scene1.md (a scene from "my sci-fi novel")

---
fileClass: Scene
---

project canvas:: [[my sci-fi novel]]
project:: ... (connections from `my sci-fi novel.canvas`)
chapter:: ... (connections from `my sci-fi novel.canvas`)

SceneB3.md (a scene from "my horror novel")

---
fileClass: Scene
---

project canvas:: [[my horror novel]]
project:: ... (connections from `my horror novel.canvas`)
chapter:: ... (connections from `my horror novel.canvas`)

[ggstrader]

@mdelobelle

There is a user experience question at stake. In case there's a conflict between two edges in two different canvas we'll have to decide whether we add the link in case one of the edges matches the criteria (OR), or in case both edges match the criteria (AND).

With groups it uses both, which I think makes sense:

One way to avoid creating one fileClass per project could be to associate the Canvas field with a File field pointing to the canvas where those connections are to be searched in.

I might misunderstand, but I don't think that solves the issue? Isn't the goal to allow the same Fileclass to apply to multiple canvases? Why not simply allow multiple paths in this setting?

[Lulullia]

One way to avoid creating one fileClass per project could be to associate the Canvas field with a File field pointing to the canvas where those connections are to be searched in.

Hi, I'd like to know if this actually works or if it's just presenting a potential fix? I really like the concept though, and I have a similar use-case (scenes for a story). I tried it but it doesn't seem to work, maybe it's not implemented?

Also, what if it was possible to match all canvases a note is linked in, and filter out those we don't want through a simple filter (like file name). This way we don't need to specify a specific Canvas (I don't think most notes will appear in each and every canvas anyway) but we can still make sure of exactly which canvasses pass the test if need be. That means that we probably still need to create a new fileClass for each type of note, but at least now we have more flexibility, it's not one fileClass per writing project anymore, instead it's one per project type. We just have to make sure our canvasses are following a good naming convention.

And as for the problem of having multiple results in one field and not being able to know from which canvas it came from… Maybe we can have a small link before each result to the parent canvas (or even canvas group)? Something like field :: "[[file1.canvas|🔗]] [value from canvas 1]", "[[file2.canvas|🔗]] [value from canvas 2]" that could be customizable the same way Aliases are.

In any case, thanks so much for this plugin – I had no idea it was this powerful until I checked out the docs for some details. So exciting for a systems nerd like me :p

[mdelobelle]

let’s explore a « canvas link target field » as a new option for canvas* types. If exists, the plugin would look for this field’s value in the note, find the related canvas file and resolve the canvas field according to the criteria

[SpocWeb]

let’s explore a « canvas link target field » as a new option for canvas* types. If exists, the plugin would look for this field’s value in the note, find the related canvas file and resolve the canvas field according to the criteria

Am I understanding correctly?

1. So in a single fileClass Definition you could define a Field named e.g. TargetCanvas of Type Canvas or CanvasLink, right?
2. And in every MarkDown Files matching this fileClass you can choose a different Canvas to retrieve the Relations/Edges from?

Yes that would make this much more useful! I wouldn't use this feature if I had to define a new fileClass for each Canvas. Please notify us when this is possible.

[SpocWeb]

On the other Hand, I also would like to collect all Relations (OR) from a Set of Canvases into the same Field of Entity. I understand that this has its downsides like

1. higher cost to search though multiple canvases (e.g. in a Folder)
2. User has to search through all Canvases to find the Link when she wants to remove it.

Anything else?

[takajasu]

As an extension to this feature request it would be nice to at least specify a unique name instead of a full path for canvas relations of types Canvas, CanvasGroup and CanvasGroupLink.

If working with shared fileClass definitions, it's cumbersome to handle identicle file locations.

But the suggestion of mapping the canvas to an instance property field is nice, too. Maybe with a unique name instead of a full path, also.