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

Disable showing parameters in the dialog #2211

Open
modelica-trac-importer opened this issue Nov 4, 2018 · 17 comments
Open

Disable showing parameters in the dialog #2211

modelica-trac-importer opened this issue Nov 4, 2018 · 17 comments
Assignees
Labels
enhancement New feature or request MCP Generic MCP label (prefer specific MCP label for grouping of issues belonging to the same MCP)

Comments

@modelica-trac-importer
Copy link
Collaborator

modelica-trac-importer commented Nov 4, 2018

Modified by beutlich on 23 Mar 2018 09:24 UTC
Sometimes users want to disable showing a public parameter from the dialog window because the parameter is hard to use, but keep it possible to modify it using the textual layer for models extending from the model.

Current ways to disable showing a parameter in the dialog pop-up:

  1. Make the modifier final (but then you can't modify it in textual layer)
  2. Make the component protected (but then you can't modify it in textual layer)
  3. Set enable=false (still shows it, but cannot be modified)
  4. Make the component constant (removes it, but causes problems when you have array sizes which are parameters since you cannot easily mix parameters with constants)

What seems to be missing is simply hide=true in the annotation (or giving special meaning for tab=""), to not show the component in the Dialog pop-up.

Buildings/IBPSA used the approach to make the component constant, but then models only work in tools which help the type-checking by evaluating certain parameter expressions and treating them as constant (or something similar).


Reported by sjoelund.se on 21 Oct 2017 05:10 UTC
Sometimes users want to disable showing a public parameter from the dialog window because the parameter is hard to use, but keep it possible to modify it using the textual layer for models extending from the model.

Current ways to disable showing a parameter in the dialog pop-up:

  1. Make the modifier final (but then you can't modify it in textual layer)
  2. Make the component protected (but then you can't modify it in textual layer)
  3. Set enabled=false (still shows it, but cannot be modified)
  4. Make the component constant (removes it, but causes problems when you have array sizes which are parameters since you cannot easily mix parameters with constants)

What seems to be missing is simply hide=true in the annotation (or giving special meaning for tab=""), to not show the component in the Dialog pop-up.

Buildings/IBPSA used the approach to make the component constant, but then models only work in tools which help the type-checking by evaluating certain parameter expressions and treating them as constant (or something similar).


Migrated-From: https://trac.modelica.org/Modelica/ticket/2211

@modelica-trac-importer
Copy link
Collaborator Author

Comment by beutlich on 21 Oct 2017 06:56 UTC
I always wondered why there is no Dialog(visible=false) annotation for parameters in Modelica, but we only can set them Dialog(enable=false). SimulationX has some means to do so, but standardization of Dialog(visible=false) seems more intuitive and straight-forward.

@modelica-trac-importer
Copy link
Collaborator Author

Comment by beutlich on 21 Oct 2017 07:07 UTC
Actually, SimulationX has some equivalent of Dialog(active=false), where inactive parameters are not only invisible in the dialog, but also are ignored for the flattened Modelica model.

@modelica-trac-importer
Copy link
Collaborator Author

Comment by beutlich on 21 Oct 2017 20:34 UTC
See also https://stackoverflow.com/q/38528492/8520615.

@modelica-trac-importer
Copy link
Collaborator Author

Comment by henrikt on 21 Oct 2017 22:09 UTC
SystemModeler has Dialog(__Wolfram_show = false).

@modelica-trac-importer
Copy link
Collaborator Author

Comment by hansolsson on 23 Oct 2017 08:17 UTC
One question is how important it is too hide the parameter - and from whom.

One traditional solution for this has been to use a tab "Advanced"; the idea is that novice users will stay away from it.
Hiding any parameter where enable cannot be true would be straightforward (includes "enable=false" and "enable=animation" if "final animation=false"); and similarly hiding a specific tab would also be straightforward.
On the other hand some users want to see (but not edit) even final parameters in order to understand the model.

If we then look at examples e.g. https://stackoverflow.com/q/38528492/8520615 it seems that the goal is that that only the library developer can set the parameter; but in that example-package you need to set the parameter to use the connector-class.

@modelica-trac-importer
Copy link
Collaborator Author

Comment by henrikt on 23 Oct 2017 08:30 UTC
Not showing a component in any tab at all makes sense for components that are so "advanced" that they are only relevant for somebody willing to look at the textual form of the model.

@modelica-trac-importer
Copy link
Collaborator Author

Comment by hansolsson on 20 Mar 2018 16:41 UTC
Language group:
Dialog(visible=false)
makes sense, i.e. adding visible-attribute with default value true.

Agreement.

@modelica-trac-importer
Copy link
Collaborator Author

Comment by hansolsson on 20 Mar 2018 17:29 UTC
Henrik: Should it be ternary - i.e. does "visible=true" mean that it is visible even if it would be hidden for other reasons, e.g. if final.
Other options discussed - overriding "final" hiding parameters - regardless of this, and enumeration instead of visible.

@modelica-trac-importer
Copy link
Collaborator Author

Comment by hansolsson on 22 Mar 2018 09:36 UTC
Language group:
Different tools have different logic for showing final parameters (some always show, some never show, some have it as a setting).
Issues with ternary logic - Dialog is a record in the specification.
An alternative would an enumeration (downside: more to type).
One possibility would be a reusable enumeration for ternary logic.

type Ternary=enumeration(False, Undefined, True);

@modelica-trac-importer
Copy link
Collaborator Author

Comment by hansolsson on 22 Mar 2018 10:23 UTC
Language group continued:
Say that only a recommendation (and same for enable) and only have true/false.
Other alternative would be two Booleans: forceShow and forceHide (and disallow both being true).

  1. Ternary logic for Boolean visible (different if set or not set); skipping record constructor or saying that value is tool-specific.
  2. Say that setting is only a recommendation, have a default value in the record constructor (visible=true) - but that tools may use a different default.
  3. Ternary value using Ternary enumeration
  4. Two Booleans forceShow and forceHide
  5. Can only hide variable with visible=false, no way of forcing them to be visible.

Poll:

  1. 4
  2. 3
  3. 4
  4. 1
  5. 4
    No clear winner; seems 1, 3, 5 are preferred. (1 and 5 are more compatible, for enable 3 would not work.)

@modelica-trac-importer
Copy link
Collaborator Author

Comment by hansolsson on 22 Mar 2018 10:29 UTC
Continued: 1 seems preferable after additional discussion.

@modelica-trac-importer
Copy link
Collaborator Author

Modified by beutlich on 23 Mar 2018 08:03 UTC

@modelica-trac-importer
Copy link
Collaborator Author

Modified by beutlich on 23 Mar 2018 08:05 UTC

@modelica-trac-importer modelica-trac-importer removed this from the Design96 milestone Nov 4, 2018
@modelica-trac-importer
Copy link
Collaborator Author

Modified by beutlich on 23 Mar 2018 09:24 UTC

@beutlich beutlich added this to the Design97 milestone Nov 12, 2018
@HansOlsson
Copy link
Collaborator

Will return to on Friday November 30th, 2018. (With more use-cases.)

@beutlich
Copy link
Member

2018-11-30 poll among MAP-LANG subgroup:

Do nothing: 1
One Boolean flag visible: 5
Two Boolean flags: 5
Ternary: 7

Conclusion: MCP for Ternary.

@HansOlsson HansOlsson added the decided A decision has been made (label added before the spec is changed) label Jan 15, 2019
@HansOlsson HansOlsson added enhancement New feature or request and removed bug Something isn't working decided A decision has been made (label added before the spec is changed) labels May 10, 2019
@HansOlsson
Copy link
Collaborator

Changed labels, since there was a decision, but the decision was to make an MCP.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request MCP Generic MCP label (prefer specific MCP label for grouping of issues belonging to the same MCP)
Projects
None yet
Development

No branches or pull requests