You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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:
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)
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.
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).
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.
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?
Activity
Xeverous commentedon May 30, 2020
popup? If not, you can always make your own by inheriting from the desired element and overridingdraw. If you want the disable element to also not occupy space, overridelimitsaswell.djowel commentedon May 30, 2020
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 commentedon May 30, 2020
Maybe something like this usage:
djowel commentedon May 30, 2020
Perhaps we also want a
collapsibleproxy for that.redtide commentedon May 30, 2020
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 commentedon May 30, 2020
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 commentedon May 30, 2020
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 commentedon May 30, 2020
I got bored... I added
hidable:https://github.com/cycfi/elements/blob/develop/lib/include/elements/element/misc.hpp#L216-L246
and
hcollapsibleandvcollapsible: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 commentedon Jun 10, 2020
Will these block eg a button? That is, if I hide or collapse a button will it still be able to receive events?
djowel commentedon Jun 10, 2020
yes they will. if you want it not to, that should probably be the
enableproxy, 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 commentedon Jun 10, 2020
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 commentedon Jun 11, 2020
Simply: you can have it either way. Swapping empty box is of course another way.
Xeverous commentedon Jun 11, 2020
Actually the
deckis 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::selectis what I actually need.jpcima commentedon Jun 14, 2020
Thanks I would like to use
vcollapsible, but the component draws even when collapsed.Should not
drawbe overriden also ?Xeverous commentedon Jun 14, 2020
What is the difference between hidden and collapsed elements?
Am I right?
jpcima commentedon Jun 14, 2020
@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 commentedon Jun 14, 2020
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 commentedon Jun 14, 2020
Based on the example
SpriteSlidersAndKnobssfztools@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 0part to disable the use collapsible, it expands itself in a different layout which is more compressed and not overlapped.djowel commentedon Jun 14, 2020
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 commentedon Jun 14, 2020
Sure it can wait no problem. There's no fire to the lake :)