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

[POLL] Should single-child containers (uiWindow, uiGroup, uiTab pages) allow NULL children? #48

Closed
andlabs opened this issue May 23, 2016 · 9 comments
Labels

Comments

@andlabs
Copy link
Owner

andlabs commented May 23, 2016

Containers that allow only one child — uiWindow, uiGroup, and the individual pages of a uiTab — have this weird intermediary state when you first create them: the state of having no child; the value of the child uiControl pointer is NULL. This creates a bunch of weird edge cases for determining what the preferred size of these containers should be and certain grandparent-parent-child relationships.

There are three things I can do to resolve this:

  1. Allow NULL children explicitly where passing NULL to a SetChild() will simply produce an empty container.
  2. Allow NULL initially, but not afterward where creating a container has a NULL child but that's the only time NULL is allowed
  3. Disallow NULL entirely meaning that every constructor function would need you to pass a child in, even a temporary one like an empty box (I could provide a spacer control too)

What do you all think? I'm genuinely not sure which I should do; all the options require relatively the same amount of code effort on my part.

@zevv
Copy link

zevv commented May 23, 2016

I opt for option 1.

Containers which take N children (Box, Tabs) also allow to be in an empty state, so why not also allow this for containers with a single state? This is also a bit more friendly and flexible from the API users' perspective, as it allows for more flexible construction and tear down of a control hierarchy.

@zevv
Copy link

zevv commented May 23, 2016

Also, referring to my other issue with manually tearing down a control tree: not allowing NULL children would make it impossible to remove an object from a tree from the leaves down.

@marcomorain
Copy link

Another option would be to disallow NULL and instead have a new control
type uiEmptyControl that has no size and is not rendered. single child
containers could have this set as the child when they are constructed.

On Mon, 23 May 2016, at 08:43, Ico Doornekamp wrote:

Also, referring to my other issue with manually tearing down a control
tree: not allowing NULL children would make it impossible to remove an
object from a tree from the leaves down.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub[1]

Links:

  1. [POLL] Should single-child containers (uiWindow, uiGroup, uiTab pages) allow NULL children? #48 (comment)

@gnarz
Copy link

gnarz commented May 23, 2016

I'd vote for option 1, as this creates symmetry with multi child controls.

@dfyx
Copy link

dfyx commented May 23, 2016

Option 1 feels the most intuitive.

@andlabs
Copy link
Owner Author

andlabs commented May 23, 2016

Multi-child controls don't allow you to add NULL, as that would make little sense (the only use would be uiBoxAppend(NULL, stretchy = true) for stretchy blank space; and later leaving a grid cell blank, but not specifying that cell is the same). If they're empty, they're empty.

uiEmptyControl could probably just be an empty box internal to these containers. The original package ui had ui.Space(), a function that returned such a thing for the purpose of stretchy blank space.

@SevenBits
Copy link

Option 1 is the best IMO.

@andlabs
Copy link
Owner Author

andlabs commented May 28, 2016

Current idea:

Allow NULL everywhere, including uiBox and uiGrid; implicitly turn it into a dummy empty-space control. Ownership has to be maintained by the parent, but that shouldn't be too hard.

How does this sound?

@andlabs
Copy link
Owner Author

andlabs commented Mar 31, 2018

Merged with #328.

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

No branches or pull requests

6 participants