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

Provide useful API to access Node bounds #252

Closed
ystrot opened this issue Dec 12, 2017 · 3 comments
Closed

Provide useful API to access Node bounds #252

ystrot opened this issue Dec 12, 2017 · 3 comments
Assignees
Milestone

Comments

@ystrot
Copy link
Member

ystrot commented Dec 12, 2017

There were several issues related to Node bounds calculation and I think it makes sense to keep all discussions in one place. This is actually a complicated task, because bounds calculation requires rendering context and in fact it's only accessible after drawing. However users don't want to think about such implementation details, instead they want to be able to access Node bounds immediately after creation and access actual information even after some updates.

This task might be implemented during several milestones, so we need to provide useful workaround for current issues. So here is a plan:

  1. We'll provide temporary public utility method to calculate Node bounds. This method will create synthetic rendering context and calculate bounds using this context once. This step is workaround to solve current issues.
  2. We'll provide Node.bounds() -> Rect method. This method will work immediately and access actual information. In the first version we'll just use utility method from step 1.
  3. Implementation from step 2 will be very slow and we actually don't need to recalculate bounds on each call, because we can just use cache to remember bounds. Moreover, during rendering we calculate bounds anyway, so if we render Node we don't need to use synthetic context. So on this step we'll provide complicated implementation to make a fast and useful solution to calculate bounds.
  4. Finally, good implementation will allow us to add ability to monitor Node.bounds changes and it will make possible complicated layouts for nodes.
@JoachimM7
Copy link
Contributor

Thanks for your answer in #240 and thanks for thinking about my suggestions. But I don't really understand the second part of your answer: In Swift you can have read only properties (https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/Properties.html#//apple_ref/doc/uid/TP40014097-CH14-ID261). So calling Node.bounds is much more correct (for me), because the "bounds" is just a property of the Node and not a function. If you follow the development of the Cocoa-API, you also can notice, that with Swift a lot of things were changed from methods to properties (if I remember right, isHidden() was a method and is now a read-only property). For me a function is usually doing some stuff (for example "hide" or "activate" and properties are returning values (like "isHidden" or "isActivated"). With computed properties and read-only properties this is much better to divide.

@ystrot
Copy link
Member Author

ystrot commented Dec 13, 2017

Ok, I see. We'll take a look which one is better in out case.

@ystrot
Copy link
Member Author

ystrot commented Jun 28, 2018

Node.bounds property implemented.

@ystrot ystrot closed this as completed Jun 28, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants