3. Artboard roles ( accumulated )

Artboard roles ( accumulated )

  • N

    Notice: Accumulated into mega-topic.

    Rationale:

    Creating a canvas with one artboard for separate style references works fine. However, if artboards could have roles aswell, this would make the additional canvases redundant.

    So, this would, for example, turn this:

    Stroke canvas -> Stroke artboard
    Color canvas -> Color artboard

    ..into this:

    Reference canvas -> Stroke artboard, Color artboard

    .., which would, among other things, lead to less clutter in the Canvas panel.

    0 1 Reply
  • administrators

    @Nils said in Artboard roles:

    However, if artboards could have roles as well, this would make the additional canvases redundant.

    This would be a bit difficult. Artboards are practically just "guides" for exporting and printing. A single canvas has its own layer hierarchy, and that is overlaid over all artboards of that canvas, so objects may overlap multiple artboards.

    0 1 Reply
  • administrators

    @vectoradmin On the other hand, if a (reference) canvas has no role, but the objects have role, than it is easy to organize multiple roles on the same canvas.

    0
    N
     1 Reply
  • N

    @vectoradmin You're right, but then you'd again need to set roles on every object.

    However, if the artboard implementation would involve a lot of work, this isn't worth it.
    I might have just got married to the idea of reference canvases.

    1 1 Reply
  • administrators

    @Nils The main issue with the artboard as a reference is that artboards are just "regions" they don't have content inside (content is placed over them).
    So I would then need to check the object shape if intersects the artboard.
    But the object shape is unavailable when styles are collected (for some internal reason).

    0
    N
     1 Reply
  • N

    @vectoradmin Hmm.. If I knew the exact backend implementation for canvas roles, artboards and styles, then maybe I could suggest a way to do this. But my intuition already tells me this would be a lot of work, so probably not worth it.

    Especially since "workovers" like this usually create regressions..

    0 1 Reply
  • administrators

    @Nils Nothing special, briefly it goes like this:

    • a document is a node hierarchy (tree) staring at top with canvases (two levels in the tree).
    • each canvas has a canvas content (and optionally other canvases) as a child node.
    • canvas content contains object nodes: these are typically Layers at first level.
    • objects continue the tree downwards with other nodes like fill, stroke, group, etc.

    The main difference from a regular document tree is that the above is not an actual tree, but a directed acyclic graph, as multiple branches may end up at the same node (due to reference objects or symbols).

    Also: the above form is the "abstract" form of the document, it contains a lot of things that need to be resolved, so it can be displayed (for example it is not known what the exact shape of an object will be at this level).
    So there is a parallel "realized" tree (this one is just a tree) of nodes that can be rendered.

    And artboards are not part of this tree. Internally artboards go under the "guide" types, similar to gird, or guideline.

    For the roles point of view: one thing that could be done is to let Layers have a separate "role" property that is used to list objects inside that layer with that role. (the main role property of a Layer is used in the same way as the object role).

    1
    N
     1 Reply
  • N

    @vectoradmin

    as multiple branches may end up at the same node (due to reference objects or symbols)

    So, for example, in the acyclic graph, a fill could be the leaf of an object node, right? And if this object then has another "fill style" leaf, that fill leaf gets redirected towards every other object that uses the fill style.

    Something along these lines correct ( fill style implementation could be different I guess? )?

    So there is a parallel "realized" tree (this one is just a tree) of nodes that can be rendered.

    I see, this reminds me a lot Flutter's tree structure with configuration and render trees. Did you draw some inspiration there? If yes, nice work!

    I guess the layer thing would be an approximation of what I want. Artboards would be nicer, though.

    Couldn't you just insert a locked rectangle in the tree upon artboard creation, which you'd then prevent from showing up in the layers panel?

    EDIT: I just thought maybe that layer role idea is actually not bad. Is it possible to hide such a layer from the UI and use it just for the listing purpose in the backend?

    0 1 Reply
  • administrators

    @Nils said in Artboard roles:

    So, for example, in the acyclic graph, a fill could be the leaf of an object node, right? And if this object then has another "fill style" leaf, that fill leaf gets redirected towards every other object that uses the fill style.

    Something along these lines correct ( fill style implementation could be different I guess? )?

    Yes, fill / stroke nodes can be shared in multiple branches. But the real value comes when sharing whole groups of objects.

    I see, this reminds me a lot Flutter's tree structure with configuration and render trees. Did you draw some inspiration there? If yes, nice work!

    Not inspired by, but I'm sure others have done something like this. It is quite common when an "abstract" model is slow to process, to have a parallel "realized / compiled" model.
    The basis for the VS document model was coded in 2013 (i just checked Flutter is started in 2015).

    Couldn't you just insert a locked rectangle in the tree upon artboard creation, which you'd then prevent from showing up in the layers panel?

    Would not really help and would create a lot of problems with Layers.

    0