Project abandoned?

[nerdoc]

Is this project still alive? There are 11 pull requests, some >1 year old; I just mane two tiny fixes (a typo and an example correction of a path in settings, which fixes a bug), and even the PRs are not coming through the CI ,because a CI config file is missing or defective...

Is there anyone actively maintaining this package?

[kytta]

@nerdoc Yeah, it seems like it hasn't seen any major activity after being brought into Jazzband. I'll focus on bringing this project in a good shape over the next weeks, so stay tuned, I guess :P

[nerdoc]

Hi @kytta, thanks, this would be great. I have done a few additions in my code to enhance e.g. MenuItem, added a badge attr, a disabled state attr (like visible), and a view_name attr, (and some other things...) If you want I can put together a PR if I find time. Should I create a separate issue for that?

[kytta]

I have done a few additions in my code to enhance e.g. MenuItem, added a badge attr, a disabled state attr (like visible), and a view_name attr, (and some other things...) If you want I can put together a PR if I find time. Should I create a separate issue for that?

I would say, you can directly create a PR without creating an issue for it

Speaking of MenuItem attributes — I am not sure we need that many out of the box. MenuItem sets its attributes from kwargs, so we don't need to add stuff that don't add anything to the logic of the app. For example:

• add view_name, because it's about navigation
• don't add badge or disabled, because it's stylistic (compare to the icon property from the docs)

[nerdoc]

Speaking of MenuItem attributes — I am not sure we need that many out of the box. MenuItem sets its attributes from kwargs, so we don't need to add stuff that don't add anything to the logic of the app. For example:
* add view_name, because it's about navigation
* don't add badge or disabled, because it's stylistic (compare to the icon property from the docs)
Yes, but: All **kwargs** properties are available in the template as variables - but given you want it a callable, it isn't called. E.g. a *badge* is mostly never meant as static str`, but as a function that returns the count of new emails, or even being there or not. MenuItem allows this by callables, which is extremely great, but "static" attributes don't help here.

For view_name yo are partly right - but I still need to subclass MenuItem in my app to get the correct behaviour:

def process(self, request: HttpRequest):
    if self.view_name:
        self.visible = request.resolver_match.view_name == self.view_name
        if not self.visible:
            return
    super().process(request)

What would help is to add a generic looop over all **kwargs (after putting them into a list self.kwargs: if callable(kwarg): ...
or the like, so that additional kwargs would be able to be callables too.

[kytta]

Yes, but: All `kwargs properties are available in the template as variables - but given you want it a callable, it isn't called.

You're right! I haven't considered this.

What would help is to add a generic loop over all **kwargs (after putting them into a list self.kwargs: if callable(kwarg): ... or the like, so that additional kwargs would be able to be callables too.

This is a nice solution. I'd first ask for the leads' opinion.

---

Let's proceed like this: create issues for (a) the view_name property; and (b) for the callable kwargs. Let's continue the discussion there.

I'm closing this issue, for the answer is: no, it is not abandoned any more :)