Blueprint for TreeView?

[michalfita]

While we're on blueprints, is it even possible to implement a blueprint for TreeView<T> (generic) from cursive_tree_view crate? How the content type other than String would be set?

[gyscos]

Unfortunately no, blueprints cannot really be generic. You can locally (in your compiled code) define a new blueprint for a specific concrete type of tree view, then use that from the builder config. But because the builder runs at runtime, we can't monomorphize to the correct type at this point. The best you could do is a blueprint that checks the config, and return one of a fixed concrete types.

[michalfita]

😱 Wouldn't find_name() work at all? In case of non-declarative UI implementation as well?

[gyscos]

In general, we have NamedView<T>, and when the user calls find_name::<T> we look for this NamedView<T> and returns an ArcMutexGuard so the user can have access to that T.

When using the builder module, we have a NamedView<BoxedView>, where the BoxedView is just a Box<dyn View>, and that trait object holds our T. When calling call_on_name, this is fine - there's a bit of code that looks both for NamedView<T> and NamedView<BoxedView>, and downcasts as needed so it can run the given closure on &mut T.

But find_name needs more than a &mut T to run a closure on. It needs to return this ArcMutexGuard, which has a 'static lifetime (it does not borrow &mut Cursive). If we have a NamedView<BoxedView> (which is really just a Arc<parking_lot::Mutex<BoxedView>>), then we need to get the ArcMutexGuard<BoxedView> (it will keep a copy of the Arc to make it 'static). We then need to get it into a ArcMutexGuard<T>. But this particular bit requires combining Arc and Map in parking lot, which is not currently supported. It's specifically this use-case which is affected - when we have a NamedView<BoxedView> (as we do when using builder), but want to call find_name::<T>.

Most of the time, call_on_name is what you want - it's simpler, safer (should never deadlock) and keeps the logic that affects that view within the scope of the closure. find_name is mostly required when you want to access several views and do some back-and-forth between them.

[gyscos]

I pushed the feature/mapped-arc-mutex branch here which uses my parking_lot fork with the mapped arc mutex guard. With that, find_name now works as expected on views generated by the builder module.

[michalfita]

Does that mean I need to use cursive dependency from the git branch? 🤔 kind of not the way I'd like to... maybe good for now.

[gyscos]

Yes it's really just a temporary solution until either parking_lot merges (and publishes) my PR, or we find an alternative solution (possibly publishing/vendoring my fork, as it's an internal only dependency).

In the meantime (for testing) you can use cargo's patch mechanism to force all (transitive) dependencies to use the git version of cursive.

[gyscos]

Now, if you want to allow the blueprint to define items, you'll first need to come up with the schema to represent that.
For example, since each item will be inserted with insert_items, which takes 3 arguments, you could define the schema as a list of items, where each item is a list of 3 values (one per argument to the insert_items function).

A yaml example:

items:
  - ["1", "LastChild", 0]
  - ["2", "LastChild", 1]
  - ["3", "LastChild", 2]

Now - how do we parse this?

One way is to define an "Item", and to implement cursive::builder::Resolvable on it.
We could say an item is a tuple (String, Placement, usize). Both String and usize implement Resolvable, so if Placement did as well, we'd be good to go. Unfortunately because of the orphan rule we can't directly implement Resolvable for Placement from outside of cursive_tree_view, so we'll use a wrapper instead:

struct Place(Placement);

impl cursive::builder::Resolvable for Place {
    fn from_config(
        config: &cursive::builder::Config,
        context: &cursive::builder::Context,
    ) -> Result<Self, cursive::builder::Error>
    where
        Self: Sized,
    {
        let placement: String = context.resolve(config)?;

        Ok(Self(match placement.as_str() {
            "After" => Placement::After,
            "Before" => Placement::Before,
            "FirstChild" => Placement::FirstChild,
            "LastChild" => Placement::LastChild,
            "Parent" => Placement::Parent,
            _ => {
                return Err(cursive::builder::Error::invalid_config(
                    "Could not decode placement",
                    config,
                ));
            }
        }))
    }
}

(This is the kind of things that could be autogenerated based on FromStr or Deserialize or various other solutions. Or maybe #[derive(Resolvable)] one day? :p)

Once we have that, we can resolve the items entry as a Vec<Item>. We just need to call insert_items for all of them.
When writing a blueprint, you can add a #[blueprint] attribute to control how the value should be used; in particular, there's a foreach parameter to call a function for each argument. Until now it was limited to single-argument methods, but I just added a commit to bring support for more complex call expressions:

type Item = (String, Place, usize);

#[cursive::blueprint(TreeView::<String>::new(), name = "TreeView")]
struct Blueprint {
    #[blueprint(
        foreach=insert_item(items.0, items.1.0, items.2),
    )]
    items: Vec<Item>,
}

You can imagine the foreach value will be used like this:

let tree_view = TreeView::<String>::new();

for items in blueprint.items {
    tree_view.$foreach // will become `tree_view.insert_item(items.0, items.1.0, items.2)`
}

With this, you can now load configs like this:

LinearLayout:
  orientation: horizontal
  children:
    - TreeView:
        with:
          - name: "tree"
        items:
          - ["1", "LastChild", 0]
          - ["2", "LastChild", 1]
          - ["3", "LastChild", 2]

This is just one example of how to encode the items in the config doc. This one maps "easily" to the insert_items function, but we could consider a different representation (maybe an actual tree). Would need more specialized code to parse it into the TreeView.

[michalfita]

Oh man, thanks for all the effort you've put into that. Very helpful, I'm going to exercise that.

But if I may have an off topic suggestion, what'd you say about using bit of that energy to go back and take a look at #765? I refreshed it.

[michalfita]

This doesn't work as cursive_tree_view has dependency on different version of cursive-core now. The cursive crate on the last commit seem to depend on cursive-core 0.4.6.

[michalfita]

OK, patching cursive-core to that last commit of yours works. Thanks.