Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create a Public Metrics Method #3746

Closed
alschmiedt opened this issue Mar 12, 2020 · 3 comments
Closed

Create a Public Metrics Method #3746

alschmiedt opened this issue Mar 12, 2020 · 3 comments
Assignees
Labels
component: developer apis issue: feature request Describes a new feature and why it should be added

Comments

@alschmiedt
Copy link
Contributor

Is your feature request related to a problem? Please describe.
Currently the only way to get metrics is by using the same method we use internally for processes that need to know just about everything about the workspace. Therefore, the method returns a lot of information that is not well organized or very well documented.

Describe the solution you'd like
A metrics method that is meant to be public and provides a subset of the current values returned from getMetrics with easier to understand and better documented values.

Describe alternatives you've considered

Additional context
Possible Use Cases:

  • Where to position something relative to the toolbars.
  • For scrolling to blocks
@alschmiedt
Copy link
Contributor Author

So far it seems like the following methods would be most useful:

getAbsoluteMetrics (or different name)

Gets the metrics for the workspace without the toolbox.
This would be used for anything that needs to be positioned on top of the workspace.
Examples: WorkspaceSearch, Trashcan, ZoomControl, Flyouts, Modals*
returns {
absoluteLeft
absoluteTop
absoluteWidth
absoluteHeight
}
*Modals would have to be used with workspace.getParentSvg().getClientBoundingRect() since the modal is outside of the blockly div(because it uses the widgetDiv)

getContentMetrics (probably different name. I don't like this name.)

This would hold what is currently the content and view metrics from our current getMetrics method.
This would be used for anything that needs to be positioned on the workspace or need information on how the workspace is scrolled.
Examples: Bubble, Scrolling on workspace

getToolboxMetrics

Contain the metrics for both the flyout and toolbox
Not currently used internally anywhere except flyout_vertical and flyout_horizontal. And I think that might be able to be factored out.

@alschmiedt
Copy link
Contributor Author

Related concerns:

  • Having some way to display debug rectangles similar to rendering_debug would be nice.
  • I think making these methods public would fix the problem where users who want to create their own getMetrics method but don't want to have to copy and paste all of the private getTopLevelWorkspaceMetrics_.

@maribethb
Copy link
Contributor

Another use case would be preventing blocks from going behind an always-open flyout (more specifically, a flyout on a toolbox where the flyout has autoClose = true. This already works when the workspace contains just a flyout and no toolbox). Currently to achieve this, most of getTopLevelWorkspaceMetrics is fine, but we need to change some properties to take into account the width of both toolbox + flyout. So having this method public would allow me to call it from a custom getMetrics method without having to copy/paste a bunch of code I don't need to change.

The approach of having multiple smaller public methods also seems like it could work, I could call those methods for the values I don't need to change, and put their values into my custom getMetrics method.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component: developer apis issue: feature request Describes a new feature and why it should be added
Projects
None yet
Development

No branches or pull requests

3 participants