Added Enum to ViewGroup derive macro

[StefanBossbaly]

First cut of the Enum Macro.

Currently it works on named and unamed enum variants. Each field must implement View + Drawable. I included an example that use a random number generator (tinyrng to stick to the no-std depandancies) to pick what variant should be displayed to prove that any can be selected.

One of the problems I am currently running into is that it does now work with LinearLayout. The problem is that LinearLayout does not implement Clone + Copy which causes the impl Transform to fail since the translate is given a &self and usally calls translate which accepts a mut self. Have to see if there is another way to implement it but it seems like I will need to add Clone + Copy to LinearLayout (which in turn means it has to be added to Views and Chain). Not sure if that is doable on Views since it holds a &'a mut [T] . Any feedback/suggestions is greatly appericated. Thanks.

[bugadani]

Thanks for working on this!

I think we shouldn't introduce a new macro and instead we should include enums in ViewGroup. Not quite the same thing, but I just find it a bit weird to need two separate macros to essentially turn complex types into something workable. Also some of it overlaps when you have an enum variant with multiple views in it.

I'm not sure how I feel about Clone. I would like to avoid that if possible, but I need to read this PR first.

Lastly, you don't need randomness and 5 enum variants in the example. I would suggest to keep it simple and easy to read, as it serves as a guide for users.

[bugadani]

Hmm, it might make sense to support units, I think, in case you don't want to display anything for a particular case. Is there any difficulty here besides generating code that does nothing?

[StefanBossbaly]

Would units just return a dummy view? I know that ViewGroups must have a length of at least 1 or the library will crash. Is there a View struct that currently exists is just a placeholder/dummy? Since we are returning a ref how would we keep that value alive for the lifetime of the enum? I would imagine it would look something like this

impl embedded_layout::view_group::ViewGroup for ... {
    fn len(&self) -> usize {
        match self {
            ...
            Self::UnitEnum => 1,
        }
    }

    fn at(&self, index: usize) -> &dyn embedded_layout::View {
        match self {
            ...
            Self::UnitEnum => {
                match index {
                    1 =>  // What do we return here, a dummy view?
                    _ => panic!(),
                }
            }
        }
    }

    fn at_mut(&mut self, index: usize) -> &mut dyn embedded_layout::View {
        match self {
            ...
            Self::UnitEnum => {
                match index {
                    1 =>  // What do we return here, a dummy view?
                    _ => panic!(),
                }
            }
        }
    }
}

[StefanBossbaly]

@bugadani I didn't address this in the code yet. Was waiting to see what you had to say about how to implement a view that has a no-op draw function.

[bugadani]

or the library will crash

Oh nevermind then, I'll do this later.

[bugadani]

I'm not opposed to implementing Clone for LinearLayout, but it looks like it's not necessary for this PR. We can keep it, but ideally it would be nicer to add it in a different PR.

[bugadani]

I would suggest to pick a panic message that is a bit more informative. Also, this message should be:

• generated as an #[inline(never)] function to avoid including the string multiple times
• it should be the same as the message for Unnamed variants

[StefanBossbaly]

Done

[bugadani]

@StefanBossbaly much better, thanks! This comment and the one about unit enums still stand, though. I can do these changes if you want me to, let me know if you do :)

[StefanBossbaly]

@bugadani This comment should be addressed. Both at() and at_mut() are now #[inline(never)] and return the same message (Invalid index! Index exceeds the value returned by len())

[bugadani]

Hmm I don't think I communicated very well. But never mind, I don't want to force you to a lengthy back-and-forth on this.

[StefanBossbaly]

I think we shouldn't introduce a new macro and instead we should include enums in ViewGroup. Not quite the same thing, but I just find it a bit weird to need two separate macros to essentially turn complex types into something workable. Also some of it overlaps when you have an enum variant with multiple views in it.

Move code into the current ViewGroup macro.

Lastly, you don't need randomness and 5 enum variants in the example. I would suggest to keep it simple and easy to read, as it serves as a guide for users.

Removed RNG. Sorry got a bit carried away 😄

I'm not opposed to implementing Clone for LinearLayout, but it looks like it's not necessary for this PR. We can keep it, but ideally it would be nicer to add it in a different PR.

Moved.