Implementation of revealer

[VimYoung]

hey @drkrssll , I think I might try my hand at trying to implement the reveler widget, though I don't know Gtk much, I was thinking to implement it by polling( continuous loop at every 2 secs), I don't know/haven't written any async code, so I might change the implementation when I get more familiar with async. Just wanted to know about your opinions, what do you thing, any heads up you would like to mention.

Edit: Yup, I didn't look the gtk docs properly, I think it wouldn't require it, let me try before presumming anything further 🤗

[VimYoung]

Minor Update: Working on adding a new widget makes me require the need for a new enum variant(say Nowid) for the following two reasons:-

1. Say the user parses the wrong input into the widgets, which is not valid, there should be a way to make this out. For example, If a user provides a reveal as a child to another reveal, the child match statement in tag_revealer(in progress) could give out Nowid as its child, which could act as a medium for propagating the error up and dealing later rather than panicking the code.
2. This will make addition of more widgets/ variants of Tag easy. we can add a _=> Something (where _ will have the Nowid tag and any other tag whose implementation is not yet complete) in fns like tag_container, tag_position etc. Then, when adding a new variant, we wouldn't have to worry about updating all the functions which are match the tag, so that we can compile and just test if it is working or not, then we can add the arms of match to the functions later.

I am not sure if I have explained well, please pardon for my explanation skills :)

[sashk4]

I believe I see what you're saying.

Something like:

pub enum Tag {
    Label(Label),
    Box(Box),
    Button(Button),
    Revealer(Revealer),
    Undefined,
}

...

match child {
    Tag::Box(box_) => tag.set_child(Some(&box_)),
    Tag::Label(label) => tag.set_child(Some(&label)),
    Tag::Button(button) => tag.set_child(Some(&button)),
    Tag::Revealer(revealer) => tag.set_child(Some(&revealer)),
    _ => return Tag::Undefined,
}

I can definitely see this being useful at scale.

[VimYoung]

Yep, that is a better use case, and then we could handle them, and print the suggestions to std output/error, it will be better for users.

[sashk4]

@bhaumik-tripathi
I got update_revealer to work using smart pointers and storing the state within a struct for easy accessibility.

Here is an implementation of the safe way to update the state.

pub fn show_hello(factory: &GtkApp) {
    let state = Rc::new(Mutex::new(RevealerState { open: false }));

    let button = tag_button("storage");
    let text = tag_label("storage");

    let revealbox = tag_revealer(
        "storage",
        text.clone(),
        2,
        RevealerTransitionType::SlideDown,
    );

    Internal::static_widget(&text, "Hello World");

    let rev_clone = revealbox.clone();
    Internal::static_button(&button, move || {
        Internal::update_revealer(rev_clone.clone(), state.clone())
    });

    Internal::static_widget(&button, "Open hello world");

    let boxx = tag_container("storage", Orientation::Vertical, 2, vec![button, revealbox]);

    let margins = vec![(Edge::Top, 20), (Edge::Right, 160)];
    let anchors = EdgeConfig::TOP_RIGHT.to_vec();

    Chunk::new(
        factory.clone(),
        "Storage",
        boxx,
        margins,
        anchors,
        Layer::Top,
        true,
    )
    .build();
}

Using Rc<Mutex<...>> allows ownership of a mutual exclusion to be shared between multiple locations, and it seems to be important to handle it this way. I can't find any other solution other than the aforementioned, so for now, this will be how to handle state:

let state = Rc::new(Mutex::new(RevealerState { open: false }));

One thing I dont like is:

let rev_clone = revealbox.clone(); // cloned once
Internal::static_button(&button, move || {
    Internal::update_revealer(rev_clone.clone(), state.clone()) // cloned a second time
});

Because I feel as if there may be a bottleneck by having to clone revealbox twice. But once again, it's the only way I could get it to work.

This approach works so I'm done messing with it for now.

[VimYoung]

Thanks for considering both the tag suggestion and fixing the update_revealer. The cloning can be dealt with later on, it is looking great.