Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve usage of the rules system with macros #1051

Open
flowln opened this issue Nov 22, 2023 · 1 comment
Open

Improve usage of the rules system with macros #1051

flowln opened this issue Nov 22, 2023 · 1 comment

Comments

@flowln
Copy link
Contributor

flowln commented Nov 22, 2023

The rules system is very interesting for embedding some additional behavior from Qt Designer without going through python code. But I think it could be extended a bit to further improve its flexibility.

In my application, I want to have some part of an interface - possibly embedded in a PyDMFrame - to be visible only on some locations, while it's hidden elsewhere. For that, I wished to use a macro definition to select the visibility of such element when opening the UI. I was able to make it work OK with the following configuration:

Rule expression for setting visibility using a macro. It has a useless local plugin, and needs custom code in PyDM to work.

The md function (short for macro_defined) I added in a local clone of PyDM in the eval environment:
macro_defined function: lambda v: not v.startswith('${') or not v.endswith('}')

What I want then is to make this not so hacky-ish, with better native support for PyDM. That would entail IMO:

  • Adding such a md function or similar to the eval environment for dealing with macros (you can make-do without it, of course, but it's annoying).
  • Possibly making the md-like function automatically get the value of the macro without the ${...} things (so, it would look like md('TEST') in the end).
  • Allowing us to not specify a channel every time. I had to add a channel there simply because it required me to, though it doesn't do a thing (except trigger the expression, but we could make it so that, if there's not channels, or no channel is marked as 'Trigger', the expression is only evaluated once at application startup).
  • Possibly passing the initial value through eval, so we could only use that. This would also mean we could leave the Expression field empty.

That I think would make using the rules system better, though I appreciate any feedback or comments on this proposal. 🙂

@jbellister-slac
Copy link
Collaborator

Hi, sorry for the delay! Caught us during Thanksgiving break. We think that extending the rules engine like this sounds like a good idea too. I think your proposals for not requiring a channel/expression and only evaluating once at application startup sound fine too, the extra flexibility should be a good thing and the documentation can be updated to make it clear what would happen in each case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants