Show / Hide / Enable / Disable widgets

[redtide]

I haven't found any function that can make some element to be visible or not, neither to enable or disable, is there some way currently?

[Xeverous]

popup? If not, you can always make your own by inheriting from the desired element and overriding draw. If you want the disable element to also not occupy space, override limits aswell.

[djowel]

I haven't found any function that can make some element to be visible or not, neither to enable or disable, is there some way currently?

Good point. It's very easy to add a proxy class that allows it to inhibit the drawing of its subject. That is the way to do it. And yes, it should be part of the library. The visibility state should probably be a callback function like the one in basic_menu_item_element:

https://github.com/cycfi/elements/blob/master/lib/include/elements/element/menu.hpp#L113

[djowel]

Maybe something like this usage:

auto e = share(hidable(some_element));
e-> is_visible = []{ return show_my_element_function(); /*return show-or-hide-state*/ }

[djowel]

If you want the disable element to also not occupy space, override limits aswell.

Perhaps we also want a collapsible proxy for that.

[redtide]

Thank you for the quick replies and suggestions! I'll try them soon. Do I keep this issue open for a future implementation in the library?

[Xeverous]

Do I keep this issue open for a future implementation in the library?

I would keep it. So far all of the issues were only closed when the topic was fully exhausted (by a PR or detailed "wontfix" explanation).

[djowel]

Thank you for the quick replies and suggestions! I'll try them soon. Do I keep this issue open for a future implementation in the library?

Yes, please keep it open. These are very easy to add. I'll see if I can add them as soon as I can.

[djowel]

I got bored... I added hidable:

https://github.com/cycfi/elements/blob/develop/lib/include/elements/element/misc.hpp#L216-L246

and hcollapsible and vcollapsible:

https://github.com/cycfi/elements/blob/develop/lib/include/elements/element/size.hpp#L655-L725

More on ... "enable"-ability later... It's a bit more involved.

[Xeverous]

Will these block eg a button? That is, if I hide or collapse a button will it still be able to receive events?

[djowel]

Will these block eg a button? That is, if I hide or collapse a button will it still be able to receive events?

yes they will. if you want it not to, that should probably be the enable proxy, which is doable now that we have event based receivers and senders. (btw, layer based buttons are completely removed in the use-basic_button branch)

[Xeverous]

Will these block eg a button? That is, if I hide or collapse a button will it still be able to receive events?

yes they will.

My two questions have opposite meaning so I find your answer to be ambiguous.

Nonetheless, I think I can currently easily workaround my use case by swapping empty box or another element in the same place.

[djowel]

My two questions have opposite meaning so I find your answer to be ambiguous.

Simply: you can have it either way. Swapping empty box is of course another way.

[Xeverous]

Swapping empty box is of course another way.

Actually the deck is what I want. I want the swapped element to occupy the same space and replace it with something different depending on some runtime condition. deck::select is what I actually need.

[jpcima]

Thanks I would like to use vcollapsible, but the component draws even when collapsed.
Should not draw be overriden also ?

[Xeverous]

What is the difference between hidden and collapsed elements?

• hidden - occupies space but is not beign drawn?
• collapsed - does not occupy any space, as if it did not exist?

Am I right?

[jpcima]

@Xeverous This is how I understand it also.

As illustration of the problem, there is a collapsed button.
You can see the slider thumb will overlap it.

[djowel]

Thanks I would like to use vcollapsible, but the component draws even when collapsed.
Should not draw be overriden also ?

I would imagine that the element will not draw if it has zero space, so there must be a bug somewhere. Admittedly, the collapsible thingies haven't been tested yet. Can you make an MCVE that I can use to try this? I am guessing that the minimum limits of the element being collapsed (a button?) is being violated, so it's not as simple as I originally thought (perhaps the collapsible's subject should be swapped out with an empty element when collapsed).

[jpcima]

Based on the example SpriteSlidersAndKnobs
sfztools@13bd7d0

The issue is present here although not as pronounced, and I don't find how to make it so as much as illustrated above.

It has a small observable amount of overlap between button and thumb.
Enabling the #if 0 part to disable the use collapsible, it expands itself in a different layout which is more compressed and not overlapped.

[djowel]

I get it. Yes, my intuition was correct. The initial implementation was naive and incorrect. I should swap out the subject with an empty element when collapsed. A deck would probably be sufficient. It shouldn't be difficult, but I am swamped right now. Can you wait a little bit for a few days?

[jpcima]

Sure it can wait no problem. There's no fire to the lake :)