The following error arises when including this package in Cargo.toml:

could not find `log` in `{{root}}`

Copying the log package dependency:

log = "0.4.11"

into my program's Cargo.toml resolves it.

Very likely this line is at fault: https://github.com/Finnerale/druid-enums/blob/master/src/lib.rs#L76

since it referneces the current crate's root rather than the library root.

Currently, if you have more than 1 field in a variant, the generated code won't compile. You would need to generate a lens to enable everything to hook up correctly. The easiest solution is just to return an error if a variant contains more than 1 field (which is easy enough). The harder solution would be to generate the required lens, but I'm not even sure this is desirable, as it hides some complexity.

The lens would transform (&mut A, &mut B) into &mut (A, B). It would do this by taking ownership of A and B by cloning, allowing the inner methods to modify them, and then replacing the contents of the original tuple with the new values. The cloning should be cheap, because all values used as data should be cheap to clone (either stack-allocated simple types, or types behind reference-counting).

Hello, I came across a possible limitation when multiple layers of enums are used.
It may be that I'm doing something wrong as well, so I'd appreciate if you could take a look into this example.

To run it:

git clone https://github.com/swfsql/druid-enums
cd druid-enums
cargo run --example login2

This is based on the login example, but I forced a situation where multiple enum layers were used:

enum AppState {
    Login(LoginState),
    Main(MainState),
}

enum MainState {
    LoggedMainState(LoggedMainState),
    UnloggedMainState(UnloggedMainState),
}

Where for the Unlogged state I refrain from labeling the username (as there would be none).

The problem is that after a login (both with or without an username), I can't click the increment button.
I think it's related to some sort of event propagation problem, but I haven't explored this area from druid..

Please let me know if I'm missing something

Currently crashes in debug mode because druid detects that layout is called before the widget is added. I will investigate a fix.

• complain about missing variants
• default variants
• tuple variants
• generics (requires new Druid release)
• documentation of the derive
• generating documentation for the ...Matcher widget and its builders
• add tests
• ensure consistency with the guarantees Druid offers to widgets
  (e.g. LifeCycle::WidgetAdded as first event)
• bullet proving error messages
• nitpicking about implementation details
• think about making Druid a dependency
• allow shared data like List does
• getting this into Druid

I want to define an enum and matcher in one module and import it into another. Is that possible?

While the previous one was more of a nitpick, this one looks serious so we'd have to collaborate on that :-)

I'm currently using your solution in an embedded linux application for a device and it's been working great, however, I've noticed one thing that happens if you use it to switch views.

Basically, while updating from one enum element to the same one with different built-in data works, updating to a completely different one, and then the first one but with new data, shows the old data instead.

Hey,

I'm trying to create an "overlay" based on an enum as described in this Zulip thread.

I want to create an enum and store it in my app state. When this enum isn't a OverlayState::None variant, use a ViewSwitcher to display an overlay corresponding to this variant. If it is an OverlayState::None variant, just display the normal page.

pub enum Overlay {
    Foo(FooOverlayState),
    Bar(BarOverlayState),
    None,
}

pub struct AppState {
    ...
    overlay: Overlay,
    ...
}

fn ui() -> impl Widget<AppState> {
    let view_switcher = ViewSwitcher::new(
        |data: &AppState, _env| data.overlay.clone(),
        |overlay, _data, _env| match overlay {
            OverlayState::None => Box::new(page_ui()),
            _ => Box::new(overlay_ui().lens(AppState::overlay)),
        },
    );
    ...
}

But we hit a snag. When the overlay is first presented, it allows you to click one and then all subsequent clicks have no effect. Hovers, however, continue to register.

Here is minimal reproduction of the issue