Akira: How Artboards should behave

[Alecaddd]

What's an Artboard

An Artboard is a a virtual representation of the screen containing the design elements. Artboards are commonly used to represent multiple pages of a website, an ad banner, a business card, or any other medium related tot he same design style, all at once on the same canvas.

Artboards remove the necessity of defining a document size like in traditional graphic tools.

Expected Behavior

An Artboard can be created like a regular rectangle shape, and the only editable attributes are:

• [x] Name
• [x] Size (WxH)
• [x] Background color (use the same fill panel)
• [x] Visibility
• [x] Lock status

Layers Panel

• [x] Hover effect on the layer panel.
• [x] Nested items are created inside the dedicated artboard.

Advanced Artboard features

• [x] Artboards can be selected on the canvas by clicking on their empty edges or on their names.
• [x] Artboards can't be rotated. (hide rotation nob and rotation slider).
• [x] If an Artboard is selected, it shouldn't be possible to hover or select any nested object (gif example below), and clicking & dragging should move the artboard and don't select nested objects.

Nesting and grouping

• [x] Elements generated inside an Artboard are attached to it with a parent-child relationtship.
• [x] Many elements can belong to only 1 Artboard at a time.
• [x] Artboards cannot be nested/grouped.
• [x] When moving an Artboard that has elements inside, all the elements move accordingly as they were part of a grouped object.
• [x] An object that belongs to an artboard will be masked if is positioned outside the edge of its parent artboard.

Example from Sketch

[amxmln]

What I love about Figma is that they got rid of the concept of artboards and use "frames" instead, which can be nested in each other. I think their handling of this is pretty much perfect.

What you're suggesting seems like a pretty standard way of handling them, basically a named group with a background color. That approach certainly works, but I'm not sure it's the most flexible one.

[sr229]

+1 for @amxmln, I think Figma frames would be more useful in some scenarios than standard artboards.

[Alecaddd]

@albfan here's the recap of how Artboard should behave.

[Alecaddd]

@amxmln @sr229, thanks for the suggestion.
We will definitely look into the possibility of creating nested artboards, or even completely implementing the "frames" approach of Figma.

For version 1, we're keeping things simple and standard artboards are what we need.

[albfan]

Related with #151

[Alecaddd]

@giacomoalbe I updated the initial comment of this thread with all the things an Artboard should do and not do.
Let me know if something is not clear or we need further discussion.

[abienz]

I noticed that currently Artboards have some transform handles and can be rotated.

Is rotation intended functionality? It seems redundant to me, and perhaps could be disabled so it doesn't distract the user and complicate the UI.

[Alecaddd]

@abienz indeed, rotation shouldn't be allowed for artboards.
Giacomo has already this task in his upcoming batch of fixes.
Thanks for the heads up and confirming that it is weird :smile:

[Alecaddd]

A couple of issues with the current Artboard implementation.

Selecting rotated items
Since we're overriding the default get_items_at and simple_is_item_at methods, we lost the ability to properly select items based on their filled paths.
Instead, we're selecting items based on their X, Y, WIDTH, and HEIGHT coordinates, which is incorrect since those coordinates don't account for rotation or empty spaces (eg. you can select a circle by clicking on the empty space of its bounding box).

Items rendering
Since we're overriding the simple_paint method, we have to constantly loop through all the child items and re-render them at every mouse movement. That's not great.
Also, because of that, we're losing all the nice optimization done by the goocanvas library, which takes care of properly rendering those items for us.

Considering another approach?
Maybe we should consider another approach for artboards that doesn't affect the default methods and allows us to inherit the built-in selection and rendering capabilities.

[Alecaddd]

Spitballing some ideas without too much thinking, just to write them down.

CanvasWidget
Maybe we could use a CanvasWidget with a standalone Canvas in it? With that we would have a completely separated canvas inside artboards, inheriting all the selection and rendering features, and getting the masking of items out of the box.
I'm sure this would cause many problems when dragging items in an out artboards, or when implementing multiselect.

CanvasGroup
We could try to extend the CanvasGroup class and build on top of that.
It seems tho as simply adding an item to another item as child, destroys the rendering and selection capabilities, so I'm not sure about this approach, but it might be worth exploring.

Fake "Artboard"
We could explore the possibility of keeping the items attached to the main canvas, and only simulate a parent>child relationship with an artboard, making those item actually part of the main canvas, therefore removing any sizing, rendering, and selecting issue.
This might be super tricky for the z-index and will also not solve the masking issue.

[Alecaddd]

Selecting rotated items
Since we're overriding the default get_items_at and simple_is_item_at methods, we lost the ability to properly select items based on their filled paths.
Instead, we're selecting items based on their X, Y, WIDTH, and HEIGHT coordinates, which is incorrect since those coordinates don't account for rotation or empty spaces (eg. you can select a circle by clicking on the empty space of its bounding box).

There's a possible solution to this problem, which is porting this method to Vala: https://gitlab.gnome.org/GNOME/goocanvas/-/blob/master/src/goocanvasitemsimple.c#L1092

This method doesn't check coordinates but rather uses the check_in_path method which accurately returns if the pointer is above the filled area of the item, which is what we want.