Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Allow for configuring the default values of properties. Provide a machine readable file that includes all default values of properties for each widget

Ouverte
  • Quelque chose ne va pas ?
#3,815 5 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 2 jours

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
35/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
Calme
Stack technique
java
Domaine
tooling

Piste de recherche

Start by locating where Phoebus widgets define their property defaults and how those definitions are exposed to clients. Compare the proposed machine-readable file with the alternative of generated documentation, then identify how either approach can cover every widget and property. Done means clients can reliably determine omitted property values, with the result kept in sync when defaults change.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

It is legal in phoebus to have a bob file that defines a widget that omits most of the property tags. Any omitted tags will have some default value, which of course will not be available to a client that reads just the xml.

This is problematic for cases where we'd like to do things like check the state of a set of screens against some condition. Unless we happen to know what the default value of a particular property is for a particular widget, we cannot perform the check if the xml does not include the information.

Of course, I could open the editor, drag a widget, and see what the initial value is, but this is a brittle solution that is subject to breaking if the defaults ever change. It would be good if the default values for all properties for all widgets were in a machine readble (i.e. json or yaml) file with a defined schema somewhere that clients could read for a base state. Alternatively, it would be good if at least there were a automatically updated document that listed all of these default values in the documentation.

For context, I am developing a linter for phoebus screens: https://github.com/NSLS2/phoebuslint. It works pretty well but I am running into things like this:

Have a rule that checks if a widget is outside of the bounds of a screen. The screen is configured to be 400 x 600, but since 600 is the default width it is omitted in the xml. The linter doesn't know about this and defaults to 0, so every widget gets marked as out of bounds.

For now, I've hard coded the default value, but it would be great if we could put together a more robust solution.

Langage dominant
Java
Étoiles
130
Forks
132
Merge moyen
3 j 1 h
PR mergées (30 j)
24

Préparer son environnement

  • Aucun Dockerfile ni fichier Docker Compose
  • Propose un modèle de pull request
  • Aucun guide de contribution

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de ControlSystemStudio/phoebus

Toutes les issues de ControlSystemStudio/phoebus

Issues similaires

Plus d'issues Java

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.