flip element

[Xeverous]

An idea that come to my mind after having the seeing the same element logic multiple times in my project:

• basically a deck element that stores exactly 2 child elements, any element type
• hidden element does not contribute to any limits/render/event calculation
• has member flip() to easily swap active element

What do you think?

[djowel]

Sounds good to me, but perhaps a better name?

[redtide]

toggle(), switch(), raise(), to_front() or like he said also swap()?

[Xeverous]

IMO swap should be reserved for copy-and-swap idiom, I would go with toggle(), to_front() and to_back().

[djowel]

Let's see...

exchange, switch, interchange, change, swop, alternate, substitute, shift, reverse, transpose, quid-prp-quo (haha!!), replacement, displace...

I think I'd go for "alternate". Thoughts?

[redtide]

Sounds good to me, I liked raise()/to_front() and to_back() but I see that maybe those would be more appropriated for the single child, not for the deck container.

I have a feeling that controls like this, which are somewhat derivatives should stay in some gallery but outside the lib, as some custom control snippets ready to use (or some "elements extension" IDK), or there would be many other alternatives that could lead to some kitchen sink thing, but I maybe be wrong for this case.

[Xeverous]

I think that this use-case (deck of size 2) is quite common and could get a better interface to flip the side and explicitly change to front and back.

Now my thoughts about the names:

• exchange - I would refrain from using this name because std::exchange does something different
• switch - not an option, already a keyword
• interchange, change - too generic, not expressing that there are only 2 sides
• substitute, shift, reverse, transpose - again, better leave such names for <algorithm> stuff

My favourites are toggle, alternate and flip.

[djowel]

I have a feeling that controls like this, which are somewhat derivatives should stay in some gallery but outside the lib, as some custom control snippets ready to use (or some "elements extension" IDK), or there would be many other alternatives that could lead to some kitchen sink thing, but I maybe be wrong for this case.

I do agree in principle that the library should be keep as simple as possible. Yes, the purpose of the gallery is indeed to be a collection of loose derivatives and composed elements. This on the other hand, is quite common. It would even probably be better to not derive from deck. pairs such as these (which is not a bad name too!) are rather common and can be thought of as building blocks, much the same as say 'cons' lists in lisp/scheme.

The layered_button can actually derive from this, so I think I agree with @Xeverous that this is rather fundamental. 'alternate' and 'pair' are reasonable names that depict its structure/composition. I think 'alternate' is the better name because it reinforces the fact that only one is active at any given time.

[djowel]

Closing this now, cleaning up. I added this to #229 , probably a low-priority task, for now. I'll be prioritizing the feature list in #229.